Cheers
tim
P.S: After having had a _really_ tough show yesterday I´m not in a mood
to reply to _any other posts regarding conversation loops or ones that could
be interpreted as the serious self-overrating of a clouded mind. It´s not worth it.
----- Original Message -----
From: "Andy Jones" <andy(at)thefront.com>
To: <XSI(at)Softimage.COM>
Sent: Thursday, June 29, 2006 8:26 PM
Subject: Re: Replacing the shadertree? Possible?
> Yeah, that's the idea. What's funny is Mental Ray is already set up to do this.
> All the surface shaders in XSI are examples of shaders built around several
> building blocks. That's why I think a lot of this stuff isn't a hallucination at
> all -- Mental Ray totally supports pretty much every feature we've talked about in
> some way or another.
>
> As far as the "black box" debate goes, right now the biggest reason to do it is
> that you can't easily share intermediate calculations to be reused by other
> shaders. Even if there were a great phenomenon-generation tool, separate nodes
> doing the same calculations is an efficiency problem, especially if there's ray
> tracing involved. For example, try making a shader with two specular algorithms
> combined behind a mixer, like you would with a clear-coated surface. Turn shadows
> and some verbose messages on and notice that Mental Ray sends outs twice as many
> shadow rays. Sometimes this is addressable with multiple outputs, and other times
> it's not. In this case, it's particularly tricky because what you need to do is
> compute an array of light samples and send it to both shaders so they can attenuate
> the highlights each their own way. In a shader like T2S, this is taken care of by
> having multiple specular models you can turn on and off within the shader (though I
> actually preferred a more general "primary, secondary, tertiary" solution where you
> pick which model to use each time.) Rendering in passes alleviates some of these
> ploblems, but not all. For this reason, we structure our shading behind a fairly
> monolithic shader node. But we try to allow things to be overridden by custom
> solutions wherever it might be needed. And once the customization starts, smaller
> nodes become very useful.
>
> -Andy
>
> kim aldis wrote:
>
>>
>>>-----Original Message-----
>>>From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On
>>>Behalf Of Tim Leydecker
>>>Sent: 29 June 2006 09:48
>>>To: XSI(at)Softimage.COM
>>>Subject: Re: Replacing the shadertree? Possible?
>>>
>>>
>>>But seriously, Andy Jones had pointed out the following here:
>>>
>>>
>>>>Ultimately, what has benefited us far more is to find ways to reduce
>>>>the building blocks of the shaders to a smaller set which we can then
>>>>change dynamically and have the changes propagate through the job.
>>>>
>>
>>[kim aldis]
>>But someone has to build that reduced, smaller set in the first place. I think what
>>Andy's asking for is the best of both worlds; more of the smaller building blocks
>>but at the same time something that will allow him to pull those small building
>>blocks together himself into something simpler. Correct me if I'm wrong, Andy.
>>
>>
>>
>>---
>>Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
>>unsubscribe xsi
>>
>>
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
