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.
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.
Can you communicate in graphs? Can they be used to express metaphors or abstractions? You've just written a wall of text in your post that someone who doesn't understand English will find messy and incomprehensible.
Visual formats are great at some things, especially in expressing concrete concepts that are perceptible. They are just not great at abstraction, which forms the basis for most of our non-trivial programming tasks.
Functional programming is quite interesting because it is not based on our linguistic capabilities, but rather a very different form of mathematical abstraction. Incidentally, many people find OO easier to grock because it leverages our intrinsic language skills.
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.
Abstraction != encapsulation. The point is about the node, not its contents. What does the node mean as a metaphor? What is it's idea?
Language is a very powerful technology that nature evolved for us. We could not have this conversation with graphs or paintings...we need words! Many programming problems are also best solved with words, though you could definitely wire something up the old fashioned way.
Can't this same criticism be made about (word-based) programming languages? Programming languages communicate the what or the how pretty well, but not the why.
I never said anything about why. Even if you are just instructing, do you care to see a wordless video or read an instruction manual? Actually it's not even that...which one is easier to write? The descriptive power of language is great when issuing imperatives; it must have been very hard to organize before language was developed 50-100 kya.
You can still communicate spatial concepts better with pictures, and maybe a hybrid approach might work, structured edited languages are very popular as vpls, but think about code with interspersed diagrams.
I think you're making a distinction that doesn't exist: lambdas are a (written) language - the have symbols, morphemes, phrasing, syntax, semantics, pretty much all the elements to define a language. Just an incredibly small and concise one.
Lambdas have definitions, but they have no communicative meaning to human beings. They have to be bound to words to provide us with a humane way of using them.
The lambda calculus is great at describing computation formally, but says nothing at all about programmer ergonomics. What we really care about is the abstraction capability of "node" or "word", the implementation is encapsulated.
-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.