I spend a lot of time doing lighting TD work using non-realtime renderers. Every one of those examples is pretty good for realtime, but also looks soooo wrong! its not anywhere near the same quality as a proper raytracer!
-Thats not what an ao pass should look like. But you shouldnt even need ao if your GI/shadows look good
- Gi should have detail to it, every realtime example is sooooo blurry
-The screen space reflections sometimeslook ok but really depends on your scene, you get all sorts of reflections in the wrong place.
-Yucky DOF without the nice bokeh on highlights and all those edge problems you get with a z-space blur.
The beauty of raytracing with a unified sampler is it makes the algorithm for each of these features you listed incredibly simple and it mixes distributes CPU/GPU time to whats important depending on that part of the image.
scene with lots of motion blur- more primary samples, less samples to gi/shadows/reflections - automatically based on how much gi/shadows you see
scene with lots of gi - more samples in gi, less for reflections etc - automatically
You can have a complex scene with reflections/gi everywhere, and then turn a heavy DOF on and get faster frame times.
Would there be much of an opportunity for someone whos into photo-realistic 3d rendering to create some of these datasets?
For starters i was thinking of making something like the make3d dataset - http://make3d.cs.cornell.edu/data.html for some of my own experiments.
I think you are missing a shift that has happened in the industry over the last few years. Yes, now that computers are fast enough, pixar raytraces everything in renderman. Most other major studios use that or arnold, a pure raytracer.
I might be out of my depth and not truly understand what is meant by abstractions, but I think the answer is yes?
Lets look at the example on the website, theres a node called cube. Isnt that little node an abstraction of a whole lot of other things? A more advanced visual programming language would allow you to access and modify what a "cube" is. You would be able to double click on that and be taken to another graph. This graph would be about the construction of a cube and would take input of width and create triangles in space to represent a cube. you could double click on the triangle node and be taken deeper, this time a node that takes vectors and defines where the surface is between them and sends it to the renderer. We could have a seperate graph to define what a vector is and the data structures behind it.
All of this for a simple cube could be represented as a huge tangle of nodes and connections, but we can condense it down to a single node called cube that takes an input of width.
Having networks and sub-networks allows you to choose what level of abstraction you work at. Each of these things at different levels can be represented by a graph.
Hold on a sec, I stare at graphs like this all day! If you work in visual effects your whole world is nodes and connections - and that is not a complicated graph ;) For someone whos not used to programming a big wall of text is going to look messy and incomprehensible too.
Just like there are best practices with code there are best practices with how you organise this kind of graph. you can usually save a subnetwork into a single node that has a clear input and output. ie, double clicking on a node will take you to another network with a clearly defined purpose. Im obviously better at these graphs than I am a programmer, but it seems to me that doing it this way actually encourages encapsulation and abstraction.
Theres also some good stuff about these graphs that I think coders can miss out on. With a graph you can use the idea of space to organise things. Our brains have a natural ability to remember where things are in space. Its like organising things on your desk, I have a pencil here , my notepad here, books in the drawer, it feels very naturall to have things laid out in space, you remember where you put them. With a graph I know that all the stuff in the top right does one task, im outputting data out the bottom etc..
It works really well when you have clear input and output. Again Im not the best programmer but I think after using these graphs for years I instantly got what people are talking about when they are promoting functional programming. I think these networks have a place where you are creating operations to do on existing things.
-Thats not what an ao pass should look like. But you shouldnt even need ao if your GI/shadows look good
- Gi should have detail to it, every realtime example is sooooo blurry
-The screen space reflections sometimeslook ok but really depends on your scene, you get all sorts of reflections in the wrong place.
-Yucky DOF without the nice bokeh on highlights and all those edge problems you get with a z-space blur.
The beauty of raytracing with a unified sampler is it makes the algorithm for each of these features you listed incredibly simple and it mixes distributes CPU/GPU time to whats important depending on that part of the image.
scene with lots of motion blur- more primary samples, less samples to gi/shadows/reflections - automatically based on how much gi/shadows you see
scene with lots of gi - more samples in gi, less for reflections etc - automatically
You can have a complex scene with reflections/gi everywhere, and then turn a heavy DOF on and get faster frame times.