No ICE for foreseeable future except in Houdini and...

[FabricPaul]

So you have no clue about Fabric, but you're convinced it can't do x, y or z? Just like yesterday when you were convinced it couldn't execute KL on discrete GPUs, then spent a painful series of posts trying to recover your position when it was pointed out that it can. Now you're just of the view that it can't do it the way you think it should be done because of technical limitations - yet you still don't know anything about it. I really don't understand what you're trying to achieve in this thread, or why.

This thread is a long series of you making snide remarks about Fabric without any grounding in our technology whatsoever. I get that you like OSS, and that commercial companies must be evil (and recent events certainly reinforce the stereotype) - but why do you think it's ok to make these kinds of remarks? Is it so hard to discuss the topic at hand without resorting to insults?

I'm all for disagreements and for discussing the relative merits and detriments of Fabric's approach, but your attitude makes it impossible to have a proper conversation because you seem more interested in insulting the company. When I don't know something, I ask. When I'm wrong about something, I acknowledge the error. If I disagree with you, I am still polite. Until you can extend me the same basic courtesies, I won't be engaging with you any further.

If I can't appeal to basic human characteristics for my sake (since I run an evil corporation), perhaps I can appeal to your empathy with the mass of Softimage users that are trying to work out what they should do next and are wading through a lot of new information to try and form an informed opinion. You could be helping them understand their options, but instead you seem to just want to push an agenda. It's a stressful enough time as it is without bring unnecessary snarkiness into discussions on their future.

I wish you all the best.

[Pooby]

Just to add. This thread is about possible ICE alternatives. Fabric is one.

Picking apart, in extreme detail, even if it was correct, the merits of particular processing methodoligies, is not going to be of interest to 99% of people who just want to have a visual programming alternative at ALL.

[Hirazi Blue]

Funny, how easily people slip into the role of moderator.
The debate has gotten too hard to follow for innocent bystanders, that much is true. Some of the remarks should better have not been made. Let's leave it at that, let's move on and let's leave the judgment if a member of this community is going/has gone too far to the "trained professionals" (i.e. "the Team").


Added a smilie to place the first statement (as a light-hearted one) apart from the rest of the post.

[Pooby]

yes, after all I have no idea what I'm doing.

Moderator edit: That's not what I meant and I sincerely hope you know that... - HB

[Daniel Brassard]

As Seen on Softimage Mailing List ..... :

Adrian Graham
Mar 20 (13 hours ago)

I suppose it's time I chime in to this thread, and this discussion board.

I work at Autodesk as the Product Designer for Bifrost (among other FX-related components in Maya), working with Marcus Nordenstam.

I'm not entirely sure where to start, as there's a ton of activity surrounding the introduction of Bifrost in Maya 2015 and the EOL of Softimage. I've been lurking on this board for a couple of weeks, so I'm only familiar with the discussions (and rants) that have happened since then.

Let's start here: because Bifrost is a new and complex framework we're designing from the ground-up, we're releasing it in stages. We've been referring to these as the 'generalist', 'FX TD' and 'developer' releases.

Maya 2015 is essentially the 'generalist' release, meaning it will be most useful for people who do not need to gain access to the underlying graph and can live with a fairly simplified workflow to get liquid FX jobs done. This doesn't mean that other users shouldn't try it out, just that they may feel blocked by the current limitations. But note, this will not be, in any way, an equivalent to ICE.

The next release, the 'FX TD' release, will expose the procedural graph and allow much more control over the solvers and order of operation, just what you would expect in an ICE-like procedural workflow. The difference here (and this is where Marcus can chime in), is that we're designing Bifrost to be a visual programming language, where you will be able to dive down into any compound to reveal the basic programmatic or mathematical nodes that drive higher-level functionality. This is very much like ICE. Here's the difference, however: these graphs are JIT-compiled for efficiency, then run as virtual executables by the Bifrost Computation Engine. More on that in another thread.

