"Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
289 views
Skip to first unread message
Andy Jones
Mar 15, 2014, 1:00:56 PM3/15/14
to soft...@listproc.autodesk.com
On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau <chris.v...@autodesk.com> wrote:
Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset?
Nope
David Barosin
Mar 15, 2014, 1:14:56 PM3/15/14
to xsi
"Nope" sounds about right.
Chris will all due respect. It's like asking how many letters to you need to say your favorite words.
ICE is an established visual language for the Softimage folk. You can program with it and it reaches far beyond just simulation.
Will Robertson
Mar 15, 2014, 1:15:15 PM3/15/14
to soft...@listproc.autodesk.com
Jonah Friedman
Mar 15, 2014, 1:17:10 PM3/15/14
to soft...@listproc.autodesk.com
Nope.
todd peleg
Mar 15, 2014, 1:21:00 PM3/15/14
to soft...@listproc.autodesk.com
Angel Negron
Mar 15, 2014, 1:26:40 PM3/15/14
to soft...@listproc.autodesk.com
NOPE
From: todda...@gmail.com
Date: Sat, 15 Mar 2014 13:21:00 -0400
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
To: soft...@listproc.autodesk.com
From: todda...@gmail.com
Date: Sat, 15 Mar 2014 13:21:00 -0400
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
To: soft...@listproc.autodesk.com
Cesar Saez
Mar 15, 2014, 3:05:10 PM3/15/14
to soft...@listproc.autodesk.com
On a more constructive note:
- Visual debugging tools, I really miss to be able to show values between connections (vectors, matrices).
- Abstract types? it's kinda embarrasing have to use a plusMinusAverage node to emulate a vector constant in maya.
- Basic math nodes? like trigonometric functions, modulo, exponential... look at any programming library (python math module could be a good starting point) and implement those.
- Raycasting nodes and some equivalent to locations (or any mechanism to interpolate data using baricentric coordinates).
- Sets and/or arrays, be able to drive a stream of data as a whole is really what makes ICE special for me.
Of course there will be people asking for everything that makes the ICE helpful and that's fine, but if you have to start somewhere I would take a look at that list.
Cheers!
- Visual debugging tools, I really miss to be able to show values between connections (vectors, matrices).
- Abstract types? it's kinda embarrasing have to use a plusMinusAverage node to emulate a vector constant in maya.
- Basic math nodes? like trigonometric functions, modulo, exponential... look at any programming library (python math module could be a good starting point) and implement those.
- Raycasting nodes and some equivalent to locations (or any mechanism to interpolate data using baricentric coordinates).
- Sets and/or arrays, be able to drive a stream of data as a whole is really what makes ICE special for me.
Of course there will be people asking for everything that makes the ICE helpful and that's fine, but if you have to start somewhere I would take a look at that list.
Cheers!
Bradley Gabe
Mar 15, 2014, 3:31:08 PM3/15/14
to soft...@listproc.autodesk.com
This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking.
It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application.
Everyone who ever looked at ICE from the outside, without ever going into the daily battle that is production, simply saw it as a particle system (and maybe tipped their hat to it's clever ability to multiprocesses). And despite the SI community's repeated insistence ICE was far more important than that, a particle system is precisely how it was marketed by Autodesk, providing continuing evidence that Autodesk didn't know what they actually had, didn't want to listen to the people who were actually using it... or didn't care.
In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system.
In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system.
It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived?
Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code.
If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible!
-Bradley
Sent from my iPhone
Mirko Jankovic
Mar 15, 2014, 3:55:13 PM3/15/14
to soft...@listproc.autodesk.com
Bradley you nailed it with this one, and also points out what really AD system does look like.. bunch of bullet points of separate marketing ready features that looks nice on list when you showing it to sales.
The matter that those separate features have little to non meaningful communications one with other... communication that actually makes workflow.. that doesn't mean much I guess.
Francisco Criado
Mar 15, 2014, 4:07:34 PM3/15/14
to soft...@listproc.autodesk.com
Agree with Bradley, +1
Ahmidou Lyazidi
Mar 15, 2014, 4:10:02 PM3/15/14
to soft...@listproc.autodesk.com
Bradley is soooo right, I'm quite surprise about this question, it doesn't mean anything at all.
It's not really about the nodes, it's how the whole system work.-----------------------------------------------
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos
http://www.cappuccino-films.com
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos
http://www.cappuccino-films.com
Angel Negron
Mar 15, 2014, 4:10:33 PM3/15/14
to soft...@listproc.autodesk.com
Agree with Bradley, +1
nailed it
Date: Sat, 15 Mar 2014 17:07:34 -0300
Date: Sat, 15 Mar 2014 17:07:34 -0300
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
David Gallagher
Mar 15, 2014, 4:11:31 PM3/15/14
to soft...@listproc.autodesk.com
You wrote all that on your phone? :)
Bk
Mar 15, 2014, 4:16:36 PM3/15/14
to soft...@listproc.autodesk.com
Bradley has expressed exactly, what I have been trying to compose over the last week. Yet better than I could.
1 Autodesk either never room the time to understand ICE,
2 or kept it under wraps in order to not let it steal the thunder from Bifrost in the future. Weird decision, as they could have used it as a taster to get people excited.
3 Or of course, there remains the possibility they are just a bit simple and confused and deserve our sympathy.
Ironically, the team that actually Made ICE are onto what could be seen as "ICE version 2 standalone or in any package". Fabric Engine. (cue "binary sunset on tatooine" music)
Ironically, the team that actually Made ICE are onto what could be seen as "ICE version 2 standalone or in any package". Fabric Engine. (cue "binary sunset on tatooine" music)
I have no doubt that the successor to ICE is the future. I do actually thing that Bifrost is heading there, but if option 3 (above) is not the case, I'd be nervous, to say the least. Because I believe Fabric is going to get in there first by a long shot.
And we SI users have learnt the hard way, about how important it is to get tools into studios and pipelines first.
Nick Martinelli
Mar 15, 2014, 4:59:00 PM3/15/14
to soft...@listproc.autodesk.com
I agree 100% with what everyone is saying.
I would like to add that ICE isn't a point and click system, so it's impossible to give a universal list. There isn't one way to do anything, just ways that work. Two artists can have a similar result with drastically different ICE trees.
I would like to add that ICE isn't a point and click system, so it's impossible to give a universal list. There isn't one way to do anything, just ways that work. Two artists can have a similar result with drastically different ICE trees.
Imagine that you ask two people to write an equation that equals 10. One might say 7+3 and the other might go with 40/4, both are correct, they just got there different ways.
Andy Jones
Mar 15, 2014, 5:11:35 PM3/15/14
to soft...@listproc.autodesk.com
Bingo.
Meng-Yang Lu
Mar 15, 2014, 5:26:28 PM3/15/14
to soft...@listproc.autodesk.com
Heh, it'd be less work just undo-ing the EOL decision instead of reinventing the round wheel to a square one.
-Lu
Eric Thivierge
Mar 15, 2014, 5:31:54 PM3/15/14
to soft...@listproc.autodesk.com
On Sat, Mar 15, 2014 at 5:26 PM, Meng-Yang Lu <ntmo...@gmail.com> wrote:
Heh, it'd be less work just undo-ing the EOL decision instead of reinventing the round wheel to a square one.
But how would that look to stock holders / board members? Confidence would plummet hard. It would do more damage then just sticking with it. Business-wise, there is no going back.
olivier jeannel
Mar 15, 2014, 5:43:44 PM3/15/14
to soft...@listproc.autodesk.com
Get data does 40%
Set data does another 40%
with 20% of various nodes in between
....
Ice is not exactly an assortment of chocolate sweets...
LOL
Set data does another 40%
with 20% of various nodes in between
....
Ice is not exactly an assortment of chocolate sweets...
LOL
Jason S
Mar 15, 2014, 11:27:01 PM3/15/14
to soft...@listproc.autodesk.com
Hi Eric, of course coming back on a decision can have some effect of
board-member/stockholder confidence.
(mostly (or exclusively) looking at daily ups-and downs)
Yet considering how "Public Perception" can be the main underlying driver of -confidence-,
and that in turn being the main driver of basically -everything- in an organisation, ..
(the whole purpose of "marketing" (sometimes taking-up 60% of entire budjets) is all around "perception")
The effects of persisting on a decision or actions that may widely be perceived as "not right",
( especailly when it's true (!) )
can absolutely far outweigh or dwarf the effects of reconsideration of such actions/decisions.
Shaken confidence can bring any organisation to it's knees,
regardless of it's size in a matter of "seconds" or days.
ie; only when a small (almost insignificant) textile factory crumbled,
did large manufactuers start spending billions in public campaigns, armies of lawyers,
(or a less insignificant % of revenue) on actually real reforms,
in respects to minimum standards in their "sweatshop" operations.
Resulting in some actions being only superficial,
others temporary t'il things blew over, and others more genuine.
Yet the only thing that motivated such actions was -public awareness-.
..
So what can make large machines turn around when exactly that ends up actually happening,
is when certain abstract fuzzy lines have been crossed,
thus affecting perception, therefore -confidence-.
While sometimes those reversals are from actual internal people waking,
more or less coming to grips with their moral compass,
and/or in other cases, merely or mostly just not to look too bad while plastering their stuff "non-sweatshop-made",
with all sorts of varying degrees in between...
(machines are run by regular everyday people after all)
.. yet the fact remains that, when something is widely perceived as wrong or unfair,
especially when you can't really hide, mask or distract attention,
is when the *RIGHT* thing has indeed the best chance of actually happening.
(mostly (or exclusively) looking at daily ups-and downs)
Yet considering how "Public Perception" can be the main underlying driver of -confidence-,
and that in turn being the main driver of basically -everything- in an organisation, ..
(the whole purpose of "marketing" (sometimes taking-up 60% of entire budjets) is all around "perception")
The effects of persisting on a decision or actions that may widely be perceived as "not right",
( especailly when it's true (!) )
can absolutely far outweigh or dwarf the effects of reconsideration of such actions/decisions.
Shaken confidence can bring any organisation to it's knees,
regardless of it's size in a matter of "seconds" or days.
ie; only when a small (almost insignificant) textile factory crumbled,
did large manufactuers start spending billions in public campaigns, armies of lawyers,
(or a less insignificant % of revenue) on actually real reforms,
in respects to minimum standards in their "sweatshop" operations.
Resulting in some actions being only superficial,
others temporary t'il things blew over, and others more genuine.
Yet the only thing that motivated such actions was -public awareness-.
..
So what can make large machines turn around when exactly that ends up actually happening,
is when certain abstract fuzzy lines have been crossed,
thus affecting perception, therefore -confidence-.
While sometimes those reversals are from actual internal people waking,
more or less coming to grips with their moral compass,
and/or in other cases, merely or mostly just not to look too bad while plastering their stuff "non-sweatshop-made",
with all sorts of varying degrees in between...
(machines are run by regular everyday people after all)
.. yet the fact remains that, when something is widely perceived as wrong or unfair,
especially when you can't really hide, mask or distract attention,
is when the *RIGHT* thing has indeed the best chance of actually happening.
Ed Manning
Mar 15, 2014, 11:29:12 PM3/15/14
to soft...@listproc.autodesk.com
Yeah. The question itself, as well-intentioned as it may be, suggests such a fundamental misapprehension of ICE and why it's useful that it seems to confirm the worst fears of many of us.
It wasn't a pile of golden eggs, it was the goose. And now it's dead.
Jason S
Mar 16, 2014, 12:57:42 AM3/16/14
to soft...@listproc.autodesk.com
Hi, while it was merely to prove a point, I'd like to point out that
the intent was not to equate prematurely retiring software with
practicing poor working standards. Had there been an edit button, I
would have accordingly edited it.
thx
thx
Emilio Hernandez
Mar 16, 2014, 9:10:59 AM3/16/14
to soft...@listproc.autodesk.com
Nope
And Bradley put it so well that there is nothing else to say.
At this moment a U turn is the best Autodesk can do.
Jordi Bares
Mar 16, 2014, 2:04:20 PM3/16/14
to soft...@listproc.autodesk.com
Its easily done, you fire the guy that took the decision and reinstall confidence on both parties. Business 101
Jordi Bares
Emilio Hernandez
Mar 16, 2014, 2:12:29 PM3/16/14
to soft...@listproc.autodesk.com
Or the guy that in the meeting raised his hand and said "why we don't kill Softimage..."
Chris Vienneau
Mar 16, 2014, 2:40:11 PM3/16/14
to soft...@listproc.autodesk.com
The topic was bringing over ICE graphs into Bifrost. We will not show the Bifrost graph in the first version but if you click here (https://www.fxguide.com/featured/bifrost-the-return-of-the-naiad-team-with-a-bridge-to-ice/) you can see what we showed at Siggraph last year in terms of the graph.
Let me ask a very open question to Paul Doyle. Paul when people say the creators of ICE work at Fabric do you agree? Many on the Bifrost team would argue they were just as much a part of it than the hard working guys at Fabric. I think it is great that there are two companies following this path and that will only mean competition which is a good thing but I do believe there are many people who came together and not just 1-2 who drove the whole thing.
ICE is a set of base function nodes built into higher order operations (compounds) with a super slick visual programming language and strong ways of querying scene data. Given we have the source code of ICE we can put in nodes that match 1 for 1 the code instead of reverse engineering it which is usually where things fall apart in terms of migration tools.
We can even open this up to the fabric guys who are here so of these node types which do you use the most on a daily basis and which do not use or find need work:
Array<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Array.htm>
* Color<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Color.htm>
* Constant<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Constant.htm>
* Conversion<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Conversion.htm>
* Data Access<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_DataAccess.htm>
* Debugging<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Debugging.htm>
* Execution<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Execution.htm>
* Geometry Queries<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_GeometryQueries.htm>
* Math Basic<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathBasic.htm>
* Math Comparison<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathComparison.htm>
* Math Logic<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathLogic.htm>
* Math Matrix<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathMatrix.htm>
* Math Statistics<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathStatistics.htm>
* Math Trigonometry<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathTrigonometry.htm>
* Math Vector<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathVector.htm>
* Point Cloud<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_PointCloud.htm>
* Rotation<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-DCAC50A6-C3FD-47D0-8F5A-6A161EBD3E68.htm>
* Simulation<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Simulation.htm>
* String<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/iceref_nodes_String.htm>
* Topology<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-FBD0D4AB-F90F-4C2C-A3D5-2EA677678349.htm>
* Crowds<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-1D883E93-17DD-4CB2-AA3D-C50A33E2F7FF.htm>
* Syflex Simul<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-96B37421-0112-41FE-8255-B8D7EE37AE63.htm>
* Syflex Force<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-3CD07777-CE7F-4EF9-9E5C-A1A0C35D2B14.htm>
* Syflex Collision<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-9CDA70F0-F9F3-4897-8698-72A9B8878926.htm>
* Syflex Constraint<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-1D551989-2D9C-48F1-A099-8511B514B535.htm>
Thx.
cv/
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Nick Martinelli [ni...@nickmartinelli.net]
Sent: Saturday, March 15, 2014 4:59 PM
To: soft...@listproc.autodesk.com
On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau <chris.v...@autodesk.com<mailto:chris.v...@autodesk.com>> wrote:
Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset?
Nope
--
Nick Martinelli
(201) 424 - 6518
www.nickMartinelli.net<http://www.nickMartinelli.net>
ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net>
Let me ask a very open question to Paul Doyle. Paul when people say the creators of ICE work at Fabric do you agree? Many on the Bifrost team would argue they were just as much a part of it than the hard working guys at Fabric. I think it is great that there are two companies following this path and that will only mean competition which is a good thing but I do believe there are many people who came together and not just 1-2 who drove the whole thing.
ICE is a set of base function nodes built into higher order operations (compounds) with a super slick visual programming language and strong ways of querying scene data. Given we have the source code of ICE we can put in nodes that match 1 for 1 the code instead of reverse engineering it which is usually where things fall apart in terms of migration tools.
We can even open this up to the fabric guys who are here so of these node types which do you use the most on a daily basis and which do not use or find need work:
Array<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Array.htm>
* Color<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Color.htm>
* Constant<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Constant.htm>
* Conversion<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Conversion.htm>
* Data Access<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_DataAccess.htm>
* Debugging<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Debugging.htm>
* Execution<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Execution.htm>
* Geometry Queries<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_GeometryQueries.htm>
* Math Basic<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathBasic.htm>
* Math Comparison<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathComparison.htm>
* Math Logic<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathLogic.htm>
* Math Matrix<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathMatrix.htm>
* Math Statistics<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathStatistics.htm>
* Math Trigonometry<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathTrigonometry.htm>
* Math Vector<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_MathVector.htm>
* Point Cloud<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_PointCloud.htm>
* Rotation<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-DCAC50A6-C3FD-47D0-8F5A-6A161EBD3E68.htm>
* Simulation<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/icenode_ref_Simulation.htm>
* String<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/iceref_nodes_String.htm>
* Topology<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-FBD0D4AB-F90F-4C2C-A3D5-2EA677678349.htm>
* Crowds<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-1D883E93-17DD-4CB2-AA3D-C50A33E2F7FF.htm>
* Syflex Simul<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-96B37421-0112-41FE-8255-B8D7EE37AE63.htm>
* Syflex Force<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-3CD07777-CE7F-4EF9-9E5C-A1A0C35D2B14.htm>
* Syflex Collision<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-9CDA70F0-F9F3-4897-8698-72A9B8878926.htm>
* Syflex Constraint<http://download.autodesk.com/global/docs/softimage2014/en_us/userguide/files/GUID-1D551989-2D9C-48F1-A099-8511B514B535.htm>
Thx.
cv/
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Nick Martinelli [ni...@nickmartinelli.net]
Sent: Saturday, March 15, 2014 4:59 PM
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
I agree 100% with what everyone is saying.
I would like to add that ICE isn't a point and click system, so it's impossible to give a universal list. There isn't one way to do anything, just ways that work. Two artists can have a similar result with drastically different ICE trees.
Imagine that you ask two people to write an equation that equals 10. One might say 7+3 and the other might go with 40/4, both are correct, they just got there different ways.
That's the beauty of ICE. It's versatility and efficiency to allow the artist to work the way they want to without sacrificing quality and production time.
I would like to add that ICE isn't a point and click system, so it's impossible to give a universal list. There isn't one way to do anything, just ways that work. Two artists can have a similar result with drastically different ICE trees.
Imagine that you ask two people to write an equation that equals 10. One might say 7+3 and the other might go with 40/4, both are correct, they just got there different ways.
That's the beauty of ICE. It's versatility and efficiency to allow the artist to work the way they want to without sacrificing quality and production time.
On Sat, Mar 15, 2014 at 4:16 PM, Bk <pa...@bustykelp.com<mailto:pa...@bustykelp.com>> wrote:
Bradley has expressed exactly, what I have been trying to compose over the last week. Yet better than I could.
1 Autodesk either never room the time to understand ICE,
2 or kept it under wraps in order to not let it steal the thunder from Bifrost in the future. Weird decision, as they could have used it as a taster to get people excited.
3 Or of course, there remains the possibility they are just a bit simple and confused and deserve our sympathy.
Ironically, the team that actually Made ICE are onto what could be seen as "ICE version 2 standalone or in any package". Fabric Engine. (cue "binary sunset on tatooine" music)
I have no doubt that the successor to ICE is the future. I do actually thing that Bifrost is heading there, but if option 3 (above) is not the case, I'd be nervous, to say the least. Because I believe Fabric is going to get in there first by a long shot.
And we SI users have learnt the hard way, about how important it is to get tools into studios and pipelines first.
Bradley has expressed exactly, what I have been trying to compose over the last week. Yet better than I could.
1 Autodesk either never room the time to understand ICE,
2 or kept it under wraps in order to not let it steal the thunder from Bifrost in the future. Weird decision, as they could have used it as a taster to get people excited.
3 Or of course, there remains the possibility they are just a bit simple and confused and deserve our sympathy.
Ironically, the team that actually Made ICE are onto what could be seen as "ICE version 2 standalone or in any package". Fabric Engine. (cue "binary sunset on tatooine" music)
I have no doubt that the successor to ICE is the future. I do actually thing that Bifrost is heading there, but if option 3 (above) is not the case, I'd be nervous, to say the least. Because I believe Fabric is going to get in there first by a long shot.
And we SI users have learnt the hard way, about how important it is to get tools into studios and pipelines first.
On 15 Mar 2014, at 19:55, Mirko Jankovic <mirkoj....@gmail.com<mailto:mirkoj....@gmail.com>> wrote:
Bradley you nailed it with this one, and also points out what really AD system does look like.. bunch of bullet points of separate marketing ready features that looks nice on list when you showing it to sales.
The matter that those separate features have little to non meaningful communications one with other... communication that actually makes workflow.. that doesn't mean much I guess.
Bradley you nailed it with this one, and also points out what really AD system does look like.. bunch of bullet points of separate marketing ready features that looks nice on list when you showing it to sales.
The matter that those separate features have little to non meaningful communications one with other... communication that actually makes workflow.. that doesn't mean much I guess.
On Sat, Mar 15, 2014 at 8:31 PM, Bradley Gabe <with...@gmail.com<mailto:with...@gmail.com>> wrote:
This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking.
It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application.
Everyone who ever looked at ICE from the outside, without ever going into the daily battle that is production, simply saw it as a particle system (and maybe tipped their hat to it's clever ability to multiprocesses). And despite the SI community's repeated insistence ICE was far more important than that, a particle system is precisely how it was marketed by Autodesk, providing continuing evidence that Autodesk didn't know what they actually had, didn't want to listen to the people who were actually using it... or didn't care.
In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system.
It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived?
Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code.
If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible!
-Bradley
Sent from my iPhone
On Mar 15, 2014, at 12:00 PM, Andy Jones <andy....@gmail.com<mailto:andy....@gmail.com>> wrote:
This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking.
It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application.
Everyone who ever looked at ICE from the outside, without ever going into the daily battle that is production, simply saw it as a particle system (and maybe tipped their hat to it's clever ability to multiprocesses). And despite the SI community's repeated insistence ICE was far more important than that, a particle system is precisely how it was marketed by Autodesk, providing continuing evidence that Autodesk didn't know what they actually had, didn't want to listen to the people who were actually using it... or didn't care.
In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system.
It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived?
Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code.
If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible!
-Bradley
Sent from my iPhone
On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau <chris.v...@autodesk.com<mailto:chris.v...@autodesk.com>> wrote:
Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset?
Nope
--
Nick Martinelli
(201) 424 - 6518
ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net>
Emilio Hernandez
Mar 16, 2014, 2:59:49 PM3/16/14
to soft...@listproc.autodesk.com
Correct me if I am wrong but Bifrost at this moment seems to me that it is only for fluid sim from that article. What about the rest that ICE is for?
Francisco Criado
Mar 16, 2014, 3:17:59 PM3/16/14
to soft...@listproc.autodesk.com
Chris, seriously? yo ad want it all right?
F.
Chris Vienneau
Mar 16, 2014, 3:48:15 PM3/16/14
to soft...@listproc.autodesk.com
? ad ?
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Francisco Criado [malcr...@gmail.com]
Sent: Sunday, March 16, 2014 3:17 PM
From: softimag...@listproc.autodesk.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx> [softimag...@listproc.autodesk.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx>] on behalf of Nick Martinelli [ni...@nickmartinelli.net<https://connect.autodesk.com/owa/UrlBlockedError.aspx>]
On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau <chris.v...@autodesk.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx><mailto:chris.v...@autodesk.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx>>> wrote:
Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset?
Nope
--
Nick Martinelli
(201) 424 - 6518
www.nickMartinelli.net<http://www.nickMartinelli.net><http://www.nickMartinelli.net>
ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net<https://connect.autodesk.com/owa/UrlBlockedError.aspx>>
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Francisco Criado [malcr...@gmail.com]
Sent: Sunday, March 16, 2014 3:17 PM
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Chris, seriously? yo ad want it all right?
F.
F.
Sent: Saturday, March 15, 2014 4:59 PM
To: soft...@listproc.autodesk.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx>
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
I agree 100% with what everyone is saying.
I would like to add that ICE isn't a point and click system, so it's impossible to give a universal list. There isn't one way to do anything, just ways that work. Two artists can have a similar result with drastically different ICE trees.
Imagine that you ask two people to write an equation that equals 10. One might say 7+3 and the other might go with 40/4, both are correct, they just got there different ways.
That's the beauty of ICE. It's versatility and efficiency to allow the artist to work the way they want to without sacrificing quality and production time.
I agree 100% with what everyone is saying.
I would like to add that ICE isn't a point and click system, so it's impossible to give a universal list. There isn't one way to do anything, just ways that work. Two artists can have a similar result with drastically different ICE trees.
Imagine that you ask two people to write an equation that equals 10. One might say 7+3 and the other might go with 40/4, both are correct, they just got there different ways.
That's the beauty of ICE. It's versatility and efficiency to allow the artist to work the way they want to without sacrificing quality and production time.
On Sat, Mar 15, 2014 at 4:16 PM, Bk <pa...@bustykelp.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx><mailto:pa...@bustykelp.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx>>> wrote:
Bradley has expressed exactly, what I have been trying to compose over the last week. Yet better than I could.
1 Autodesk either never room the time to understand ICE,
2 or kept it under wraps in order to not let it steal the thunder from Bifrost in the future. Weird decision, as they could have used it as a taster to get people excited.
3 Or of course, there remains the possibility they are just a bit simple and confused and deserve our sympathy.
Ironically, the team that actually Made ICE are onto what could be seen as "ICE version 2 standalone or in any package". Fabric Engine. (cue "binary sunset on tatooine" music)
I have no doubt that the successor to ICE is the future. I do actually thing that Bifrost is heading there, but if option 3 (above) is not the case, I'd be nervous, to say the least. Because I believe Fabric is going to get in there first by a long shot.
And we SI users have learnt the hard way, about how important it is to get tools into studios and pipelines first.
Bradley has expressed exactly, what I have been trying to compose over the last week. Yet better than I could.
1 Autodesk either never room the time to understand ICE,
2 or kept it under wraps in order to not let it steal the thunder from Bifrost in the future. Weird decision, as they could have used it as a taster to get people excited.
3 Or of course, there remains the possibility they are just a bit simple and confused and deserve our sympathy.
Ironically, the team that actually Made ICE are onto what could be seen as "ICE version 2 standalone or in any package". Fabric Engine. (cue "binary sunset on tatooine" music)
I have no doubt that the successor to ICE is the future. I do actually thing that Bifrost is heading there, but if option 3 (above) is not the case, I'd be nervous, to say the least. Because I believe Fabric is going to get in there first by a long shot.
And we SI users have learnt the hard way, about how important it is to get tools into studios and pipelines first.
On 15 Mar 2014, at 19:55, Mirko Jankovic <mirkoj....@gmail.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx><mailto:mirkoj....@gmail.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx>>> wrote:
Bradley you nailed it with this one, and also points out what really AD system does look like.. bunch of bullet points of separate marketing ready features that looks nice on list when you showing it to sales.
The matter that those separate features have little to non meaningful communications one with other... communication that actually makes workflow.. that doesn't mean much I guess.
Bradley you nailed it with this one, and also points out what really AD system does look like.. bunch of bullet points of separate marketing ready features that looks nice on list when you showing it to sales.
The matter that those separate features have little to non meaningful communications one with other... communication that actually makes workflow.. that doesn't mean much I guess.
On Sat, Mar 15, 2014 at 8:31 PM, Bradley Gabe <with...@gmail.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx><mailto:with...@gmail.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx>>> wrote:
This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking.
It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application.
Everyone who ever looked at ICE from the outside, without ever going into the daily battle that is production, simply saw it as a particle system (and maybe tipped their hat to it's clever ability to multiprocesses). And despite the SI community's repeated insistence ICE was far more important than that, a particle system is precisely how it was marketed by Autodesk, providing continuing evidence that Autodesk didn't know what they actually had, didn't want to listen to the people who were actually using it... or didn't care.
In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system.
It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived?
Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code.
If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible!
-Bradley
Sent from my iPhone
On Mar 15, 2014, at 12:00 PM, Andy Jones <andy....@gmail.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx><mailto:andy....@gmail.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx>>> wrote:
This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking.
It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application.
Everyone who ever looked at ICE from the outside, without ever going into the daily battle that is production, simply saw it as a particle system (and maybe tipped their hat to it's clever ability to multiprocesses). And despite the SI community's repeated insistence ICE was far more important than that, a particle system is precisely how it was marketed by Autodesk, providing continuing evidence that Autodesk didn't know what they actually had, didn't want to listen to the people who were actually using it... or didn't care.
In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system.
It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived?
Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code.
If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible!
-Bradley
Sent from my iPhone
On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau <chris.v...@autodesk.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx><mailto:chris.v...@autodesk.com<https://connect.autodesk.com/owa/UrlBlockedError.aspx>>> wrote:
Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset?
Nope
--
Nick Martinelli
(201) 424 - 6518
ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net<https://connect.autodesk.com/owa/UrlBlockedError.aspx>>
Paul Doyle
Mar 16, 2014, 3:51:41 PM3/16/14
to soft...@listproc.autodesk.com
Hi Chris - Ronald was the main (very gifted) designer and he's now at Ubisoft, so I'd suggest he's really the key person from the original ICE team and doesn't work for either AD or Fabric. At Fabric we have Jerome and Peter who were involved in much of back-end multi-threading work, and Phil and Helge who built a lot of the nodes and demos that went into 7.0. That's by no means the entire team.
Lots of people at Softimage were involved throughout, and given that a ton of work went into ICE since 7.0 it would be unfair to say there's nobody at AD or in the Bifrost team worked on ICE. ICE was exciting and a success because the whole of Softimage was sold on the idea - it was prevalent throughout the company. I wouldn't denigrate anyone that was involved in XSI 7.0, it was a colossal team effort that is still the high point of my career.
I also have immense respect for the team that worked on Skyline and am confident that whatever they build will be impressive. There are many talented people that I worked with in the Games group, so I'm not going to say anything but good things about them.
What is unclear is how the ICE approach (as a high-level visual programming paradigm) meshes with Bifrost as publicly shown to date - I expect that is driving the questions people are raising. Because of that, I think it is problematic to say that Bifrost is the spiritual successor to ICE. Nobody is really explaining how that's the case, beyond it's also going to have a visual programming system - but that's like saying Maya and Softimage are the same because they both have a scene graph.
There is also just an issue of rubbing people up the wrong way. Many people feel that ICE is a phenomenal piece of technology that had the potential to become something even more amazing (and valuable to AD at the FX end of the pipeline) - sadly that was not where efforts were invested post-acquisition. It is hard for your customers to understand why Softimage is being EOL when award winning work is being produced with that toolset - and being told 'just wait till Bifrost comes out' doesn't really sweeten the pill. I understand the logic behind that, but you're asking people to have a lot of faith in something they haven't seen yet.
Thanks,
Paul
Chris Vienneau
Mar 16, 2014, 4:59:56 PM3/16/14
to soft...@listproc.autodesk.com
Thanks Paul. I think everyone here respects all the hard work everyone put into ICE and that the whole team did not leave and many of the key people involved in ICE kept working on what eventually became Bifrost. Bifrost will be launched this week so people will get their first real glimpse of the technology. We are clear that we are using the procedural core to power liquids in the form of the rewritten Naiad solver using a generalist UI. We will be more open about the technology like we were in the FX guide article as the year goes on but will have any such discussion with customers under NDA as you know since we seem to keep the same circles these days.
cv/
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Paul Doyle [techn...@gmail.com]
Sent: Sunday, March 16, 2014 3:51 PM
cv/
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Paul Doyle [techn...@gmail.com]
Sent: Sunday, March 16, 2014 3:51 PM
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Steven Caron
Mar 16, 2014, 5:00:57 PM3/16/14
to soft...@listproc.autodesk.com
you don't have to explain ICE to us, i personally have been using some incarnation of ICE for about 7 years now. grabbing a list of categories from the docs and asking us which ones we use the most makes me wonder if you know what are doing... we need all of those lower level nodes to create the compounds, missing even a handful and it becomes very difficult and some what impossible to make them.
but going along with your question, the geometry queries are probably some of the most important nodes. as you already pointed out the underlying data type 'location' is the backbone of how we store and query scene data which drive our simulations and effects. they are the inputs to our functions.
Chris Vienneau
Mar 16, 2014, 5:16:01 PM3/16/14
to soft...@listproc.autodesk.com
Fair enough. I have had this conversation with a few people face to face and it is obviously easier than a mailing list. Thanks for the thought as it is consistent with what other people have said.
cv/
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Steven Caron [car...@gmail.com]
Sent: Sunday, March 16, 2014 5:00 PM
cv/
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Steven Caron [car...@gmail.com]
Sent: Sunday, March 16, 2014 5:00 PM
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
you don't have to explain ICE to us, i personally have been using some incarnation of ICE for about 7 years now. grabbing a list of categories from the docs and asking us which ones we use the most makes me wonder if you know what are doing... we need all of those lower level nodes to create the compounds, missing even a handful and it becomes very difficult and some what impossible to make them.
but going along with your question, the geometry queries are probably some of the most important nodes. as you already pointed out the underlying data type 'location' is the backbone of how we store and query scene data which drive our simulations and effects. they are the inputs to our functions.
but going along with your question, the geometry queries are probably some of the most important nodes. as you already pointed out the underlying data type 'location' is the backbone of how we store and query scene data which drive our simulations and effects. they are the inputs to our functions.
Eric Thivierge
Mar 16, 2014, 6:42:44 PM3/16/14
to soft...@listproc.autodesk.com
Hey Chris,
A few questions:
1. How do you respond to the people who have been long time die hard Softimage users who have also been exposed to other DCC's, maya specifically, who have little to no faith in AD being innovative or responsive to their user base as history has shown. I can give you a specific example. Skin painting. How many years has it been that it has been in its current form, and your user base asking for it's interaction model and tool set cleaned up and extended. Yet here we are just prior to the 2015 release and it's gotten no attention. It's been years people have been asking for this. Yet nothing from AD. Same with the blend shape tools. No attention. Take a look at the various threads on this list and 3D Pro where Maya veterans say that the use of 3rd Party tools is a must! We need a developer that actually listens and turns around results quickly. Not taking 5+ years to not even address it.
2. What is a generalist UI?
3. So the first release of a tool built with your node graph will be released in Bifrost. How long do we have to wait until the node graph is accessible? (Granted I know you can't tell us, it just has to be asked). It's known that with Maya releases and new features that the first version is never production ready. You could say that for most new features in all software, but when we think about it, if we hypothetically say the node graph is another year off, that first release won't be usable and so that puts us to the next year's release, 2017. At that time most studios will need to have had to transitioned off of Softimage and onto another platform, such as Maya. So at that point we have more or less zero time to get acquainted with the new system and integrate it into the pipeline and build tools around it. That's all with the wishful thinking everything goes to plan.
4. Let's not kid ourselves. AD is a company who for the majority of their major new features lately, acquires technology and integrates it. NEX is the most recent to come to mind. In a larger scale sort of way that is exactly what you did with Softimage. Bought it for the devs and are now trying to integrate the technology. How is this supposed to bring confidence to users who need to use Maya? It's just a bunch of plug-ins that were bought and slapped together. There doesn't seem to be a unified workflow thought out of how these all need to play together and thus gives you a very fragmented workflow. Not to mention, what happens when there is a year where you don't acquire a software? Does Maya not get a new feature that release?
5. Lastly, who are these other key people who remained at AD that worked on ICE? It may give us reassurance to know what good hands we've been left in. (Not really expecting an answer here because it'd be dangerous for AD to list their employees, but it's more the point that we don't know who these other key people are and thus, have no reason to be confident in them.)
Thanks,
Andy Jones
Mar 16, 2014, 6:52:48 PM3/16/14
to soft...@listproc.autodesk.com
Let me ask a very open question to Paul Doyle. Paul when people say the creators of ICE work at Fabric do you agree? Many on the Bifrost team would argue they were just as much a part of it than the hard working guys at Fabric. I think it is great that there are two companies following this path and that will only mean competition which is a good thing but I do believe there are many people who came together and not just 1-2 who drove the whole thing.
I don't know what the answer to this is, but as a customer I really don't care that much. I'm far more interested in which development team is innovating and working on not only giving us back what we're losing with ICE, but also addressing its limitations. Given that AD just "offed" ICE without having a replacement ready, it's going to be a tough sell to convince me AD has a solid vision for the future of the software they sell.
AD has all the advantages in terms of size and market share, and I'm 100% confident that there are still some truly exceptional developers working there -- some of whom no doubt worked directly on ICE. I'm also 100% confident the Titanic had a lot of great sailors on board when it sank. Even a tiny lifeboat becomes awfully appealing when the captain of the ship drives it into an iceberg. Let alone a Chinook helicopter (which is how I see Fabric Engine in this analogy. For those who don't think a Chinook helicopter is good enough, remember the Titanic sank in 1912).
Since you brought them into this, I'd like to ask an open question to your devs who worked on ICE: Do they feel like their talents are being put to good use? If so, how?
I think comparing a list of answers to questions like that would be a lot more productive than counting how many of the people who worked on ICE haven't left AD yet.
Mario Reitbauer
Mar 16, 2014, 7:15:03 PM3/16/14
to soft...@listproc.autodesk.com
Uhm.
Actually I know others who say that the key people behind Ice went to a quite new company which name starts with F and ends with abric Engine.So someone is wrong here.
About your question.
Actually I think there is not even a single node which should miss in ICE. Some are redundant and wouldnt need to be there but overall 99% of the nodes just should be there. And there are even nodes missing (uv to location on polygon meshes as example).
Bk
Mar 16, 2014, 7:35:29 PM3/16/14
to soft...@listproc.autodesk.com
Say there was a 50/50 split of the ice team.
I would always go with the team that decided to take matters into their own hands with the confidence to start their own company, rather than the team that went to work for their competitors- being a company infamous for slow plodding development and stifling of development.
I even knew of this reputation long before I'd bought an Ad product, yet the stark reality was far worse than even the reputation suggested.
Luc-Eric Rousseau
Mar 16, 2014, 7:40:08 PM3/16/14
to soft...@listproc.autodesk.com
On Sun, Mar 16, 2014 at 3:51 PM, Paul Doyle <techn...@gmail.com> wrote:
> What is unclear is how the ICE approach (as a high-level visual programming
> paradigm) meshes with Bifrost as publicly shown to date - I expect that is
> driving the questions people are raising. Because of that, I think it is
> problematic to say that Bifrost is the spiritual successor to ICE. Nobody is
> really explaining how that's the case, beyond it's also going to have a
> visual programming system - but that's like saying Maya and Softimage are
> the same because they both have a scene graph.
Here is the link between ICE and Bifrost.
> What is unclear is how the ICE approach (as a high-level visual programming
> paradigm) meshes with Bifrost as publicly shown to date - I expect that is
> driving the questions people are raising. Because of that, I think it is
> problematic to say that Bifrost is the spiritual successor to ICE. Nobody is
> really explaining how that's the case, beyond it's also going to have a
> visual programming system - but that's like saying Maya and Softimage are
> the same because they both have a scene graph.
When we worked on ICE at Softimage, there questions about how ICE
could be used in other markets such games or also used in the rest of
Avid as an fx module. However, the implementation ended up being 100%
tied to XSI's innards and not a separate engine. But the idea
endured that it would have been the right thing to do, to have a "ICE
runtime".
As you know very well, after making some game middleware authoring
tool prototype with XSI, the team then went on to work on project
Skyline, where they created an stand alone evaluation engine that
could have been the successor to ICE, and there had been talked in the
first year of the possibility to plug that BACK into Softimage at a
later date.
Marc Petit was hoping to get a portable ICE engine as a side effect of
Skyline, but that could not happen because the team's focus was
animation (i.e. processing vector, matrices, and doing new things like
state machines) and targeting single-threaded game consoles, and not
particle work on a PC. There was just a load of other things to do .
But the principles of the graph, with get/set data and polymorphic
nodes, for example, are similar.
So now we're at bifrost and the siggraph 2013 demo of it, which you
can see here at the 8 minute mark http://tinyurl.com/nsswz4n is
running on work that is evolving from these previous efforts. The
prototype shown was even using the skyline graph, although that won't
be what we ship.
Gerbrand Nel
Mar 17, 2014, 2:13:39 AM3/17/14
to soft...@listproc.autodesk.com
1(a):Get Data
1(b):Set Data
On 2014/03/15 07:00 PM, Andy Jones wrote:
1(b):Set Data
On 2014/03/15 07:00 PM, Andy Jones wrote:
pet...@skynet.be
Mar 17, 2014, 4:38:03 AM3/17/14
to soft...@listproc.autodesk.com
While you’re at it – don’t forget those connecting lines between the nodes
– absolutely essential, I’d say they are good for 33-50% of all ICE trees!
Also the passthrough node which is present in many compounds – maybe
10%?
Looking forward to the 200% ICE experience in Maya!
From: Gerbrand Nel
Sent: Monday, March 17, 2014 7:13 AM
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do
With TheToolset"
sku...@gmail.com
Mar 17, 2014, 5:40:22 AM3/17/14
to soft...@listproc.autodesk.com
I would say quite simply an updated Hypershade in Maya, who nodes can easily be accessed or at least interacted upon/driven via the new ICE clone. Maya’s Hypershade interface is the same as when I started using Maya 14+ years ago today and it is far inferior to Softimage’s render tree and Material Compound system that uses the same nodal interface as ICE. This is probably #1 on my list over all else.
adrian wyer
Mar 17, 2014, 7:46:38 AM3/17/14
to soft...@listproc.autodesk.com
this, so much fucking this!!!!
From:
softimag...@listproc.autodesk.com
[mailto:softimag...@listproc.autodesk.com] On Behalf Of Bradley Gabe
Sent: 15 March 2014 19:31
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE
Nodes That Cover 80% of What You Do With TheToolset"
This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking.
It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application.
Everyone who ever looked at ICE from the outside, without ever going
into the daily battle that is production, simply saw it as a particle system
(and maybe tipped their hat to it's clever ability to multiprocesses). And
despite the SI community's repeated insistence ICE was far more important than
that, a particle system is precisely how it was marketed by Autodesk, providing
continuing evidence that Autodesk didn't know what they actually had, didn't
want to listen to the people who were actually using it... or didn't care.
In real estate, they say the most important things are location, location,
location. In CG production, the most important things are workarounds,
workarounds, workarounds. ICE has provided SI users with a highly potent,
splendidly integrated, reasonably artist friendly, visual node based toolkit
for discovering and developing production workarounds, without having to resort
to coding for every little thing. Particle effects are merely a byproduct of
the system.
It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived?
Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code.
If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible!
-Bradley
Sent from my iPhone
Chris Marshall
Mar 17, 2014, 8:29:11 AM3/17/14
to soft...@listproc.autodesk.com
yes but if push came to shove, your top 10 ice nodes......?
;-P
Eric Thivierge
Mar 18, 2014, 2:26:07 PM3/18/14
to soft...@listproc.autodesk.com
Just giving this a little bump so Chris V. doesn't forget. Hopefully
Andy's subsequent questions also get some answers...
Thanks,
Eric T.
Thanks,
Eric T.
Enoch Ihde
Mar 18, 2014, 7:08:11 PM3/18/14
to softimage
@chris:
i use pretty much all of the generic & general nodes, as i think any user of ice does.
whether or not people use syflex stuff will depend on if they're doing syflex specific cloth work.
you understand that this question of "which of this list of datatypes do you use?" is a bit ridiculous?
i suppose you're trying to prioritize what to implement and when, but you're basically saying "do you use floats, ints, for loops, arrays, data comparisons, and logic operations, and which ones do you use the most?"
a very odd question, don't you think?
Adam Sale
Mar 18, 2014, 7:16:46 PM3/18/14
to soft...@listproc.autodesk.com
Chris, lets err on the side of caution and implement them all, as they will all be needed at one time or another. The cool thing about ICE is that one never knows what kind of cool tools another user would dream up. Having all of the nodes gives us all the ability to create that which doesn't even exist yet.
Innovative approaches to ICE was why I fell in love with it.
I remember Felix Gebhardts forest vs man sim back in 2008, and remembered thinking that this new paradigm in working gave us the potential for limitless innovation. Innovative approaches to ICE was why I fell in love with it.
Adam
Eric Thivierge
Mar 19, 2014, 8:58:00 AM3/19/14
to soft...@listproc.autodesk.com
Guys, I think we lost another PM... Chris V. has moved on to better
pastures... :(
> <chris.v...@autodesk.com <mailto:chris.v...@autodesk.com>>
> <mailto:softimag...@listproc.autodesk.com>
> [softimag...@listproc.autodesk.com
> <mailto:softimag...@listproc.autodesk.com>] on behalf of
> Nick Martinelli [ni...@nickmartinelli.net
> <mailto:ni...@nickmartinelli.net>]
> <mailto:soft...@listproc.autodesk.com>
> <mailto:andy....@gmail.com><mailto:andy....@gmail.com
> www.nickMartinelli.net
> <http://www.nickMartinelli.net><http://www.nickMartinelli.net>
> ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net
> <mailto:ni...@nickMartinelli.net>>
>
>
>
pastures... :(
> [softimag...@listproc.autodesk.com
> <mailto:softimag...@listproc.autodesk.com>] on behalf of
> Nick Martinelli [ni...@nickmartinelli.net
> <mailto:ni...@nickmartinelli.net>]
> <mailto:soft...@listproc.autodesk.com>
> Subject: Re: "Top List of ICE Nodes That Cover 80% of What You
> Do With The Toolset"
>
> I agree 100% with what everyone is saying.
>
> I would like to add that ICE isn't a point and click system,
> so it's impossible to give a universal list. There isn't one
> way to do anything, just ways that work. Two artists can have
> a similar result with drastically different ICE trees.
>
> Imagine that you ask two people to write an equation that
> equals 10. One might say 7+3 and the other might go with
> 40/4, both are correct, they just got there different ways.
>
> That's the beauty of ICE. It's versatility and efficiency to
> allow the artist to work the way they want to without
> sacrificing quality and production time.
>
>
>
> On Sat, Mar 15, 2014 at 4:16 PM, Bk <pa...@bustykelp.com
> <mailto:pa...@bustykelp.com><mailto:pa...@bustykelp.com
> Do With The Toolset"
>
> I agree 100% with what everyone is saying.
>
> I would like to add that ICE isn't a point and click system,
> so it's impossible to give a universal list. There isn't one
> way to do anything, just ways that work. Two artists can have
> a similar result with drastically different ICE trees.
>
> Imagine that you ask two people to write an equation that
> equals 10. One might say 7+3 and the other might go with
> 40/4, both are correct, they just got there different ways.
>
> That's the beauty of ICE. It's versatility and efficiency to
> allow the artist to work the way they want to without
> sacrificing quality and production time.
>
>
>
> On Sat, Mar 15, 2014 at 4:16 PM, Bk <pa...@bustykelp.com
> <mailto:pa...@bustykelp.com>>> wrote:
> Bradley has expressed exactly, what I have been trying to
> compose over the last week. Yet better than I could.
>
> 1 Autodesk either never room the time to understand ICE,
> 2 or kept it under wraps in order to not let it steal the
> thunder from Bifrost in the future. Weird decision, as they
> could have used it as a taster to get people excited.
> 3 Or of course, there remains the possibility they are just a
> bit simple and confused and deserve our sympathy.
>
> Ironically, the team that actually Made ICE are onto what
> could be seen as "ICE version 2 standalone or in any package".
> Fabric Engine. (cue "binary sunset on tatooine" music)
>
> I have no doubt that the successor to ICE is the future. I do
> actually thing that Bifrost is heading there, but if option 3
> (above) is not the case, I'd be nervous, to say the least.
> Because I believe Fabric is going to get in there first by a
> long shot.
> And we SI users have learnt the hard way, about how important
> it is to get tools into studios and pipelines first.
>
> On 15 Mar 2014, at 19:55, Mirko Jankovic
> <mirkoj....@gmail.com
> <mailto:mirkoj....@gmail.com><mailto:mirkoj....@gmail.com
> Bradley has expressed exactly, what I have been trying to
> compose over the last week. Yet better than I could.
>
> 1 Autodesk either never room the time to understand ICE,
> 2 or kept it under wraps in order to not let it steal the
> thunder from Bifrost in the future. Weird decision, as they
> could have used it as a taster to get people excited.
> 3 Or of course, there remains the possibility they are just a
> bit simple and confused and deserve our sympathy.
>
> Ironically, the team that actually Made ICE are onto what
> could be seen as "ICE version 2 standalone or in any package".
> Fabric Engine. (cue "binary sunset on tatooine" music)
>
> I have no doubt that the successor to ICE is the future. I do
> actually thing that Bifrost is heading there, but if option 3
> (above) is not the case, I'd be nervous, to say the least.
> Because I believe Fabric is going to get in there first by a
> long shot.
> And we SI users have learnt the hard way, about how important
> it is to get tools into studios and pipelines first.
>
> On 15 Mar 2014, at 19:55, Mirko Jankovic
> <mirkoj....@gmail.com
> <mailto:mirkoj....@gmail.com>>> wrote:
>
> Bradley you nailed it with this one, and also points out what
> really AD system does look like.. bunch of bullet points of
> separate marketing ready features that looks nice on list when
> you showing it to sales.
> The matter that those separate features have little to non
> meaningful communications one with other... communication
> that actually makes workflow.. that doesn't mean much I guess.
>
>
> On Sat, Mar 15, 2014 at 8:31 PM, Bradley Gabe
> <with...@gmail.com
> <mailto:with...@gmail.com><mailto:with...@gmail.com
>
> Bradley you nailed it with this one, and also points out what
> really AD system does look like.. bunch of bullet points of
> separate marketing ready features that looks nice on list when
> you showing it to sales.
> The matter that those separate features have little to non
> meaningful communications one with other... communication
> that actually makes workflow.. that doesn't mean much I guess.
>
>
> On Sat, Mar 15, 2014 at 8:31 PM, Bradley Gabe
> <with...@gmail.com
> <mailto:andy....@gmail.com>>> wrote:
>
> On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau
> <chris.v...@autodesk.com
> <mailto:chris.v...@autodesk.com><mailto:chris.v...@autodesk.com
>
> On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau
> <chris.v...@autodesk.com
> <mailto:chris.v...@autodesk.com>>> wrote:
> Do you guys think there is a top list of nodes in ICE and
> compounds you all use that cover 80% of what you do with the
> toolset?
>
> Nope
>
>
>
>
> --
>
> Nick Martinelli
> (201) 424 - 6518 <tel:%28201%29%20424%20-%206518>
> Do you guys think there is a top list of nodes in ICE and
> compounds you all use that cover 80% of what you do with the
> toolset?
>
> Nope
>
>
>
>
> --
>
> Nick Martinelli
> www.nickMartinelli.net
> <http://www.nickMartinelli.net><http://www.nickMartinelli.net>
> ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net
> <mailto:ni...@nickMartinelli.net>>
>
>
>
Martin Yara
Mar 19, 2014, 9:08:12 AM3/19/14
to soft...@listproc.autodesk.com
What? !
He was one of the few who were talking to us even when being attacked and cursed. The only good thing that has happened to us in the last couple of weeks.
Martin
Matt Morris
Mar 19, 2014, 9:09:53 AM3/19/14
to soft...@listproc.autodesk.com
Seriously? Well my faith in the management of autodesk just reached a new low, didn't think that was possible.
Eric Thivierge
Mar 19, 2014, 9:15:04 AM3/19/14
to soft...@listproc.autodesk.com
No it's a joke, but Chris V. has been MIA when questions are being
asked...
On Wednesday, March 19, 2014 9:09:53 AM, Matt Morris wrote:
> Seriously? Well my faith in the management of autodesk just reached a
> new low, didn't think that was possible.
>
>
> On 19 March 2014 12:58, Eric Thivierge <ethiv...@hybride.com
asked...
On Wednesday, March 19, 2014 9:09:53 AM, Matt Morris wrote:
> Seriously? Well my faith in the management of autodesk just reached a
> new low, didn't think that was possible.
>
>
> On 19 March 2014 12:58, Eric Thivierge <ethiv...@hybride.com
Luc-Eric Rousseau
Mar 19, 2014, 9:16:52 AM3/19/14
to soft...@listproc.autodesk.com
Can you move the question to Chris to a new thread for when he gets back online. Thanks
Eric Thivierge
Mar 19, 2014, 9:22:45 AM3/19/14
to soft...@listproc.autodesk.com
No. We have enough threads already and the question was in context to
what was being said in this thread. I know it's a task to sift through
all these emails, but he engaged in this thread so he should be keeping
up with the thread and the questions asked within it. Honestly, I
shouldn't have to ask a question twice and in addition to that, Andy
Jones had a subsequent question as well. Should we ask everyone else
who had questions for Chris V. to start new threads too?
Thanks,
Eric T.
what was being said in this thread. I know it's a task to sift through
all these emails, but he engaged in this thread so he should be keeping
up with the thread and the questions asked within it. Honestly, I
shouldn't have to ask a question twice and in addition to that, Andy
Jones had a subsequent question as well. Should we ask everyone else
who had questions for Chris V. to start new threads too?
Thanks,
Eric T.
Perry Harovas
Mar 19, 2014, 10:18:06 AM3/19/14
to soft...@listproc.autodesk.com
And to Chris' credit, he still replied to me offline with a question I had.
--
Eric Thivierge
Mar 19, 2014, 10:19:12 AM3/19/14
to soft...@listproc.autodesk.com
Sorry to hear that. Hope you feel better soon. Thanks for the note.
Eric T.
Eric T.
Chris Vienneau
Mar 19, 2014, 11:13:40 AM3/19/14
to softimage
Yeah I wasn't talking data types. Things like syflex and crowds was the main gist of the question.
Sent from Windows Mail
From: Enoch Ihde
Sent: Tuesday, March 18, 2014 7:08 PM
To: softimage
@chris:
i use pretty much all of the generic & general nodes, as i think any user of ice does.
whether or not people use syflex stuff will depend on if they're doing syflex specific cloth work.
you understand that this question of "which of this list of datatypes do you use?" is a bit ridiculous?
i suppose you're trying to prioritize what to implement and when, but you're basically saying "do you use floats, ints, for loops, arrays, data comparisons, and logic operations, and which ones do you use the most?"
a very odd question, don't you think?
From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> [softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>] on behalf of Nick Martinelli [ni...@nickmartinelli.net<mailto:ni...@nickmartinelli.net>]
On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau <chris.v...@autodesk.com<mailto:chris.v...@autodesk.com><mailto:chris.v...@autodesk.com<mailto:chris.v...@autodesk.com>>> wrote:
Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset?
Nope
--
Nick Martinelli
(201) 424 - 6518<tel:%28201%29%20424%20-%206518>
www.nickMartinelli.net<http://www.nickMartinelli.net><http://www.nickMartinelli.net>
ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net>>
Sent from Windows Mail
From: Enoch Ihde
Sent: Tuesday, March 18, 2014 7:08 PM
To: softimage
@chris:
i use pretty much all of the generic & general nodes, as i think any user of ice does.
whether or not people use syflex stuff will depend on if they're doing syflex specific cloth work.
you understand that this question of "which of this list of datatypes do you use?" is a bit ridiculous?
i suppose you're trying to prioritize what to implement and when, but you're basically saying "do you use floats, ints, for loops, arrays, data comparisons, and logic operations, and which ones do you use the most?"
a very odd question, don't you think?
Sent: Saturday, March 15, 2014 4:59 PM
To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
I agree 100% with what everyone is saying.
I would like to add that ICE isn't a point and click system, so it's impossible to give a universal list. There isn't one way to do anything, just ways that work. Two artists can have a similar result with drastically different ICE trees.
Imagine that you ask two people to write an equation that equals 10. One might say 7+3 and the other might go with 40/4, both are correct, they just got there different ways.
That's the beauty of ICE. It's versatility and efficiency to allow the artist to work the way they want to without sacrificing quality and production time.
I agree 100% with what everyone is saying.
I would like to add that ICE isn't a point and click system, so it's impossible to give a universal list. There isn't one way to do anything, just ways that work. Two artists can have a similar result with drastically different ICE trees.
Imagine that you ask two people to write an equation that equals 10. One might say 7+3 and the other might go with 40/4, both are correct, they just got there different ways.
That's the beauty of ICE. It's versatility and efficiency to allow the artist to work the way they want to without sacrificing quality and production time.
On Sat, Mar 15, 2014 at 4:16 PM, Bk <pa...@bustykelp.com<mailto:pa...@bustykelp.com><mailto:pa...@bustykelp.com<mailto:pa...@bustykelp.com>>> wrote:
Bradley has expressed exactly, what I have been trying to compose over the last week. Yet better than I could.
1 Autodesk either never room the time to understand ICE,
2 or kept it under wraps in order to not let it steal the thunder from Bifrost in the future. Weird decision, as they could have used it as a taster to get people excited.
3 Or of course, there remains the possibility they are just a bit simple and confused and deserve our sympathy.
Ironically, the team that actually Made ICE are onto what could be seen as "ICE version 2 standalone or in any package". Fabric Engine. (cue "binary sunset on tatooine" music)
I have no doubt that the successor to ICE is the future. I do actually thing that Bifrost is heading there, but if option 3 (above) is not the case, I'd be nervous, to say the least. Because I believe Fabric is going to get in there first by a long shot.
And we SI users have learnt the hard way, about how important it is to get tools into studios and pipelines first.
Bradley has expressed exactly, what I have been trying to compose over the last week. Yet better than I could.
1 Autodesk either never room the time to understand ICE,
2 or kept it under wraps in order to not let it steal the thunder from Bifrost in the future. Weird decision, as they could have used it as a taster to get people excited.
3 Or of course, there remains the possibility they are just a bit simple and confused and deserve our sympathy.
Ironically, the team that actually Made ICE are onto what could be seen as "ICE version 2 standalone or in any package". Fabric Engine. (cue "binary sunset on tatooine" music)
I have no doubt that the successor to ICE is the future. I do actually thing that Bifrost is heading there, but if option 3 (above) is not the case, I'd be nervous, to say the least. Because I believe Fabric is going to get in there first by a long shot.
And we SI users have learnt the hard way, about how important it is to get tools into studios and pipelines first.
On 15 Mar 2014, at 19:55, Mirko Jankovic <mirkoj....@gmail.com<mailto:mirkoj....@gmail.com><mailto:mirkoj....@gmail.com<mailto:mirkoj....@gmail.com>>> wrote:
Bradley you nailed it with this one, and also points out what really AD system does look like.. bunch of bullet points of separate marketing ready features that looks nice on list when you showing it to sales.
The matter that those separate features have little to non meaningful communications one with other... communication that actually makes workflow.. that doesn't mean much I guess.
Bradley you nailed it with this one, and also points out what really AD system does look like.. bunch of bullet points of separate marketing ready features that looks nice on list when you showing it to sales.
The matter that those separate features have little to non meaningful communications one with other... communication that actually makes workflow.. that doesn't mean much I guess.
On Sat, Mar 15, 2014 at 8:31 PM, Bradley Gabe <with...@gmail.com<mailto:with...@gmail.com><mailto:with...@gmail.com<mailto:with...@gmail.com>>> wrote:
This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking.
It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application.
Everyone who ever looked at ICE from the outside, without ever going into the daily battle that is production, simply saw it as a particle system (and maybe tipped their hat to it's clever ability to multiprocesses). And despite the SI community's repeated insistence ICE was far more important than that, a particle system is precisely how it was marketed by Autodesk, providing continuing evidence that Autodesk didn't know what they actually had, didn't want to listen to the people who were actually using it... or didn't care.
In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system.
It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived?
Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code.
If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible!
-Bradley
Sent from my iPhone
On Mar 15, 2014, at 12:00 PM, Andy Jones <andy....@gmail.com<mailto:andy....@gmail.com><mailto:andy....@gmail.com<mailto:andy....@gmail.com>>> wrote:
This is what concerns me about the future for where Autodesk takes their DCC flagships. Bullet-point thinking.
It's not any specific list of ICE nodes that make it so powerful and useful, rather it's how well it plays within the data structures of the rest of the application.
Everyone who ever looked at ICE from the outside, without ever going into the daily battle that is production, simply saw it as a particle system (and maybe tipped their hat to it's clever ability to multiprocesses). And despite the SI community's repeated insistence ICE was far more important than that, a particle system is precisely how it was marketed by Autodesk, providing continuing evidence that Autodesk didn't know what they actually had, didn't want to listen to the people who were actually using it... or didn't care.
In real estate, they say the most important things are location, location, location. In CG production, the most important things are workarounds, workarounds, workarounds. ICE has provided SI users with a highly potent, splendidly integrated, reasonably artist friendly, visual node based toolkit for discovering and developing production workarounds, without having to resort to coding for every little thing. Particle effects are merely a byproduct of the system.
It was through interacting with ICE that I developed a much more profound understanding of CG data structures, an intuitive sense of how the linear algebra drives transforms, of how I could influence operators to do the things I could only imagine in times past. Every day in production is a day of experiment and discovery using ICE. Do you have any idea how empowering that feels after years of waiting for technical help from developers that never arrived?
Furthermore, after years of tech experimenting and workarounds with ICE, my ability to develop non-ICE tools for animation, deformation, etc, had increased drastically. Tools that used to require a week for me to work out the math, I could develop in less than a day, because ICE had both provided me with enough practice to greatly enhance my thinking, but also because I could use it as a prototype laboratory to quickly hash out more difficult concepts, prior to sitting down to write out the code.
If you're wondering why people are concerned about life without XSI, these are some pretty major reasons. You're going to have to convince us the future of node-based work in Maya/Max isn't a bullet point list of nodes for creating particle or fluid sim effects. Rather, that it's a fully developed, operator development kit, from which particles, fluids, simulations, and all kinds of production workarounds, workarounds, workarounds are possible!
-Bradley
Sent from my iPhone
On Sat, Mar 15, 2014 at 6:41 AM, Chris Vienneau <chris.v...@autodesk.com<mailto:chris.v...@autodesk.com><mailto:chris.v...@autodesk.com<mailto:chris.v...@autodesk.com>>> wrote:
Do you guys think there is a top list of nodes in ICE and compounds you all use that cover 80% of what you do with the toolset?
Nope
--
Nick Martinelli
www.nickMartinelli.net<http://www.nickMartinelli.net><http://www.nickMartinelli.net>
ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net<mailto:ni...@nickMartinelli.net>>
Chris Vienneau
Mar 19, 2014, 11:57:01 AM3/19/14
to soft...@listproc.autodesk.com
Sorry I am reading through a lot of the posts. Answers inline
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Eric Thivierge [ethiv...@gmail.com]
Sent: Sunday, March 16, 2014 6:42 PM
2. What is a generalist UI?
- There are hundreds of thousands of users in the 3D market doing everything from film, tv, games, advertising, graphic design, visualization, etc... . A generalist is someone who uses more than two areas of the DCC (modeling, animation, fx, lighting) . A vast majority of these users want to use the out of the box UI and presets and less than 10% of the overall user base scripts (whether visually or not). So a generalist UI is the interface intended for the use case where a user wants to interact with a set of menus, editors, viewport gizmos to achieve a given effect.
3. So the first release of a tool built with your node graph will be released in Bifrost. How long do we have to wait until the node graph is accessible? (Granted I know you can't tell us, it just has to be asked). It's known that with Maya releases and new features that the first version is never production ready. You could say that for most new features in all software, but when we think about it, if we hypothetically say the node graph is another year off, that first release won't be usable and so that puts us to the next year's release, 2017. At that time most studios will need to have had to transitioned off of Softimage and onto another platform, such as Maya. So at that point we have more or less zero time to get acquainted with the new system and integrate it into the pipeline and build tools around it. That's all with the wishful thinking everything goes to plan.
-You know I can't tell you that but since you have seen the graph with your own eyes you at least know it is there. Anyone under NDA can get all of the information here.
4. Let's not kid ourselves. AD is a company who for the majority of their major new features lately, acquires technology and integrates it. NEX is the most recent to come to mind. In a larger scale sort of way that is exactly what you did with Softimage. Bought it for the devs and are now trying to integrate the technology. How is this supposed to bring confidence to users who need to use Maya? It's just a bunch of plug-ins that were bought and slapped together. There doesn't seem to be a unified workflow thought out of how these all need to play together and thus gives you a very fragmented workflow. Not to mention, what happens when there is a year where you don't acquire a software? Does Maya not get a new feature that release?
Isn't your pipeline a collection of applications glued together with a unified workflow or intent? We are clear that Maya needs a UI/workflow overhaul to bring coherency to many of the workflows and there are tools in Softimage like Gator which show the power of such an approach. In this release we had several features that were developed in house like Geodesic Voxel Binding and the whole viewport effort was built on technology entirely developed by Autodesk. So Eric by that logic are you saying that putting effort into Ptex support, UV tiling, Alembic, Open EXR 2.0, python, etc... are not good things?
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Eric Thivierge [ethiv...@gmail.com]
Sent: Sunday, March 16, 2014 6:42 PM
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Hey Chris,
A few questions:
1. How do you respond to the people who have been long time die hard Softimage users who have also been exposed to other DCC's, maya specifically, who have little to no faith in AD being innovative or responsive to their user base as history has shown. I can give you a specific example. Skin painting. How many years has it been that it has been in its current form, and your user base asking for it's interaction model and tool set cleaned up and extended. Yet here we are just prior to the 2015 release and it's gotten no attention. It's been years people have been asking for this. Yet nothing from AD. Same with the blend shape tools. No attention. Take a look at the various threads on this list and 3D Pro where Maya veterans say that the use of 3rd Party tools is a must! We need a developer that actually listens and turns around results quickly. Not taking 5+ years to not even address it.
- As we have been saying the last few weeks the main drive for the last few years was to modernize Maya's core so that we could start to modernize the workflows on top of it. Having a good workflow for fluids or particles and not be able to generate the quality and scale required to generate the fx that are the norm was not acceptable. The first two areas we focused on was FX and modeling and yes we started with the NEX toolkit but we have kept the developers that built the plugin on to integrate all the technology correctly into Maya. I think if you look at the work done in uv editing, retopology, base modeling operations, and workflow the work is detailed and broad/ We are looking at making big progress in animation and lighting/rendering very shortly. Maya LT is releasing every three months and we are looking at building back up the pace with Maya.
A few questions:
1. How do you respond to the people who have been long time die hard Softimage users who have also been exposed to other DCC's, maya specifically, who have little to no faith in AD being innovative or responsive to their user base as history has shown. I can give you a specific example. Skin painting. How many years has it been that it has been in its current form, and your user base asking for it's interaction model and tool set cleaned up and extended. Yet here we are just prior to the 2015 release and it's gotten no attention. It's been years people have been asking for this. Yet nothing from AD. Same with the blend shape tools. No attention. Take a look at the various threads on this list and 3D Pro where Maya veterans say that the use of 3rd Party tools is a must! We need a developer that actually listens and turns around results quickly. Not taking 5+ years to not even address it.
2. What is a generalist UI?
3. So the first release of a tool built with your node graph will be released in Bifrost. How long do we have to wait until the node graph is accessible? (Granted I know you can't tell us, it just has to be asked). It's known that with Maya releases and new features that the first version is never production ready. You could say that for most new features in all software, but when we think about it, if we hypothetically say the node graph is another year off, that first release won't be usable and so that puts us to the next year's release, 2017. At that time most studios will need to have had to transitioned off of Softimage and onto another platform, such as Maya. So at that point we have more or less zero time to get acquainted with the new system and integrate it into the pipeline and build tools around it. That's all with the wishful thinking everything goes to plan.
4. Let's not kid ourselves. AD is a company who for the majority of their major new features lately, acquires technology and integrates it. NEX is the most recent to come to mind. In a larger scale sort of way that is exactly what you did with Softimage. Bought it for the devs and are now trying to integrate the technology. How is this supposed to bring confidence to users who need to use Maya? It's just a bunch of plug-ins that were bought and slapped together. There doesn't seem to be a unified workflow thought out of how these all need to play together and thus gives you a very fragmented workflow. Not to mention, what happens when there is a year where you don't acquire a software? Does Maya not get a new feature that release?
5. Lastly, who are these other key people who remained at AD that worked on ICE? It may give us reassurance to know what good hands we've been left in. (Not really expecting an answer here because it'd be dangerous for AD to list their employees, but it's more the point that we don't know who these other key people are and thus, have no reason to be confident in them.)
-I will ask those employees if they want to have their names listed but I can understand if they don't want to do so. ICE was derived from a very novel programming methodology that had fallen out of favor and which is why Fabric can start up with no harm of IP infringement on ICE. I have many names over the years mentioned as key contributors of ICE and wanted to make sure that the fact that many people who worked at Soft still work at Autodesk and that key people from the ICE team work at Autodesk and on Bifrost was understood as well.
Eric Thivierge
Mar 19, 2014, 12:35:25 PM3/19/14
to soft...@listproc.autodesk.com
Replying Inline as well. :)
> A few questions:
> 1. How do you respond to the people who have been long time die hard Softimage users who have also been exposed to other DCC's, maya specifically, who have little to no faith in AD being innovative or responsive to their user base as history has shown. I can give you a specific example. Skin painting. How many years has it been that it has been in its current form, and your user base asking for it's interaction model and tool set cleaned up and extended. Yet here we are just prior to the 2015 release and it's gotten no attention. It's been years people have been asking for this. Yet nothing from AD. Same with the blend shape tools. No attention. Take a look at the various threads on this list and 3D Pro where Maya veterans say that the use of 3rd Party tools is a must! We need a developer that actually listens and turns around results quickly. Not taking 5+ years to not even address it.
>
> - As we have been saying the last few weeks the main drive for the last few years was to modernize Maya's core so that we could start to modernize the workflows on top of it. Having a good workflow for fluids or particles and not be able to generate the quality and scale required to generate the fx that are the norm was not acceptable. The first two areas we focused on was FX and modeling and yes we started with the NEX toolkit but we have kept the developers that built the plugin on to integrate all the technology correctly into Maya. I think if you look at the work done in uv editing, retopology, base modeling operations, and workflow the work is detailed and broad/ We are looking at making big progress in animation and lighting/rendering very shortly. Maya LT is releasing every three months and we are looking at building back up the pace with Maya.
Thanks. As per the NEX devs, is it intended only to keep them on until
integration is done or are you guys thinking that their strategies can
be useful in the future and plan to have them work on other areas? In
the same vain as the core modernization, will there be other things
that may come up that prevent you from working on the various tool sets
much like the core modernization has?
>
> 3. So the first release of a tool built with your node graph will be released in Bifrost. How long do we have to wait until the node graph is accessible? (Granted I know you can't tell us, it just has to be asked). It's known that with Maya releases and new features that the first version is never production ready. You could say that for most new features in all software, but when we think about it, if we hypothetically say the node graph is another year off, that first release won't be usable and so that puts us to the next year's release, 2017. At that time most studios will need to have had to transitioned off of Softimage and onto another platform, such as Maya. So at that point we have more or less zero time to get acquainted with the new system and integrate it into the pipeline and build tools around it. That's all with the wishful thinking everything goes to plan.
>
> -You know I can't tell you that but since you have seen the graph with your own eyes you at least know it is there. Anyone under NDA can get all of the information here.
I know you can't tell me, but do you see where there are valid
concerns? We could still be 2 years away right now from being able to
use and integrate that new toolset into our pipeline. The whole initial
plan was to have everyone transitioning off of Softimage within the
next 2 years, then AD backpedaled on that. What would have happened if
you guys stuck to your original plan? There would have been a huge gap
left.
>
> 4. Let's not kid ourselves. AD is a company who for the majority of their major new features lately, acquires technology and integrates it. NEX is the most recent to come to mind. In a larger scale sort of way that is exactly what you did with Softimage. Bought it for the devs and are now trying to integrate the technology. How is this supposed to bring confidence to users who need to use Maya? It's just a bunch of plug-ins that were bought and slapped together. There doesn't seem to be a unified workflow thought out of how these all need to play together and thus gives you a very fragmented workflow. Not to mention, what happens when there is a year where you don't acquire a software? Does Maya not get a new feature that release?
>
> Isn't your pipeline a collection of applications glued together with a unified workflow or intent? We are clear that Maya needs a UI/workflow overhaul to bring coherency to many of the workflows and there are tools in Softimage like Gator which show the power of such an approach. In this release we had several features that were developed in house like Geodesic Voxel Binding and the whole viewport effort was built on technology entirely developed by Autodesk. So Eric by that logic are you saying that putting effort into Ptex support, UV tiling, Alembic, Open EXR 2.0, python, etc... are not good things?
Yes it is, even more reason why I don't need one of those application's
glued together within itself. Pipelines are complex enough let alone
having to fight within one application to have it do what I want and
work productively at a good pace. There is a difference in integrating
Open Source projects than just buying tech, integrating it, and letting
it rot. The OpenSource projects continue to get dev from outside of AD
and evolve.
> 5. Lastly, who are these other key people who remained at AD that worked on ICE? It may give us reassurance to know what good hands we've been left in. (Not really expecting an answer here because it'd be dangerous for AD to list their employees, but it's more the point that we don't know who these other key people are and thus, have no reason to be confident in them.)
>
> -I will ask those employees if they want to have their names listed but I can understand if they don't want to do so. ICE was derived from a very novel programming methodology that had fallen out of favor and which is why Fabric can start up with no harm of IP infringement on ICE. I have many names over the years mentioned as key contributors of ICE and wanted to make sure that the fact that many people who worked at Soft still work at Autodesk and that key people from the ICE team work at Autodesk and on Bifrost was understood as well.
Not sure why Fabric is getting dragged into this... again. But what
novel programming methodology are you speaking of? Surely not node
based programming.
In the end, all I'm trying to illustrate here is why the vast majority
of Softimage users have little confidence in AD. If you want to move
forward and convince us you really need to be honest about the history
and put a tremendous effort into changing the way things have been done
at AD in the past on all fronts. Not just updating bits and pieces and
hitting bullet points.
Personally, if Maya didn't have the market share and be the only
product on the market that had the amount of decent rigging and
animation tools it currently has, I would be jumping off the AD ship
ASAP. I don't like the way AD works overall. However, since you have
the market cornered in these respects, I have no other option. If the
AD mentality doesn't make a big shift, and another solution comes
along, you're going to find yourselves with a lot of people jumping
ship. I wouldn't take it for granted.
Eric T.
> A few questions:
> 1. How do you respond to the people who have been long time die hard Softimage users who have also been exposed to other DCC's, maya specifically, who have little to no faith in AD being innovative or responsive to their user base as history has shown. I can give you a specific example. Skin painting. How many years has it been that it has been in its current form, and your user base asking for it's interaction model and tool set cleaned up and extended. Yet here we are just prior to the 2015 release and it's gotten no attention. It's been years people have been asking for this. Yet nothing from AD. Same with the blend shape tools. No attention. Take a look at the various threads on this list and 3D Pro where Maya veterans say that the use of 3rd Party tools is a must! We need a developer that actually listens and turns around results quickly. Not taking 5+ years to not even address it.
>
> - As we have been saying the last few weeks the main drive for the last few years was to modernize Maya's core so that we could start to modernize the workflows on top of it. Having a good workflow for fluids or particles and not be able to generate the quality and scale required to generate the fx that are the norm was not acceptable. The first two areas we focused on was FX and modeling and yes we started with the NEX toolkit but we have kept the developers that built the plugin on to integrate all the technology correctly into Maya. I think if you look at the work done in uv editing, retopology, base modeling operations, and workflow the work is detailed and broad/ We are looking at making big progress in animation and lighting/rendering very shortly. Maya LT is releasing every three months and we are looking at building back up the pace with Maya.
integration is done or are you guys thinking that their strategies can
be useful in the future and plan to have them work on other areas? In
the same vain as the core modernization, will there be other things
that may come up that prevent you from working on the various tool sets
much like the core modernization has?
>
> 3. So the first release of a tool built with your node graph will be released in Bifrost. How long do we have to wait until the node graph is accessible? (Granted I know you can't tell us, it just has to be asked). It's known that with Maya releases and new features that the first version is never production ready. You could say that for most new features in all software, but when we think about it, if we hypothetically say the node graph is another year off, that first release won't be usable and so that puts us to the next year's release, 2017. At that time most studios will need to have had to transitioned off of Softimage and onto another platform, such as Maya. So at that point we have more or less zero time to get acquainted with the new system and integrate it into the pipeline and build tools around it. That's all with the wishful thinking everything goes to plan.
>
> -You know I can't tell you that but since you have seen the graph with your own eyes you at least know it is there. Anyone under NDA can get all of the information here.
concerns? We could still be 2 years away right now from being able to
use and integrate that new toolset into our pipeline. The whole initial
plan was to have everyone transitioning off of Softimage within the
next 2 years, then AD backpedaled on that. What would have happened if
you guys stuck to your original plan? There would have been a huge gap
left.
>
> 4. Let's not kid ourselves. AD is a company who for the majority of their major new features lately, acquires technology and integrates it. NEX is the most recent to come to mind. In a larger scale sort of way that is exactly what you did with Softimage. Bought it for the devs and are now trying to integrate the technology. How is this supposed to bring confidence to users who need to use Maya? It's just a bunch of plug-ins that were bought and slapped together. There doesn't seem to be a unified workflow thought out of how these all need to play together and thus gives you a very fragmented workflow. Not to mention, what happens when there is a year where you don't acquire a software? Does Maya not get a new feature that release?
>
> Isn't your pipeline a collection of applications glued together with a unified workflow or intent? We are clear that Maya needs a UI/workflow overhaul to bring coherency to many of the workflows and there are tools in Softimage like Gator which show the power of such an approach. In this release we had several features that were developed in house like Geodesic Voxel Binding and the whole viewport effort was built on technology entirely developed by Autodesk. So Eric by that logic are you saying that putting effort into Ptex support, UV tiling, Alembic, Open EXR 2.0, python, etc... are not good things?
glued together within itself. Pipelines are complex enough let alone
having to fight within one application to have it do what I want and
work productively at a good pace. There is a difference in integrating
Open Source projects than just buying tech, integrating it, and letting
it rot. The OpenSource projects continue to get dev from outside of AD
and evolve.
> 5. Lastly, who are these other key people who remained at AD that worked on ICE? It may give us reassurance to know what good hands we've been left in. (Not really expecting an answer here because it'd be dangerous for AD to list their employees, but it's more the point that we don't know who these other key people are and thus, have no reason to be confident in them.)
>
> -I will ask those employees if they want to have their names listed but I can understand if they don't want to do so. ICE was derived from a very novel programming methodology that had fallen out of favor and which is why Fabric can start up with no harm of IP infringement on ICE. I have many names over the years mentioned as key contributors of ICE and wanted to make sure that the fact that many people who worked at Soft still work at Autodesk and that key people from the ICE team work at Autodesk and on Bifrost was understood as well.
novel programming methodology are you speaking of? Surely not node
based programming.
In the end, all I'm trying to illustrate here is why the vast majority
of Softimage users have little confidence in AD. If you want to move
forward and convince us you really need to be honest about the history
and put a tremendous effort into changing the way things have been done
at AD in the past on all fronts. Not just updating bits and pieces and
hitting bullet points.
Personally, if Maya didn't have the market share and be the only
product on the market that had the amount of decent rigging and
animation tools it currently has, I would be jumping off the AD ship
ASAP. I don't like the way AD works overall. However, since you have
the market cornered in these respects, I have no other option. If the
AD mentality doesn't make a big shift, and another solution comes
along, you're going to find yourselves with a lot of people jumping
ship. I wouldn't take it for granted.
Eric T.
Paul Doyle
Mar 19, 2014, 1:22:54 PM3/19/14
to soft...@listproc.autodesk.com
The statement "ICE was derived from a very novel programming
seems to suggest that Fabric borrows from ICE, which is not a remotely
accurate portrayal of the respective technologies. Given that our team
has deep expertise on both ICE and Fabric, I am well placed to make
this clarification.
Data flow graphs and visual programming predate ICE and imho have
never been out of favour (within the same domain, let alone within
computer science). The commonality between ICE and Fabric starts and
stops there - I think anyone familiar with our execution engine and KL
would agree. It's like suggesting that ICE ripped off Houdini.
methodology that had fallen out of favor and which is why Fabric can
start up with no harm of IP infringement on ICE" is perplexing. It
seems to suggest that Fabric borrows from ICE, which is not a remotely
accurate portrayal of the respective technologies. Given that our team
has deep expertise on both ICE and Fabric, I am well placed to make
this clarification.
Data flow graphs and visual programming predate ICE and imho have
never been out of favour (within the same domain, let alone within
computer science). The commonality between ICE and Fabric starts and
stops there - I think anyone familiar with our execution engine and KL
would agree. It's like suggesting that ICE ripped off Houdini.
Martin Chatterjee
Mar 19, 2014, 1:42:13 PM3/19/14
to soft...@listproc.autodesk.com
Chris,
(...) ICE was derived from a very novel programming methodology that had fallen out of favor and which is why Fabric can start up with no harm of IP infringement on ICE. (...)
Excuse me, say what? I'm so calling 'bullshit' on that statement.
I don't even know where to begin...
a.) Autodesk surely did not invent the concepts of graphical programming/data flow graphs.
b.) these concepts definitely did not fall out of favor anywhere
c.) your implication that the technology behind Fabric Engine is essentially a v2.0 of ICE (and therefore your indirect accusation that the Fabric team simply took the groundwork for their engine with them when they left Autodesk) is ridiculous to put it mildly.
-M
Chris Vienneau
Mar 19, 2014, 2:00:57 PM3/19/14
to Eric Thivierge, soft...@listproc.autodesk.com
Hi Eric,
I will go back up as our inline inline is getting too hard to follow. What we have been doing the last few years is bringing on very focused dev talent like the NEX guys or unfold 3D guys and signing them to multi-year contracts so we do not get the plugin pasted in and it dies. This gives us 2-3 releases to avoid the rot syndrome that we have seen in other packages.
The concerns over Bifrost are totally valid. I told you that at our meeting. Again revamping the UI with QT, the viewport, and the data model has taken many years and lots of hard lessons learned in the heart of production. Bifrost will get put immediately into the hands of hundreds of thousands of students, professionals, pipelines and pirates so we will know if the base engine will run on the shittiest hardware we track all the way up to the machines of tomorrow we run in the labs of places like HP and Intel. Again the first important thing we wanted to get out of Bifrost was scale and performance. As we build out the TD UIs (node based and python) and then developer platform there will be challenges at each step but with Maya in the most grueling pipelines in the world we get the hard feedback very quick.
I understand why everyone here is skeptical about our ability to innovate or trust what is being written. We have to show progress on these topics in short order and keep it up or you will find other solutions eventually.
cv/
________________________________________
From: Eric Thivierge [ethiv...@hybride.com]
Sent: Wednesday, March 19, 2014 12:35 PM
To: soft...@listproc.autodesk.com
Cc: Chris Vienneau
I will go back up as our inline inline is getting too hard to follow. What we have been doing the last few years is bringing on very focused dev talent like the NEX guys or unfold 3D guys and signing them to multi-year contracts so we do not get the plugin pasted in and it dies. This gives us 2-3 releases to avoid the rot syndrome that we have seen in other packages.
The concerns over Bifrost are totally valid. I told you that at our meeting. Again revamping the UI with QT, the viewport, and the data model has taken many years and lots of hard lessons learned in the heart of production. Bifrost will get put immediately into the hands of hundreds of thousands of students, professionals, pipelines and pirates so we will know if the base engine will run on the shittiest hardware we track all the way up to the machines of tomorrow we run in the labs of places like HP and Intel. Again the first important thing we wanted to get out of Bifrost was scale and performance. As we build out the TD UIs (node based and python) and then developer platform there will be challenges at each step but with Maya in the most grueling pipelines in the world we get the hard feedback very quick.
I understand why everyone here is skeptical about our ability to innovate or trust what is being written. We have to show progress on these topics in short order and keep it up or you will find other solutions eventually.
cv/
________________________________________
From: Eric Thivierge [ethiv...@hybride.com]
Sent: Wednesday, March 19, 2014 12:35 PM
To: soft...@listproc.autodesk.com
Cc: Chris Vienneau
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Chris Vienneau
Mar 19, 2014, 2:30:04 PM3/19/14
to soft...@listproc.autodesk.com
Hi Martin,
Graphical programming/data flow graphs are not a programming methodology. ICE is based on a functional style programming like the type you see in Scheme, Clojure from Google, and even Lisp. This methodology was very much out of style in the object oriented C++ world of the 90s. Bringing it back in ICE was what I was talking about as what was novel (i.e. not the standard practice) and Paul can correct me if I am wrong but Fabric uses a functional approach to their programming. Bifrost uses the same functional approach with data-flow which is the way to get parallelism with big data sets.
So to call bullshit on your bullshit call: ICE, Fabric, and Bifrost are leveraging programming methodologies that started in the 60s and are owned by no one. These methodologies did fall out of favor in the big C++ object oriented desktop adventure and the move back to the big data / cloud world has brought them back which is great as the data in film and games is growing year by year and we need to find way to separate the data and functions. Fabric started out on their own with a clean slate and nothing I said implied differently.
cv/
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Martin Chatterjee [martin.chat...@googlemail.com]
Sent: Wednesday, March 19, 2014 1:42 PM
[ http://www.chatterjee.de<http://www.chatterjee.de/> ]
[ https://vimeo.com/chatterjee ]
Graphical programming/data flow graphs are not a programming methodology. ICE is based on a functional style programming like the type you see in Scheme, Clojure from Google, and even Lisp. This methodology was very much out of style in the object oriented C++ world of the 90s. Bringing it back in ICE was what I was talking about as what was novel (i.e. not the standard practice) and Paul can correct me if I am wrong but Fabric uses a functional approach to their programming. Bifrost uses the same functional approach with data-flow which is the way to get parallelism with big data sets.
So to call bullshit on your bullshit call: ICE, Fabric, and Bifrost are leveraging programming methodologies that started in the 60s and are owned by no one. These methodologies did fall out of favor in the big C++ object oriented desktop adventure and the move back to the big data / cloud world has brought them back which is great as the data in film and games is growing year by year and we need to find way to separate the data and functions. Fabric started out on their own with a clean slate and nothing I said implied differently.
cv/
________________________________
From: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] on behalf of Martin Chatterjee [martin.chat...@googlemail.com]
Sent: Wednesday, March 19, 2014 1:42 PM
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
[ https://vimeo.com/chatterjee ]
Paul Doyle
Mar 19, 2014, 2:48:12 PM3/19/14
to soft...@listproc.autodesk.com
Thanks for clearing that up, Chris - appreciated.
Jason S
Mar 19, 2014, 2:49:26 PM3/19/14
to soft...@listproc.autodesk.com
On 03/19/14 14:00, Chris Vienneau wrote:
I understand why everyone here is skeptical about our ability to innovate or trust what is being written. We have to show progress on these topics in short order and keep it up or you will find other solutions eventually.
Even -if- (big -if-) that would be so ... we will be able to
see if you were trustworthy in 5-7 years,
or we will have to find other solutions (yet again.. being somewhat very possible).
Quite possibly ending-up like the node editor.
(on top of, and still having to deal-with and manage the hypershade or -the existing architecture-)
or we will have to find other solutions (yet again.. being somewhat very possible).
Quite possibly ending-up like the node editor.
(on top of, and still having to deal-with and manage the hypershade or -the existing architecture-)
Martin Chatterjee
Mar 19, 2014, 2:49:42 PM3/19/14
to soft...@listproc.autodesk.com
Chris,
Graphical programming/data flow graphs are not a programming methodology. ICE is based on a functional style programming like the type you see in Scheme, Clojure from Google, and even Lisp. This methodology was very much out of style in the object oriented C++ world of the 90s. Bringing it back in ICE was what I was talking about as what was novel (i.e. not the standard practice)
(...)
ICE, Fabric, and Bifrost are leveraging programming methodologies that started in the 60s and are owned by no one.
(...)
Fabric started out on their own with a clean slate and nothing I said implied differently.
Thanks for clearing this up. What you have been stating above I understand and I do concur with.
However I am very sure that the overwhelming majority of people reading this list did not have associations to "Scheme, Clojure or Lisp" when they read your previous comment but instead probably read the same things between the lines which made me reply in the first place...
So I am really glad that you cleared up this misunderstanding, thanks again for that.
-M
Enoch Ihde
Mar 20, 2014, 2:21:54 AM3/20/14
to softimage
ah, regarding things like crowdfx & syflex, or "the more comprehensive prebuilt ICE nodes", i think that's all very dependent on what people use ICE for.
you have a lot of flexibility there.
Raffaele Fragapane
Mar 20, 2014, 2:56:45 AM3/20/14
to soft...@listproc.autodesk.com
The functional programming throwback has officially pushed this conversation into the twilight zone and right out the other end of it into some unexplored surreal territory.
Thanks to all involved, it'll stay with me for the rest of my life and make me giggle every time I'll think of it.
Cesar Saez
Mar 20, 2014, 3:31:50 AM3/20/14
to soft...@listproc.autodesk.com
+1
Both mentions to FE tech are a bit surreal.
Both mentions to FE tech are a bit surreal.
Andy Jones
Mar 20, 2014, 3:47:14 AM3/20/14
to soft...@listproc.autodesk.com
Now that I understand the history of ICE a little better, I can see that I was wrong to balk at naming the top ICE nodes I need. Here's my updated list:
car cdr cons eq atom cons quote
I suppose I won't really need defun, since Maya will let me just add the same nodes over and over again with a mel script.
Brent McPherson
Mar 20, 2014, 9:03:24 AM3/20/14
to soft...@listproc.autodesk.com
Fun fact: Do you know Maya started out using scheme as its scripting language?
--
Brent
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Andy Jones
Sent: 20 March 2014 07:47
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
--
Brent
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Andy Jones
Sent: 20 March 2014 07:47
To: soft...@listproc.autodesk.com
Subject: Re: "Top List of ICE Nodes That Cover 80% of What You Do With The Toolset"
Now that I understand the history of ICE a little better, I can see that I was wrong to balk at naming the top ICE nodes I need. Here's my updated list:
car cdr cons eq atom cons quote
I suppose I won't really need defun, since Maya will let me just add the same nodes over and over again with a mel script.
car cdr cons eq atom cons quote
I suppose I won't really need defun, since Maya will let me just add the same nodes over and over again with a mel script.
Luc-Eric Rousseau
Mar 20, 2014, 9:32:41 AM3/20/14
to soft...@listproc.autodesk.com
The original Softimage 3D developers loved LISP so much, they lobbied
Daniel Langlois to write the software in LISP. The people behing
Mirai probably think they dodge a bullet. The Softimage|3D expression
language, also in XSI, is based on LISP..
Daniel Langlois to write the software in LISP. The people behing
Mirai probably think they dodge a bullet. The Softimage|3D expression
language, also in XSI, is based on LISP..
Luc-Eric Rousseau
Mar 20, 2014, 9:35:57 AM3/20/14
to soft...@listproc.autodesk.com
b.s., but it is not. You can talk to Andre Foisy, or even Ronald if
he's around, and he can explain it. Personally these conversation
have a way of reminding me to stick to UI. ;) Andre is our resident
softimage scientist.
Raffaele Fragapane
Mar 20, 2014, 7:09:12 PM3/20/14
to soft...@listproc.autodesk.com
I'm not saying it's B.S., but it is remarkably out place.
Beside the fact implying functional programming was unpopular, or dead, or forgotten since the 80s or the 60s or whatever is immensely asinine, given that a staggering amount of engineers and mathematicians out there dealing with tough as nails problems do so in functional style restricted or oriented languages every day. Saying that it's functional programming at the core of ICE and its qualities, or of Fabric for that matter, is irrelevant, and it felt like an incredibly artificial way to bring FE in the picture as some sort of rip-off manoeuvre.
Sure, it might have been how a brilliant intuition was presented, but why the mention of patents (lack thereof) and FE?
Graphs are a classic discrete problem, the classic transposition from the math problem to relatively modern implementations one has been functional focused for... I don't know, 40 years? More?
It makes as much sense as saying Bifrost is a FE rip-off because it revolves around compilation and relies on LLVM, and configures itself as an external platform feeding transparently into DCC cients.
Is that a comfortable thought to entertain? Does it drive the discussion anywhere? No, neither, nor it should since finding such shaky ground as common to drive a point home (functional programming or LLVM+clang) is like implying Maya ripped off Max before being bought because it was ported to run on x86 CPUs.
Sorry if this comes out strong, I'm not having a go at you at all Luc only replying for continuity, but as to why it's a somewhat strong mail:
Honestly? I expect much better from vendors than this.
If there are chips on shoulders I hope they get plastered in a hurry (because that's what some comments I occasionally read sound), because I spend, or affect people who pay my wage in spending, money on these products, I'd really rather know that mature individuals constitute the force driving them.
--
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Reply all
Reply to author
Forward
0 new messages