just don't put materials on clusters ;) On 4 February 2016 at 00:28, Andres Stephens <[email protected]> wrote:
> Overriding cluster materials... yeah I had that discovery the other day. > Had to reshader each cluster within the pass overrides using laborous > scripts! > > Is there a work around for that? > > > -------- Original message -------- > From: Sven Constable <[email protected]> > Date: 03/02/2016 18:12 (GMT-05:00) > To: [email protected] > Subject: RE: this is the end...... > > Nothing wrong with Softimage, except NURBS/curve modeling and overriding > cluster materials in passes. :) > > > > sven > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Graham Bell > *Sent:* Wednesday, February 03, 2016 11:13 PM > *To:* [email protected] > *Subject:* Re: this is the end...... > > > > I'm saying nothing, this is getting too close to becoming a 'where did it > go all go wrong' type discussion. > > On Wed, 3 Feb 2016 at 18:49, Olivier Jeannel <[email protected]> > wrote: > > Too bad there was no "lead" with a vision for the future of SI. I'm sure > people would have follow if you guys had a produced some different ways of > working and thinking... Isn't it what happened to us with ice ? At least > for me, before XSI 7 I wouldn't believed I'd do some vector math, and 1 > month ago I wouldn't believe I'd type some criptic vex code. > > > > On Wed, Feb 3, 2016 at 7:33 PM, Luc-Eric Rousseau <[email protected]> > wrote: > > On 3 February 2016 at 09:57, Olivier Jeannel <[email protected]> > wrote: > > Luc Eric, do you mean that ice modeling developpment was in a stall > state, > > with nothing to do to enhance it because of that glass "ceiling" ? > > Yeah, ICE modelling nodes expose the operator stack's low-level > commands we always had, and we have all the design with clusters and > properties to deal with, etc, and that's limiting. > > We did have to do something to add materials IDs that by-passes this, > as you know, because you can't modify a cluster during evaluation and > therefore would not have been able set a local material (kind of a > showstopper!), but the other tools in XSI do not "see" this material > ID concept. > > ICE really shines at processing data arrays in parallel, but when it > gets to modeling, you're constructing a linear sequence > single-threaded calls to the geometry engine and you'd need a > different kind of design approach to be able to got the next level - > and then update the rest of XSI to know about those new structures. > Meshes in XSI are not fundamentally arrays of points with attributes, > it's more like there is a mesh and there is a cluster somewhere else, > and then a property which might be inherited, and then, etc.. the > graph is more like a spider web of dependancies and you can't > elegantly modify it with a low level general procedural graph. It's > designed for the operator stack. > > This whole cluster and property inheritance is not to be seen as a > "legacy burden", however, but rather it is a large part of the > elegance of XSI and what makes it easy to use. So there is a design > and engineering conflict there. I think the team pretty much did go > as far as they could in the totally reasonable implementation approach > that it adopted, except perhaps we didn't NURBS support if I recall. > > There was a similar problem with ICE Kinematic, where we could have > gone just not care about breaking all the Softimage tools and workflow > people are used to and tell people to just rebuild everything. ICE > Kinematic took instead the more conservative approach of allowing you > connecting to the existing Kinematic property rather than allowing you > to define your own arbitrary property (with maybe just a "rotateZ" > parameter). Helge had something working with that second approach, but > there would have been so much stuff to redo. > > > >
