Re: Replacing the shadertree? Possible?

[Andy Jones <andy(at)thefront.com>]

I'm curious how you guys are planning on integrating this with Mental 
Ray.  Would your node view call one shader that knows how to call its 
own sub-shaders from within the running mental ray context without 
having them predefined in the mi scene?  Or is there a way to get XSI to 
translate the shader tree natively into Mental Ray from the get-go?  The 
latter seems tricky because XSI seems to handle a lot of that type of 
stuff totally internally, and we don't have a lot of access to 
pre-render callbacks -- hence all the reliance on geometry shaders for 
modifying mental ray scenes in ways that XSI doesn't permit.  Seems like 
you might have to translate everything into a standard render tree to 
get it to work. The former seems tricky too, because it would have to 
create all the needed shader functions at initialization time, right?  
Or are you talking about something that wouldn't use Mental Ray at all?

I'd almost rather see this type of effort go into providing Blender with 
a powerful native node-based rendertree.  Either that, or you should try 
to get Softimage to provide you with a shared technology agreement so 
you can just improve/rewrite their existing rendertree (I don't know if 
they actually do that or not).  At some point, it just seems kind of 
silly to implement tools this elaborate that are 
replacements/enhancements for existing features.  Things like overrides 
and passes will be difficult to keep working, for example.  If Softimage 
wants to remain competitive, at some point, they're just going to have 
to include new features like this natively.  You can bet that whatever 
it is Discreet is going to eventually come out with will have more 
features than XSI's rendertree currently has, and not less.  That's just 
how these things go.

What's interesting to me is it actually seems like a pretty reasonable 
task to implement multiple output shaders in XSI (assuming you have 
access to the code).  Mental Ray already supports struct output.  It's 
just really tough to use it for multiple outputs because the user has to 
provide all the logic for dealing with components of the struct.  All 
XSI really needs is an implicit struct-accessor shader that can take the 
output struct as input and read data with an appropriate offset, 
depending on which output node was used for the connection.  With the 
addition of such an intermediate shader, multiple outputs could be 
provided without requiring any modification to the input logic of 
existing shaders.  And you could just ignore the intermediate 
struct-accessor shader to deal with existing single-output shaders.  The 
whole system could remain pretty much backwards-compatible.

I think mutliple inputs and conversions could be addressed in the same 
way that XSI uses layers now, whereby mixers and other intermediate 
shaders are provided .  IMHO, they just need to improve the interface 
and feature set for the layering functionality.  Messiah definitely 
seems to have the more elegant solution for this, but it's really just a 
question of designing the right widget and not letting things get too 
complex.  One thing I really hate is the fact that all the layering gets 
thrown down at the bottom of the shader.  The whole thing has a very 
"tacked-on" feel.

Keeping dead nodes in the rendertree is sort of a separate topic, since 
it's totally an interface issue.  On the one hand, it'd be nice to never 
lose a tree I made and accidentally left unconnected, but on the other 
hand, 90% of the time, I actually don't need the nodes anymore.  Maybe 
what I'd like to see happen is for dangling nodes to be global to the 
rendertree view, and not get wiped whenever I close the window or change 
materials.  So, the rendertree view would double as a sort of clipboard, 
not unlike the FXTree.  A similar feature I'd like to see even more is a 
shader node macro/phenomenon engine that would allow shader fragments to 
be saved and reused on the fly, and referenced into existing trees.  
This sort of thing could also work nicely with node preview.  Node 
preview could also function as a simple short-circuit for surface, 
whereby the material would have an implicit connection to whichever node 
is being previewed, and in a previewing context, that input would be 
rendered instead of the actual surface input.

I guess my point is that there's nothing fundamentally inconsistent with 
Mental Ray, the rendertree and these new features.  It could be extended 
to encompass them, and ultimately, that would be the best solution.  Of 
course, far be it from me to stop you from just doing it all yourself.  
If you do it, and it's better than what XSI's got, I'll use it.  And if 
there's something I feel like I can add, I'd definitely contribute.

-Andy

Thomas Helzle wrote:

> Hi Andy,
>
> superb! Does your interface rely on the Lightwave SDK or is it completely standalone?
> I'm sure this would need some further discussion and testing (especially since it shouldn't mimic XSIs tree too closely ;-) )
> I have to do some more reading on such a "base-material" or how this would be called in XSI/MR.
>
> Actually your Histogram tool brought me to the idea of external interfaces when I found out that I can't use Fcurves for shaders in XSI. :-)
> In messiah I found a pretty cool workaround for the no-Fcurves-in-Shaders problem and now I have a shader in my TLHPro package that can use the timeline/graph editor with all it's bells and whistles for "superfinetuning" of surfaces and other stuff.
>
> Let's see if we can get something going.
> Anyone else interested to join in?
>
> Thanks and best regards,
>
> Thomas Helzle
>
>
>
> On Wed, 14 Jun 2006 23:13:24 +0200, Andy Nicholas <andy(at)andynicholas.com> wrote:
>
>  
>
> > Hi Thomas,
> >
> > I started writing a node interface in OpenGL to mimic XSI's. It was only a
> > beginning, but a good place to start from. At the time I think I was looking
> > to add a node based interface to Lightwave. If we can figure out a way of
> > plugging into XSI, then I'm sure we could get this to work.
> >
> > BTW, isn't it possible to write our own materials now for XSI? Wouldn't that
> > be the best option for complete customisation of the tree?
> >
> > 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