[Bf-committers] From Farsthary another anouncement

[joe]

On Tue, Feb 10, 2009 at 6:27 PM, Yves Poissant <ypoissant2 at videotron.ca> wrote:
> From: "joe" <joeedh at gmail.com>
> Sent: Tuesday, February 10, 2009 2:10 AM
>
> Yup. That is what I think too. IMO, the solution is to have like 3 rendering
> *environments*: A legacy render environment, a toon (or NPR) render
> environment and a physical render environment. When the end user works in
> the physical render environment, he can set its lights and material using
> physical descriptions. When working in the NPR environment, then all NPR
> lighting and material features are available, etc. This would make selecting
> material much simples and much less confusing and would prevent mixing
> setups that are not designed to work properly together anyway.
>
This could even be presented to the user as different render layer
types, that he could combine in the compositor.  That's a great idea.
All three render types could even spit out all their pixel samples
into render passes, which could be combined in the compositor as well
(e.g. if you want a totally nonphysical cartoon character in a
physical scene).

I like this idea.  With three different environments, you could
optimize each one of them properly.

> That said, there are already several people working on render engines of all
> kind. From NPR to OpenGL emulation to physically plausible to unbiased
> renderers. So why replicate all this effort in Blender. In the end, if
> Blender had the complete API to allow plugin those external renderers, then
> development efforts could be spent on other aspect for which there is little
> outside efforts such as the whole animation support system.

This sounds like an interesting idea.  We could split our legacy
shading code into a DSO, and plug it into legacy-compatible renderers.
 Render plugins could define their own material types (legacy
materials would just be another material type).  Back to my render
layer idea, each object could have a different material for each
renderer that includes it.

>
>> This probably could even be done
>> in a way to always get smooth results (like approximate AO), which
>> would be useful for animations
>
> The way I see it, there will always be people wanting to experiment with
> rendering engines. The lagacy renderer provides just that: A lot a knobs
> that can be tweaked and enough rope to hang oneself.

Yeah there is way too many options, and it's hard to manage them
without presets.

>
>> Often times, artists prefer solutions that aren't as physically
>> correct, but are easier to use, for various reasons (speed, smoothness
>> of result, more tweak ability, better matches a cartoony look, etc).
>> Big Buck Bunny, for example, used approximate AO (I can't remember the
>> non-blender term for this for the life of me, it was in gpu gems 1,
>> one of the sample chapters I think), because it produced a smooth
>> result, necessary for animation.
>
> There's always been a tradeoff between artist spending time setting up
> materials and lights (in addition to more fun stuff like animating or posing
> or creatively placing lights in a scene), and render time.
>

Yeah.  Sometimes people prefer the extra control, and sometimes they
just turn on AO and a few simple material/lights (all of 5 minutes of
work) and call it good enough. :)  Physically-plausible material types
could really be helpful here, I think.

> A lot of users just want a render. Period. They are not at a point where
> they can appreciate realisticness and its subtleties. They would like to
> render a full movie in an evening. As long as it moves and there are lights
> and shadows, then all is fine.
>
> As users get more experienced, they want good looking lights and materials.
> And this requires a lot of time spent at setting the myriad of lights and
> setting the materials. And once this is done, continuously returning to it,
> tweaking the materials to correct idiosyncratic behavior when the lighting
> environment changes. Unfortunately, this can suck a lot of time. Time that
> would be better spent on truely creative stuff like posing the characters,
> choosing dramatic light placements, finding proper camera POV, animating,
> facial expressions, etc.
>
> We are getting to a point where CPU time is cheaper than human time for that
> sort of chores. Instead of spending days at fine tuning the multitude of
> parameters for materials. just use some physically designed presets, tweak a
> little according to some well defined and easy to understand physicall rules
> and let the computer spend the time rendering that stuff. And then, while
> the computer renders a sequence, the artist can enjoy tweaking the
> subtleties of a character expression, gesture and timing.

It does sound as if modern ray tracer design is getting to the point
where that's possible.  That's so awesome!  Not being shackled to a
scanline system. . .that'd be cool.

I agree, I think lots of people will be just like you say.  On the
other hand, a lot of people will still want tons of control over their
render, especially if they're not going for a physically-accurate
look.  This is why supporting both in separate systems is such a cool
idea.  Or what you said about render plugins, that's even better.  I
also really like the idea of being able to have multiple render layers
with different renderers, that you combine in the compositor.

>
> Personally, I find the artistic race for photorealism graal a little bit
> futile because at some point, when all models and renders will look
> photoreal, what's left for distinguishing an artist style from another
> artist style? And frankly, I'm kind of tired of seeing arch-vis after
> arch-vis of photoreal interior designs using VRay and like. It really gets
> boring. What I really appreciate, though, are artists who have developped a
> very personal style.
>
> But there is no denying that photorealism is everywhere and unavoidable.
> There is no denying that the push toward photorealism will continue and that
> every 3D application out there ought to support that rendering paradigm.
>
> I don't believe, though, that physically based material definition goes
> against the grain of artistic style development. I do not equate physically
> based materials and lights with photorealism. They just don't equate.
> Physically based material definition already allows for a lot of freedom and
> creativity in designing new materials. But the style is mainly in the
> design. The character designs, their environment design, the situation they
> have to deal with, their reactions, etc.

Ah I disagree.  The style has a lot to do with the way the materials
look, and even the compositing.

>
> Physically based material definition makes the artist life easier because
> the material responds to well known physical laws. We already know,
> intuitively, what to expect from this and that material. Our problems, right
> now is that the legacy CG material model is completely had-hoc and the
> artist have to learn a new, unintuitive, mental model of its behavior. A
> mental model that may breaks down as soon as several features are brought
> together.

I agree with you there.  The "flexibility" I worry about supporting,
I'm starting to think could probably be done in a better way then
that.  Perhaps a scanline renderer that supports a generic shading
language (with less restrictions then a physically-plausible one),
then you build different paradigms of working on top of it, none of
them based on legacy models (perhaps psuedo-BRDF). . .ah wait.  This
is what renderman renderers are for, isn't it.

>
> I whent a little too deeply technical into this BRDF vs legacy discussion.
> I'm not even sure there are plans to refactor the renderer. I mainly liked
> to point the developers attention to the field of physically based
> rendering. It is an important development going on and should not be
> overlooked. And even if there are no plans (or nobody available) for
> refactoring the renderer, it may be a good idea to be aware of this field
> and keep that in mind when implementing new features that are related to
> material and lights.

You've certainly succeeded there! I'm certainly going to think about
this, perhaps read some papers, etc, for the next long while (even
though I won't have time for implementing any of  this in the
foreseeable future).  I wouldn't be surprise if people start
experimenting with your ideas (or already have started).

Thanks a lot for this information.  It's very valuable.  I'm sure lots
of us will refer back to what you've said for a long time, since it's
a good amount of practical information, from someone who uses this
stuff in production work (ah if I remember right, you do don't you?).

Joe