[Bf-committers] From Farsthary another anouncement
joeedh at gmail.com
Fri Feb 6 21:05:19 CET 2009
On Fri, Feb 6, 2009 at 6:57 AM, Yves Poissant <ypoissant2 at videotron.ca> wrote:
> From: "joe" <joeedh at gmail.com>
> Sent: Friday, February 06, 2009 3:29 AM
>> Out of curiosity, does it really look terrible in practice, if the
>> legacy<->brdf conversions aren't always perfect?
> Typically, users who will want to do that conversion will want to use their
> material inside a physically plausible renderer. They will end up
> redesigning the material anyway. Look on BlenderArtists for the threads
> where Blender users try to use external renderers such as Yaf(a)ray, indigo,
> luxrender and such. They all invariably end up redesigning all their
> materials because the conversion did look terrible enough to be
> unacceptable. Automatic conversion need to be based on a few assumptions and
> the result is that the automatically converted materials all end up looking
> like made out of the same material, usually some kind of plastic.
Except I thought those renderers don't allow custom shaders, while we
obviously have access to the legacy shading code in blender. It seems
if you hacked together BRDF black boxes like brecht said, you'd at
least get a better result then the sort of conversions done for those
> How "good enough" is "good enough"? When you read Pixar research papers, you
> quickly realize that their "good enough" is pretty high standards. When
> pixar publish algorithms they say is "good enough", it is just a label, for
> them, to point out that the result is not strictly physically correct. It is
> a bunch of approximations designed to efficiently aproach the physical
> correctness quality. They don't try to physically simulate lighting and
> materials the way Maxwell or Fryrender do. But they carefully base their
> approximations on physical laws, and design probabilistic and statistical
> approximations that are not exact but are "good enough". Compared to this
> level of "good enough" standard, I would never dare say that an automatic
> Legacy to BRDF conversion would be "good enough" except in very rare cases.
I haven't gotten that impression from their papers, but you've
probably read more of them.
> BTW, I think Pixar is one of the best CG research labs around today. Their
> researchers are big names and very high calibers. I like that they focus on
> production solutions. They are the only ones to do that that well. And I
> thank them for publishing their results in papers and distributing their
> papers freely on the web. Before a new physically plausible render engine
> would be designed for Blender, I suggest that a good reading of Pixar papers
> should be made in order to get a good sense of how such a renderer should be
> designed to allow those kind of approximations and optimizations. It would
> be a mistake to start designing a new renderer engine based on pure
> physically rendering approaches.
Of course everyone should read pixar's papers who works on render design :)
>> I'm also wondering how a shading language would fit into
>> such a system. You couldn't really restrict people to writing pure
>> BRDF's, so it wouldn't always be correct, necessarily. It's kind of
>> like how in DSM, node materials can't always be handled correctly,
>> because they can output anything.
> It is a free world. If someone somewhere wanted to design a pseudo BRDF,
> that looks like a BRDF and can be used like a BRDF but does not behave like
> a BRDF, or is not physically plausible, then where is the problem? If
> someone wanted to experiment with some form of alien materials, then why
> not? Why couldn't imagination be released free when designing BRDF? And if
> the final render looks cool or amazing, then so much the better. And if
> someone else find the BRDF cool enough to use it then so be it.
> I think we need to start to put BRDF design out of the hands of researchers
> and into the hands of the artists. We need to push the envelope in term of
> BRDF design. And if a BRDF is really not physically plausible, I doubt the
> renderer will crash or melt down. In extreme cases, the resulting render may
> well look lika a renderer bug but the bug will be in the BRDF. Not in the
> renderer (at least, the renderer should be robust enough to elegantly handle
> weird BRDFs. But IMO, it is the intrinsic nature of a physically plausible
> render engine to be quite robust).
Ah so your saying a shading language would be used to define BRDF's?
What sort of constraints would it have? I'm just really curious, since
I think a shading language would be an important part of a redesigned
shading pipeline (at the very least, nodes would compile to it).
More information about the Bf-committers