Horde3D

So I have been playing around with porting the engine to mobile platforms, trying to get some hardware to run it on (beagle board or openpandora console), and i started thinking, wow, now that Horde3D is feature complete what is left to be done? How would a Horde3D 2.0 feature list look like?

So as an inspirational discussion for the weekend i thought it would be cool if we shared our vision of what a next-next-gen game engine would be like.

The trend appears to be ray-tracing, however as you all know ray tracing is at the moment a multi-core CPU application, not GPU driven. Also there is no standard API for ray-tracing (openRT is proprietary afaik, as is the intel solution). nonetheless ray-tracing GPU approximations or GPU friendly algorithms are becoming available. In other words do you guys think that ray-tracing is the next-next gen game technology?

What would your Horde3D 2.0 feature list look like?

Let the words flow...

No. Every few years it seems that real-time ray-tracing gets another round of discussion, and in the end it always turns out that for rendering triangles, rasterization will always be faster...

Ray tracing should only be used when you're doing something that rasterization cannot also easily do (e.g. advanced parralax mapping techniques are currently using small ray-traces within the pixel shader!).

Personally i think ray tracing makes sense in some scenarios, with 16+ core cpus in the near future we have to put them to use, Intel is trying to make us all RT believers, due to the full programmability and familiarity with the x86 IS, personally i am having a hard time swallowing that, but lets see what they come up with, they have been investing heavily in the game market, with the purchase of several game middleware companies, havoc, project offset and all that...

Stuff like Ageia physics cards are simply going to be swollen by one of the 16 cores (personally i think nVidia bought Ageia because of the software and the IP not because of the physics dedicated cards). The graphics cards, now that is a whole different story with programmable graphics cards (CUDA) and huge amounts of dedicated memory, it would take a serious effort to switch game developers mentality from rasterization to RT-RT. I think RT-RT will happen when we have 128/256-bit cpus and parallelization becomes common place, graphics cards have a huge advantage in terms of wideness.

I would like to see some standards and real life games using RT-RT technology in systems (CPUs) that don't cost over $250.

Have any of you seen http://theamusementmachine.net/ ? (I'm not sure where I first came across it - I thought it might be here but a search of the forum didn't turn it up)

The demos are not the prettiest graphics I have ever seen but they do claim to be real time ray tracing performed on the GPU.

And then there is http://www.openrt.de/

Something I noticed with the screenshots of openRT is that all of the shadows are hard-edged. Obviously doing proper ray-tracing for non-point light sources is very expensive which brings us to blurring the shadows and messing with the elegance and 'correctness' of the whole approach.

Though now I say it perhaps there is a way to trace a cone of light (from a circular source to a point) and make a good approximation of how much is occluded without the brute force approach of tracing a grid of lines. I CAN do "how close does this line get to this plane... Is this approach used at all does anyone know?

Had anyone read John Carmack's thoughts on RT?

I think he's hit the nail on the head in saying that "future" renderers will use both raster and ray-traced graphics.
For things that can be rasterised easily, rasterize them!
For things that can't be rasterized easily, ray-trace them!

It makes a lot of sense really - a ray-traced pixel can still output to the same frame-buffer that you're rasterizing into (same depth buffer, same G-Buffer, etc, etc). You can even use the same fragment shaders on pixels that come from either a ray or a raster!


Also, his idea of using a ray-tracer for a sparse voxel quad-tree is much more justifiable then just making a ray-tracer that still uses triangles.