The third (and by no means final) release we call the 'developer' release, where you'll be able to write your own custom C++ nodes and utilize the full Bifrost API (C++ and possibly Python). You can then insert these nodes into your graph, call them as rendertime procedurals or whatever.

So are we simply tacking on a half-baked feature onto Maya? Absolutely not. Are we going to stop Bifrost development after Maya 2015? No way, there's SO much stuff we're working on, but there's obviously only so many people we can put on the team, even for a huge company like Autodesk.

And I know this sounds like a cliche, but we're really trying to do things right in designing a future-proof framework. We spent a lot of time figuring out how to decouple Bifrost from Maya; to pass data between the two processes and not have Bifrost dependent on Maya, but rather Maya be a client to Bifrost. This means that we'll eventually be able to run Bifrost as a standalone app, on the cloud, on a farm, on your gaming system, iPad, Atari 2600, etc.

If you feel this first release of Bifrost to be limited in functionality, consider that we had to postpone development on certain features in order to deliver a solid usable, basic (if simplified) initial workflow. We'd have much rather done this than pushed an unfinished solution through the pipe to increase the number of bullet points on the "back of the box". We're just laying the foundation at this point.

Mist, foam and spray are some things you may have heard that are indeed missing from Bifrost in Maya 2015. We had to choose between developing that or focusing on things like threading, furthering development on the FLIP solver or memory management, all of which take precedence over furthering the implementation of Bifrost particles.

We've also had the opportunity to design the Bifrost codebase from the ground-up, utilizing modern libraries that Maya or Softimage would otherwise not have access to. This is why everything is so well threaded in Bifrost. I have to shamelessly disclose that I have a dual-CPU machine with 32 cores, and to see (and hear) them all humming at 100% is a marvelous thing. That, and Maya is still interactive and fluid whilst computation takes place in the background. This is totally new for Maya, but I know a other apps can do this.

So, is Bifrost ready to take the place of Softimage ICE? No, not yet.

In Maya 2015, Bifrost is a procedural FX framework with a FLIP liquid solver, based on the technology seen in Naiad. But as time goes by, Bifrost can be involved in more and more components of Maya, and give users access to graphs for anything they do in Maya, not unlike how ICE works. As you can guess, it sounds like a hell of a lot of work, and would involve all areas of design and development. The next step is opening the graph, which means we have to improve the Node Editor and devise new workflows to deal with, for example, compounds and ports.

Who's on the Bifrost development team? I probably shouldn't name names, but there's one of the original authors of the FLIP solver (Bridson), liquid sim supergenius (Nielsen), some of the original devs of ICE (you know who you are) and old-skool Maya devs, including Duncan Brindsmead. And of course, Marcus, who is the Product Manager for Bifrost, and is unique in the PD realm in that he is, himself, a developer and FX TD. Note that Marcus is blissfully ignorant of how things happen (or more importantly, are supposed to happen) in Maya, so the ideas and constructs we're planning and designing are not limited to existing technology in the Maya codebase. He's very proud of this fact. Maybe he's the first software-agnostic Product Manager that Maya has ever had.

I have lots more to say about all this, but I'm surprised anyone's got this far. I'll end it here for now.

I'm happy to answer any questions or comments you may have. I fully disclose that I have never used Softimage in production throughout my 19-year career in VFX and film (except for a few short projects at ILM in 1998), so I defer to you guys to lead the discussions in a constructive, professional manner.

Adrian Graham
Principal User Experience Designer
Autodesk M&E Film & TV Solutions

[Hirazi Blue]

Interesting, that nobody has yet mentioned Ephere Lab for 3ds Max.

[MauricioPC]

Interesting, that nobody has yet mentioned Ephere Lab for 3ds Max.

There's a review about it here ... http://www.maxunderground.com/ephere_lab_review


I've never used it ... but it looks nice.

[Bullit]

As Seen on Softimage Mailing List ..... :

Autodesk guy says nothing trustable.

One of Blender developements: