You've both raised some interesting points here.
(As it is, I never started making Voxeng3 - might do it if I get a good idea sorted out in my own head.)
@ Diggsey
What you've said all sounds very logical, however, I was thinking of using an octree to save wasted space as well. - With that multiple resolution array idea you've suggested, I'd be using more data than I was in the 1024x1024x128 array. (I'd be using like, 1024x1024x128 + 512x512x64 + 256x256x32 for example.) This would most likely overflow the Java heap, something I'm trying to avoid getting close to doing.
I'd prefer to use an efficient octree (not even necessarily using the object oriented one Zotoaster suggested) to make sure all raycasts were as short as possible as well as ensuring all data is as small as possible (without compression/reworking the voxel engine).
@ Fallout
Yeah I never do things the way they're supposed to be done. - I don't know how to make Wolfenstein3D, but I came close using another method (1D raycasting). I don't know how to make a proper voxel engine, but I came close using another method (2D raycasting).
This is just because I don't know how the 3D maths works behind real games and haven't invested much time attempting to learn.
I think though, that real voxel engines use layered alpha-mapped images which get closer and closer to the camera and end up making it look like filled space. Similar to the way this image looks:
I imagine each layer of that is just a splodge of pixels on a 2D image which is then rendered as a plain infront of and behind other splodges to make a 3D shape.
I could do this (badly) but the difficulty then comes in re-rendering the splodges efficiently and calculating the new angles to render from. (I'd also probably use raycasts to be rendering it anyway so it'd render the whole process fairly pointless. xD)
In conclusion:
I'm actually not that good a computer scientist, I don't know how half of the things I see are done. xD
