Advanced scene description format - is there a need? back

(L) [2013/02/24] [ost by raider] [Advanced scene description format - is there a need?] Wayback!

Hi, All!

Guys, from your experience...
Is there any (practical) use of advanced features in scene description language, I mean variables, expressions, loops, conditionals etc.
In other words, is there any sense to make it a full featured programming langues designed specifically to build/describe 3D scene, or simple "static" description is "just enough" in all cases?

I've started "yet another renderer", and I still have doubts on some very basic architectural concepts. So please feel free to share your opinion, it's very valuable from me, don't want to waste time on something "cool" feature that nobody really needs.

Thank you in advance!

(L) [2013/02/24] [ost by ingenious] [Advanced scene description format - is there a need?] Wayback!

My view is that the scene is a piece of static data, which, in contrast to a program, cannot change of behave differently, because it doesn't take any input. I don't see any use for control flow (if, for) structures in describing static data. Can you come up with a scenario where a loop or a branch will be useful to describe a scene (or any static data for that matter)? You can probably achieve some data compression using such flow structures. But it seems to me that they will only complicate parsing the data.

Ability to describe control flow is needed for any "shader" programs that are attached to the scene data. But this is a whole science on its own and has so many other more complicated unresolved issues and lack of any standard whatsoever...

(L) [2013/02/25] [ost by raider] [Advanced scene description format - is there a need?] Wayback!

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.
Depending on command line options you can select different versions of the objects to be rendered (high-res/low-res).
You could organize objects into groups (layers) and render them separately using additional command line options.
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.
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?

(L) [2013/02/25] [ost by ingenious] [Advanced scene description format - is there a need?] Wayback!

These all seem like valid use cases indeed. However, they can also be accomplished via a descriptive format. I think it's better to stick to the principle of separating the data structures from the algorithms that operate on them. I don't think you want the scene to describe a rendering algorithm -- you want it do describe data that is well structured and thus suited for various types of processing.

(L) [2013/02/25] [ost by graphicsMan] [Advanced scene description format - is there a need?] Wayback!

FWIW, I agree.  I personally think it would be great to take this all the way to the level of material shaders.  With the exception of procedural texture, I think it's time we left shading languages behind [SMILEY :)]

(L) [2013/02/25] [ost by jbikker] [Advanced scene description format - is there a need?] Wayback!

It would be useful for procedural geometry. [SMILEY :)]

(L) [2013/02/25] [ost by graphicsMan] [Advanced scene description format - is there a need?] Wayback!

Yeah, I guess procedural anything...

(L) [2013/02/25] [ost by raider] [Advanced scene description format - is there a need?] Wayback!

>> graphicsMan wrote:I think it's time we left shading languages behind
Why do you think so? What's different now? I see that rendering tasks tend to become more and more complex with time (okay, not purely rendering alone, but all production pipeline getting more complicated, but rendering still big and major part of it). And that higher complexity requires higher flexibility through all the components. Not like I'm an expert in anything, just a bit surprised seeing that.

(L) [2013/02/25] [ost by graphicsMan] [Advanced scene description format - is there a need?] Wayback!

I guess it's more of a personal preference thing.  I should probably have prefaced my statement above by saying that for physically-based rendering, we should dump shading languages for material evaluation.  The reason is that it makes it very difficult to ensure the necessary properties of the material for physically-based rendering algorithms.

The material model should still allow very complex combinations of physically-plausible pieces (as long as those combinations don't break the rendering algorithm).

(L) [2013/02/26] [ost by stefan] [Advanced scene description format - is there a need?] Wayback!

IIRC Nvidia's Gelato used Python as scene description language, and in RenderMan there's RiProcedural which lets you plug in C code with calls to the RenderMan API. This is useful for production rendering, for example, one can easily integrate a custom fluid, particle or hair system into a RiProcedural without having to bake it into huge data sets. Geometry can then even be generated on demand with an adaptive level of detail.

For shading languages, I like OSL a lot and the latest version of RenderMan also has a new shader language that supporting what they call physically plausible shaders. I still like being able to go beyond physics in my render engines, when I need 100% realism I just take a photo [SMILEY ;)]