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 <sixsi_l...@imagefront.de> Date: 03/02/2016 18:12 (GMT-05:00) To: softimage@listproc.autodesk.com Subject: RE: this is the end...... Nothing wrong with Softimage, except NURBS/curve modeling and overriding cluster materials in passes. :) sven From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Graham Bell Sent: Wednesday, February 03, 2016 11:13 PM To: softimage@listproc.autodesk.com 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 <facialdel...@gmail.com> 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 <luceri...@gmail.com> wrote: On 3 February 2016 at 09:57, Olivier Jeannel <facialdel...@gmail.com> 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.
