My rod-marching was an order-of-magnitude faster than classic per-pixel ray-marching on the CPU.
I have now approximated it on the GPU - try it live in your browser and report back on your performance statistics please :)
First, you render the scene to a small texture, then use this texture as input to the bigger scene.
E.g. you may render a 64x64 texture of the scene using a small number of maximum ray-steps. Then you render to a 256x256 texture using the 64x64 texture as input and another small number of ray steps. And finally you render to the screen with normal ray-steps and the 256x256 texture as input.
Sadly, the SIMD nature of GPUs works against the big gains seen on the CPU. Also, the cost of changing render targets adds overhead. On wimpy laptop ATI GPUs I’ve had speed reports of 25 to 50% improvement. This is not to be sniffed at if it takes you from 10 fps to 15 fps it takes you from unplayable to barely tolerable :)
What is perhaps more interesting is the code I wrote to get webGL going. I have a nice little gluOrtho2D / glOrtho and gluPerspective as well as mat4 inverse function in there for you to copy.
Also generally useful, there’s a bitmap (AngelCode) font renderer and a window concept in there. Having worked making UI toolkits for real its kind of hard to fight the urge to go make UI toolkits everywhere I go. They get more and more minimal each time though.
I guess I’ll add nice widget border utility, some layout managers and then some simple widgets like labels and sliders and buttons and so on soon enough.
↓ click the "share" button below!