Rahsennor wrote:
I don't mean to be rude, but did anyone actually look at my link? Raymarching (a form of raytracing) works in realtime on consumer GPUs now.
Sorry, I didn't say anything to acknowledge either of the to things you mentioned (point cloud rendering, or raymarching) but I thought they were both good examples of alternative rendering paradigms (the point cloud especially).
I didn't feel a need to say anything about raymarching specifically because it's in the same family as raytracing, and its advantages (e.g. can express curves and complex shapes with relatively simple code) and disadvantages (mainly ineffective performance) are pretty much the same as other forms of raytracing.
Rahsennor wrote:
The Unreal Engine is
already using it for soft shadows. There are
plenty of examples around the web that will run right in your browser, even on a crappy Intel GPU like mine. Granted, it doesn't work so well for animated models of humans, but it's definitely already practical for other things.
I was also alluding to stuff like this when I said I've seen pixel shader raytracers in the demonscene. Years ago I saw the
Valleyball demo, which was released with its source code, and it was really cool to be able to just see everything right there in the shader code. Since then shadertoy has appeared, which has been a cool place for lots of things like this.
(I like the application to shadows, I hadn't seen that yet. Very interested to learn how the SDF is being stored, which those slides don't really explain... got some research to do later, thanks.
)
As far as how practical it is... none of those examples run at a "playable" game framerate at fullscreen for me (with a half decent GPU), and all of those scenes are relatively very simple. A fish swimming in water like this should be a well above 60fps walk in the park for traditional rendering (
e.g. 16 year old xbox demo), and this demo struggles to do 3FPS in fullscreen with a modern GPU. This also doesn't scale well: more objects mean more code in the shader-- the limit of what you can fit in a shader program is VERY low here. The demos with an infinite field of balls do it with recursion/loops, but you can't use recursion to e.g. turn a "dinner table" function into a "furnished dining room", recursion only really makes
fractal shapes. You will need code for each an every unique element, and that quickly eats up both your shader size budget and your performance budget.
(Though you could make a case for future tech where shaders have access to much, much larger shared program memory? Kind of like the idea of space-inefficient self modifying code for faster PPU upload on the NES... a big huge optimized spatial partitioning tree as unrolled code... might solve the memory half of the limitation at least.)
The fish looks really neat, but that fish is also modeled with like 100 difficult lines of code, really editable only by a specialized programmer + artist. Doing the same thing with traditional triangles would be straightforward work for any pro modeller, could perform well in more complicated scenes, and you could
make a full game out of it. I'm impressed by it, but only
because I know it's being done in such a difficult way.
Quote:
All the details, with loads of realtime and non-realtime examples, can be found
on the site of the guy who popularized it.
I loooove the picture here of the snail being modelled from functions. That's really cool, and also really illustrates both the power and the problem of this approach.
3D modelers are used to using scuplting tools like
Zbrush that work similar to the physical clay counterpart. Click somewhere to add detail, squish or stretch the shape, cut a groove, add a blob... A triangle mesh handles these actions very well; each just moves some of the points around, and the detail is directly there in the data. A point is where you put it, not dependent on any chain of actions, etc.
Modelling from high level shapes, though, is a really painstaking thing to do! The whole process is inverted: you want to start from high level shapes, and make something interesting looking by making as few additions to it as possible to keep the code complexity down. Every curve, every twist, every groove adds another node of code to run to produce that detail. The 3D model is like an edit history (sort of like the
old sierra games). The main problem is just that if the "edit history" gets too deep, performance is dead, and that's a very hard constraint to model around. Every piece of the tree affects everything else, and making changes higher up require corrective tweaks everywhere on the model.
Maybe I should take a moment to mourn the loss of Java on the web, because one of my favourite websites no longer works functionally at all. Ken Perlin's website had so many very interesting Java demos of different ideas for rendering and animation.
http://mrl.nyu.edu/~perlin/