[Bf-committers] From Farsthary another anouncement

joe joeedh at gmail.com
Wed Feb 11 12:26:19 CET 2009

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?).


More information about the Bf-committers mailing list