Re: this is the end......

[Jason S]

On 02/03/16 13:33, Luc-Eric Rousseau wrote: 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. I agree. And although ICE may to this day remain one of the most approachable visual programming systems, and that it braught the guts out of 3D for a much more direct access, after having been 'spoiled' by the construction stack's straight forward, yet perhaps 'black-boxed' operators, I still wished (when ICE modeling came) that procedural modeling could also be more like "direct modeling", (or like a tree view version of the stack), where you can relatively easily & -visually- define or select what you want to somehow modify and then just as simply go ahead and modify,... but with the clarity of seeing what comes from where, which only freeform nodes layed-out in space can provide as opposed to stacks, specifically for more elaborate things.          Houdini may come to mind, but I was thinking more of something like 'regular', simple, yet reliable modeling operations, except nodebased. and although ICE can be easier to grasp than other procedural systems, It's no secret that ICE modeling can be quite a challenge when faced with the varying Per-element contexts, array types, etc... and much time can be spent on figuring out how to make connections happen, as opposed to the stack with operators, which allows to just do things very visually and directly, perhaps collapsing 50 move-points into one concactenated "OffsetComponents", and have some things remain "live". On 02/03/16 9:28, Luc-Eric Rousseau wrote: If I recall correctly, nobody really knew what to do next back then, the only opinion I had was "not these two". Motion graphics stuff, perhaps. There; softimage.uservoice.com would have been a good place to start, I wonder if management ever made a trip there, with the number one wish being 'ice-ification' of the schematic. And a revamped front-end to the schematic would no doubt have been considerably less spaghetti-like than the revamped front-end to the spaghetti-like hypergraph. @Graham; Without going too far into 'what-if' scenarios,    On 02/02/16 17:08, Graham Bell wrote:     I wish you luck with that. It was hard enough trying to sell them Soft and ICE. So Houdini could be even harder. If only had there generally been some  (or not to say  any sort of) effort on that front, other than at best, (re-)presenting it as not much more than a standalone particle plugin, .. or if only depreciation wasn't the point. But rest assured all such things is mostly water under the bridge by now. On 02/03/16 13:33, Luc-Eric Rousseau 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.