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