Advanced scene description format - is there a need?

[cignox1]

Okay, I see your point. And I believe many others would share you opinion with you if we ask.
But I can think of some scenarios where I see conditionals useful.

1. Depending on command line options you can select different versions of the objects to be rendered (high-res/low-res).
2. You could organize objects into groups (layers) and render them separately using additional command line options.
3. Object could be assigned to multiple groups, so in addition to ordinary layers you could organize groups “production” and “previz”, where in “production” you include all high-res objects (or references to them) and in “previz” you include the key objects only excluding extra details, like, for instance, particles. Doing so you could invoke renderer supplying additional command line options to render “for production” and “for preview” from the same file. That seams to me more convenient in contrast to generating (and keeping them in sync) separate files for each layer, for previz/production and so forth.
4. Loops are less obvious, but… For example, you could iterate over some objects (e.g. particles), and load some other geometry instead of particles (e.g. plant geometry selected randomly from a list of files, making a field of grass that way). And, off course, having conditionals you would have a possibility to choose geometry from different directories depending on render target (production/draft).

How is that? Still looks useless?

Those seem to me operations which could be left to the rendering software thought (or the component designed to read the scene). An appropriate use of attributes to the elements of your scene file could be enough for most of these use cases. For example, one or more 'target' elements may collect all the geometry into different sets:

Code: Select all

<scene>
<geometry name="car1_hires">
...
</geometry>
<geometry name="car1_lowres">
...
</geometry>
<target name="hires">
<reference type="geometry" name="car1_hires"/>
</target>
<target name="lowres">
<reference type="geometry" name="car2_hires"/>
</target>
</scene>

Or instead, elements can have an additional attribute "target" with the same meaning. Once defined the target (think to debug/release in development), the appropriate elements are loaded.

[raider]

Nice thing about “physically-based” rendering is that it’s not more “physical” than any other old-school approaches. Every 3D-rendering algorithm (I exclude here some special purpose vizulization techniques like wireframe rendering, false color scientific visualization and so on) tries to approximate the way how light interacts with surface or media. Even 30-years-old flat shaded facets tries to approximate a real world process (“a light source illuminates a surface”), thus it’s also “physically-based”, just the reflection model is much more coarse and light transport lacks many important properties comparing to the those modern models and algorithms we use now.

What I’m trying to say is that “physically-based” rendering does not change the game. That’s just one more step towards to the goal of generating more plausible images (in the cases, where realistic look is required). Some internal goals of what we call “physically-based” rendering, like, for example, energy conservation, are not required by the “artist” at all. For example, physical correctness of the output image immediately brakes when you take your “caustics” or “indirect” layer and make it “look brighter” using your favorite compositing system, because that’s what the story you telling needs, or just because “it looks a bit nicer”. Once the desired result achieved, no one cares how it has been done – strictly physically correct or not.

If you insist on 100% correctness in your rendering software, your users will loose flexibility. The need to manipulate (programmatically) the way how the final image is being constructed has been there in old times of “coarse physical models” and it didn’t disappear yet, and will not disappear in the times of “more precise models” (which we used to call the times of “physically-based” rendering). So, that’s why I think the more flexibility (yet maintaining simplicity and reliability) you can provide, the better it is.

So, “shaders” and “procedurals” will not disappear, definitely.

[raider]

Those seem to me operations which could be left to the rendering software thought (or the component designed to read the scene). An appropriate use of attributes to the elements of your scene file could be enough for most of these use cases. For example, one or more 'target' elements may collect all the geometry into different sets:

Hm... That's a good idea, by the way. Thank's a lot for that tip!

[graphicsMan]

Nice thing about “physically-based” rendering is that it’s not more “physical” than any other old-school approaches. Every 3D-rendering algorithm (I exclude here some special purpose vizulization techniques like wireframe rendering, false color scientific visualization and so on) tries to approximate the way how light interacts with surface or media. Even 30-years-old flat shaded facets tries to approximate a real world process (“a light source illuminates a surface”), thus it’s also “physically-based”, just the reflection model is much more coarse and light transport lacks many important properties comparing to the those modern models and algorithms we use now.

What I’m trying to say is that “physically-based” rendering does not change the game. That’s just one more step towards to the goal of generating more plausible images (in the cases, where realistic look is required). Some internal goals of what we call “physically-based” rendering, like, for example, energy conservation, are not required by the “artist” at all. For example, physical correctness of the output image immediately brakes when you take your “caustics” or “indirect” layer and make it “look brighter” using your favorite compositing system, because that’s what the story you telling needs, or just because “it looks a bit nicer”. Once the desired result achieved, no one cares how it has been done – strictly physically correct or not.

If you insist on 100% correctness in your rendering software, your users will loose flexibility. The need to manipulate (programmatically) the way how the final image is being constructed has been there in old times of “coarse physical models” and it didn’t disappear yet, and will not disappear in the times of “more precise models” (which we used to call the times of “physically-based” rendering). So, that’s why I think the more flexibility (yet maintaining simplicity and reliability) you can provide, the better it is.

So, “shaders” and “procedurals” will not disappear, definitely.

I totally agree with you actually. I think there are many cases where these things will not disappear. I just want them to. By physically-based, I mean that the algorithms used require materials to obey reciprocity, energy conservation, etc... Definitely most shader writers using Renderman at movie studios do not worry about these things

[raider]

I totally agree with you actually. I think there are many cases where these things will not disappear. I just want them to. By physically-based, I mean that the algorithms used require materials to obey reciprocity, energy conservation, etc... Definitely most shader writers using Renderman at movie studios do not worry about these things

It's true what you say about RenderMan shader writers And if you read the Introduction chapter of Advanced Renderman you will find lots of statements confirming that, like "Experience has shown that viewers have so little intuition about the reflection situation that almost any approximation [of reflection] will do". That's because RenderMan was born not in production and for production, where time schedule is at the top priority, where director is the lord of souls.

[graphicsMan]

Right, but this is an argument for making composable "realistic" pieces whenever possible -- it means that the person designing the material has less control, but can't mess up the rendering algorithm either. I will concede that this is not possible in the general movie-style production setting, but there are lots of other cases for rendering.