You can get somewhat of an idea how it works here: http://www.voxelquest.com/news/how-does-it-work http://www.voxelquest.com/news/how-does-it-work You can cha

You can get somewhat of an idea how it works here: http://www.voxelquest.com/news/how-does-it-work http://www.voxelquest.com/news/how-does-it-work You can change geometry by passing parameters to to the shader or creating special object generation functions within the shader. This is not intended to render everything in the game, mostly just aspects of the environment that can be easily procedurally generated like terrain and structures. Other things can be merged in from a traditional pipeline like using polygonal character models (or even sprites, as I have shown in my past demos). The more that you can define mathematically, the better. Doing texture lookups is almost an order of magnitude more expensive sometimes, and less precise always. You start really simple, and say did I hit the bounding box that contains the object? If so, did I hit the more complex piece of geometry within that? If so, what UVW coordinate did I hit on the geometry? Marching through the UVW coordinates on the ray, you can create any sort of procedural texture. I have shown a voronoi texture and a shingle texture but really anything can be created and some procedural textures are very cheap compares to others (voronoi is relatively expensive). If you look at old shots of my terrain, it is all created with voronoi and noise pretty much. http://www.voxelquest.com/gallery.html http://www.voxelquest.com/gallery.html It is possible things will get too expensive to do in realtime, but the option will always be there. Worst case scenario is that I can render like I did with my old isometric engine and cache the render results. At the very least the option will always be there for more powerful computers in the future. That said I think realtime is feasible on decent midrange/modern hardware.