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.
