Bifröst on FXGuide

[mixepix]

About Bifröst and it's ICE heritage. http://www.fxguide.com/featured/bifrost ... ge-to-ice/

[Daniel Brassard]

Interesting article. Thanks for posting.

[iamVFX]

if you look at the article closely, you can see autodesk ad appearing

the only reason why ICE is mentioned is compound feature? no custom mesh generation or procedural kinematics i suppose?

"A lot of the tasks such as fixing holes etc lend themselves to the interactive workflow in the viewport. So we don’t want to force proceduralism onto a user."
yeah, why would you want to fix holes procedurally when you can spend a hour or two tracking them down and fixing by yourself

[luceric]

ice is mentioned because the bifrost demo is built on the next generation of ICE development, the one that is app agnostic and uses a runtime compiler. ICE kinematics is not this awesome gem. Not only is it dreadfully slow in softimage compared to just using expressions, that kind of node-based rigging is native in maya with the hypergraph/node editor. it's softimage that isn't node-based and needed ICE bolted on the side to do this. Same for node-based procedural modeling. but didn't say anything about not doing modeling procedurally in bifrost, no matter how you'd like to spin random phrases in the article.

[iamVFX]

Not only is it dreadfully slow in softimage compared to just using expressions,

oh, so the presentations about how ice kinematics is fast was an autodesk bullshit? i knew that, but thanks for honesty

that kind of node-based rigging is native in maya with the hypergraph/node editor.

but not in the bifrost, so no application agnostics and runtime compilation?

sounds like "we have no these feature because ICE is shitty on them, but we still marketing them to people as fast features in another product called Softimage" kind of answer to me

[luceric]

Not only is it dreadfully slow in softimage compared to just using expressions,

oh, so the presentations about how ice kinematics is fast was an autodesk bullshit? i knew that, but thanks for honesty

that kind of node-based rigging is native in maya with the hypergraph/node editor.

but not in the bifrost, so no application agnostics and runtime compilation?

sounds like "we have no these feature because ICE is shitty on them, but we still marketing them to people as fast features in another product called Softimage" kind of answer to me

I'd be curious to see if you can find examples where someone marketted that ICE Kinematics gives faster playback performance than classic rigging, because we were very careful to never say that. There are whole tutorials dedicated to minimizing the ICE overhead with ice kinematics. The feature was about adding node-based rigging workflows. ICE in XSI is designed to process large batches of data in parallels. It's good at particles, deformers, etc, stuff that parallelizes well. It is not efficient at being called to just processing small matrices that can't be parallelized, there is too much overhead to start an ICE evaluation. the next gen tech is about fixing that, it compiles graphs rather than interpreting them.

Anyway the article here is about Bifrost fluid simuation, meshing, distributed evaluation, simulation. It's not because the article doesn't talk about something that it cannot do that thing. Just like it's not because someone says that you may not want proceduralism "to fix holes" that you can't have a procedural way to do it. That's not what the article talk about at all. It talks about the fact that nodes don't make the need for great and interactive workflows for artists obsolete in favor of just offering on node-based workflows and telling people to just program whatever they need.

[iamVFX]

ok, so i guess it is my problem with understanding of ice kinematics, because why would you do all this hard work of setting it up with not having even slightest performance benefits. now it looks more nonsensical to me personally.

bifrost as a code generator seems to be a great idea if you can use its code in other purposes, other than vfx stuff at least. can you use generated code in your game engine for commercial purposes, for example?

[Mathaeus]

Anyway the article here is about Bifrost fluid simuation, meshing, distributed evaluation, simulation. It's not because the article doesn't talk about something that it cannot do that thing. Just like it's not because someone says that you may not want proceduralism "to fix holes" that you can't have a procedural way to do it. That's not what the article talk about at all. It talks about the fact that nodes don't make the need for great and interactive workflows for artists obsolete in favor of just offering on node-based workflows and telling people to just program whatever they need.

I'll be free to rephrase this into simple question. Would I be able to create something not-simulated and procedural, with this next ICE gen. Let's say simple tree generator. Or something mixed, like growing plants or so. With all due respect to all brushing addicts all around, some things belongs to procedural generation, in any way.

By the way, this direct volume rendering, for me, looks like one of most interesting feature. IF it's faster than current, render-time method like in BA Shaders or Ben Rogall's stuff. I hope it should be faster, since data are generated before rendering. Motion blur for free, melting for free, gradients between hard surface and air, what not should be possible. Hope there will be decent implementation in out-of-the box render engine.... without need to pay for another renderer, just to get it to work properly.

[luceric]

bifrost as a code generator seems to be a great idea if you can use its code in other purposes, other than vfx stuff at least. can you use generated code in your game engine for commercial purposes, for example?

Unfortunately. it's too early right now to talk in any greater detail than that article (which is already quite a book to read!) about Bifrost and possibilities of the underlying tech. We'll all see together how that stuff actually unfolds into products in the future.

[Helli]

And just to mention it cause I heared it several times allready "this is going to be like Ice".

Nope it won't. Like 1 sentence states in the article. "It does not know anything about Maya".

good: you are independent from platforms
not that good: you don't have that deep integration you find in Houdini or Ice.


The only thing which is in there so far when it comes to Ice:
They used Ideas which were in Ice allready (compounds a.e.) but it will NOT be like Ice, at least what you can get information wise from this article.

Edit:
Luc you mentioned that it is a newer aproach of Ice, so can you explain this a bit more ?
Cause in other threads guys from SI mentioned that you can't just port Ice to maya cause of it's deep integration into xsi. So what is now the good/bad stuff about having this platfrom independent.

[ojo3D]

And if all the ex-ICE developers are working on Bifrost, who's working on ICE?

[Ahmidou]

Luc you mentioned that it is a newer aproach of Ice, so can you explain this a bit more ?
Cause in other threads guys from SI mentioned that you can't just port Ice to maya cause of it's deep integration into xsi. So what is now the good/bad stuff about having this platfrom independent.

From my undertanding it compile optimized multithreaded c++ code on the fly, when ICE evaluate precompiled code

[Mathaeus]

And if all the ex-ICE developers are working on Bifrost, who's working on ICE?

Well not all of them. ICE team lead works for Ubisoft since 2009 or so, probably you know who is in Fabric engine. Imho sometime around ICE kinematics, it was clear that ICE 'glass is half empty', but we were looking on this from optimistic side.
By the way, somewhere around Maya acquisition, "Nucleus technology was meant to all AD products, not only Maya" - so Max people believed they'll get something too. But nothing of that, to this very day.