No, so far, i haven't been doing any opts (even compiler opts are completely disabled), though some assembly coding might speed the whole thing a bit..
BTW i already have benchmark built in :D
Printable View
No, so far, i haven't been doing any opts (even compiler opts are completely disabled), though some assembly coding might speed the whole thing a bit..
BTW i already have benchmark built in :D
Well I've got an algorithm that may help you and it may not. Essentially a line in any space be it 2D or 3D is a displacement from one point to another. If you know the endpoints then you can find any point in between them using linear interpolation.
If you know Bresehnam's line drawing algorithm you can use that to 'step' through your world space. You know the origin of your rays and you know the endpoint of your rays. The endpoint of your rays is simply a function of the viewing angle on x and y, the viewing distance, and the distance to the rendering plane. Once you find this endpoint you can simply step from origin to endpoint using Bresehnam's integer algo. I've code this for my voxels and it simply flies. There are some issues with it, however. For one you cannot bilinear interpolate the texels because you are using an integral stepsize. There is no way to find the barycentric coords of your ray within the voxel being rendered - or at least not one that I've found yet. But the actual algo should run fairly fast on even the slowest of machines. The algo is very good at drawing lines on video displays during rasterization and it works well also as a method to trace a line in 3D or 2D space.
If you are not using an integral algo like this then you are essentially doing what renderers currently do. You are only interpolating on 1 coordinate - renderers typically only find the x coordinate the line while rasterizing and simply increment the y by one pixel. This produces good results in a render....but in world space this will not do. Problem is you will be skipping over certain voxels that should be there...but are skipped. This results in a blocky render.
If you are using sin() and cos() to step through the world space then you are suffering some serious overdraw problems in your stepping which results in extremely slow renders. Basically you want to assume that you have drawn 1 voxel and then step forward in world space by the size of that voxel. After all, if we have hit a voxel and already found where it is at in screen space.....why constantly recompute the ray if we have already rendered the voxel that ray hit? The size of the voxel is again a function of the distance to the rendering plane and the size of the voxel. Small sizes result in very good renders, albeit at a performance price, and large sizes result in blocky renders but are extremely fast.
Perhaps we should join forces as I'm looking to add some objects to my terrain and I do not want to combine polies with the terrain. Using polies with voxels causes the polies to stick out like sore thumbs....but using voxel images with voxel landscapes would look.....uberly voxelicious.
:)
PM me.
Found more information on 6 DOF landscapes. There is an article out there about Vertical Ray Coherence. It's freely available on the net...but I won't attach it here because I'm not sure if that's allowed or not.