My name is Yoshiharu 'Slang' Sato and I am 19 years old, living in Japan. I've been working on my own polygon engine over the several months (video log: http://slang.blog15.fc2.com/).
Through my doing research on dynamic geometry destruction using constructive solid geometry, I recently came across your Voxlap Engine and that was really a shock-and-awe impact to me - high performance software volume rendering in real-time along with the dynamic geometry destruction!
Personally, I do think that the dynamic geometry destruction is the key to new-generation games, however, as lighting and shadowing in a game get done all dynamically, it is becoming much more difficult to achieve the dynamic geometry destruction in a polygon engine because altering geometry in a game level significantly increases 1) the polygon count of the level geometry 2) the number of lights that are visible to the camera 3) the number of objects that are visible to the camera or casts shadows onto the camera region. (Hence there could be massive GPU load along with multipass rendering and shadow buffer rendering.)
Consequently, I am now strongly interested in voxel engines for the potentials (and in actually writing one) but your Voxlap source code is highly optimized and thus it is quite difficult for me - a snot-nosed programmer - to understand the inside algorithms from that. So I am curious if there are any useful references on voxel engines. Would you tell me any good books / online resources out there? (I've googled but got no useful hints so far...)
Thanks in advance.
Best regards,
Awesoken at
You have an extremely impressive demo! Too bad I can't run it on my lowly ATI X800 : /
I would advise against wasting your talents on pure voxel technology. Yes, it's nice in theory - after all, what could be simpler than a 3D grid? In practice though, things are very different. To get the kinds of frame rates I do in Voxlap, I had to use tricks for everything. You can forget about doing anything with a triple-nested 'for' loop. And if you were thinking about storing the 1024x1024x256 map uncompressed, think again. In Voxlap, I compress the world map using RLE-style compression along the columns, storing only the colors of surface voxels. I then render directly from this data structure. Modifying this compressed buffer is also quite a chore, as it requires working directly with compressed data in order to be fast enough. In the end, I realized that all these hacks and optimizations were a lot more work than it would have been to write a standard polygon engine.
Voxlap's renderer is based on the same kind of raycasting technology as the old heightmap voxel engines, like NovaLogic's Comanche Maximum Overkill. Of course, I devised ways to extend it to support room-over-room and 6 degrees of freedom. Here's a nice tutorial that explains heightmap-based voxel rendering: http://www.flipcode.com/articles/voxelland_part01.shtml
You might also want to check out some of the older demos at the bottom of my Voxlap page as they all use tech similar to Voxlap. The QuickBasic code at bottom is very short - perhaps you should start with that. Besides that page, you should check out GROURAY2.KC (included with EVALDRAW), which shows a part of how my extension to 6 degrees of freedom works. This thread has a lot more information about Voxlap: http://jonof.edgenetwork.org/forum/viewtopic.php?t=30
Slang at
Awesoken said
You have an extremely impressive demo! Too bad I can't run it on my lowly ATI X800 : /
Thanks! And yes, the demo requires GeForce 6800 or later since it uses hardware bilinear filtering on floating-point textures (4xFP16).
And thanks again for the links. I haven't followed up those completely yet, and thus I can't verify the practical effectiveness or even the actual utility of this idea at this point but, how about the idea of using virtualized textures for voxel rendering?
At this year's QuakeCon, John Carmack actually mentioned this - "raycasted voxel rendering + MegaTexture = MegaGeometry." As you might know, the MegaTexture is virtualized texturing technology that uses single gigantic texture but requires only few megabytes of VRAM when drawing the MegaTexture-mapped geometry. Therefore, the MegaGeometry would be some kind of "infinite voxel world" - at least so far as the local hard drive's space permits.
With the MegaGeometry and dynamic geometry destruction, voxel-based games would be pretty attractive and I think that there would be a lot of new gameplay experiences to become reality, such as driving an army tank insanely in a fully-destroyable city like these [1, 2]. :D Or, the player is a huge monster like Godzilla and destroys worlds' cities. (I think destruction is the best interaction!)
Would you tell me your thoughts on the possibilities of MegaGeometry?
Best regards,
Awesoken at
your thoughts on the possibilities of MegaGeometry?
I am not familiar with "MegaTexture", so I have no thoughts about it.
psychorosti at
Heard about "MegaTexture" and "MegaGeometry" too, but its rather dissapointing on what it represents. Here for some more infos Wiki on MegaTexture .
There is really nothing "new" about it, using realtime partial-data-fetching algorithms is common in every bigger database system/software. And thats what it is. It would be much better when they begin to start they work on a genetic-algorithm basis as some of Tom's Projects do.
Creating a new generic-Object creating-Language (GOL) that can be Hardware-Side implemented to overcome the final bottleneck of every IT-System: Memory Bandwidth.
Also this would then suggest a whole new way on programming. Enforcing some it-experts to work on the GOL direktly as instead of having to create the meshes/world beforehand. THAT would be a real huge step towards a World that you imagine, Slang.
But for me it really did not look like that there was any thought spend on this direction.