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. >
