RE: OT Maya: ncache hell

[Adrian Graham]

Wow, this thread went off the rails quickly.

You can, indeed, plug an animCurve into anything with a 'time' attribute, in 
this case, it would be to the nParticleShape1Cache1.time attribute.

There's a 'Scene Time Warp' feature (look under the Animate menu) in Maya 2015 
that seemed to work on nParticle caches for me. It still doesn't handle 
frame-interpolation properly, but you may be able to crank your subsamples and 
get what you need.

BTW, I think the script you're thinking of is called Time Warper 
(http://www.creativecrash.com/maya/script/time-warper)?

But you guys are all right; Maya is missing the ability to interpolate 
sub-frames automatically in the nCache format. Bifrost's .bif format does not 
have this issue, as points/voxels/etc carry their own velocity data. This means 
you don't have to sample prev/next frames to get motion blur.

Adrian

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker
Sent: Wednesday, February 18, 2015 7:51 PM
To: softimage@listproc.autodesk.com
Subject: Re: OT Maya: ncache hell

Hi Adrian,

thanks for the explanation of your approach. Yes, that sounds like a lot of 
work.

I was thinking more along the lines of asking Autodesk to implement additional 
cache editing as a feature, e.g. be able to retime and reanimate existing 
cached data as if working with a keyframed channel.

Either using an animation curve on the time input or even messing with the full 
data with interpolation between "keyframes", knowing that motionblur will then 
still work nicely.

I would think this could be regarded desireable for working with alembic files, 
bifrost, volumes, particles, animation, etc.

There is a standalone app that let´s you modify particle caches after sim, I 
can´t remember the name atm...

Anyway, asking to get Trax have better interpolation for caches might be 
interesting, too.

Imho, having to decide beforehand how many subsamples/ticks/substeps to store 
in a cache is a bit of a shot in the dark and can easily bloat files while 
still not solving the problem of always getting nice motionblur, regardless of 
shutter settings and lengths that may change later.

I´d think there is room for improvement, ideally allowing to cache to sparse 
data and interpolate for best results.



Am 19.02.2015 um 01:41 schrieb Adrian Graham:
> I've written scripts that do this:
>
> - generate a null for each particle emitted
> - move the null to the updated particle location on each frame
> - keyframe the null after moving it
> - rinse and repeat
>
> So you end up with a big mess of nulls and keyframes, and not much else you 
> do with them.
>
> I suppose you could do the above, then kill particle emission, then do it the 
> other way around; write a runtime expression to emit one particle per null, 
> and move it where each null is at each frame. This would work at any 
> sub-frame, as the runtime expression would query the exact position of the 
> associated null at the current time.
>
> But that's a real roundabout way of doing this, and you'd quickly bog down 
> with hundreds or thousands of particles/nulls.
>
> If you're really interested in doing this, I could try it and record a video 
> showing you how I did it.
>
> Adrian
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com 
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker
> Sent: Wednesday, February 18, 2015 3:59 PM
> To: softimage@listproc.autodesk.com
> Subject: Re: OT Maya: ncache hell
>
> Hi Adrian,
>
> would there be a way to plot/bake an nCache to keyframes per particle and 
> then use the "natural" interpolation happening between keyframes to get 
> better retiming results?
>
> One could then always re-export to a new cache?
>
> If not, that may be an idea to suggest as a feature request?
>
> E.g. the feature request would be to allow the user to edit any cached data 
> input in the fcurve editor as keyframe data with all the interpolation 
> options usually found between two keyframes.
>
> That shouldn´t be insanely complicate to be pulled off as it would "just" 
> require to read cache data as keyframes, then interpolate instead of step, no?
>
> Cheers,
>
> tim
>
>
>
>
> Am 18.02.2015 um 20:05 schrieb Adrian Graham:
>> Er, let's pretend you guys never saw that...
>>
>>
>> From: Ben Beckett mailto:nebbeck...@gmail.com>>
>> Reply-To:
>> "softimage@listproc.autodesk.com<mailto:softim...@listproc.autodesk.co
>> m>"
>> mailto:softim...@listproc.autodesk.co
>> m>>
>> Date: Wednesday, February 18, 2015 at 5:19 AM

RE: OT Maya: ncache hell

[Adrian Graham]

I've written scripts that do this:

- generate a null for each particle emitted
- move the null to the updated particle location on each frame
- keyframe the null after moving it
- rinse and repeat

So you end up with a big mess of nulls and keyframes, and not much else you do 
with them.

I suppose you could do the above, then kill particle emission, then do it the 
other way around; write a runtime expression to emit one particle per null, and 
move it where each null is at each frame. This would work at any sub-frame, as 
the runtime expression would query the exact position of the associated null at 
the current time.

But that's a real roundabout way of doing this, and you'd quickly bog down with 
hundreds or thousands of particles/nulls.

If you're really interested in doing this, I could try it and record a video 
showing you how I did it.

Adrian

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker
Sent: Wednesday, February 18, 2015 3:59 PM
To: softimage@listproc.autodesk.com
Subject: Re: OT Maya: ncache hell

Hi Adrian,

would there be a way to plot/bake an nCache to keyframes per particle and then 
use the "natural" interpolation happening between keyframes to get better 
retiming results?

One could then always re-export to a new cache?

If not, that may be an idea to suggest as a feature request?

E.g. the feature request would be to allow the user to edit any cached data 
input in the fcurve editor as keyframe data with all the interpolation options 
usually found between two keyframes.

That shouldn´t be insanely complicate to be pulled off as it would "just" 
require to read cache data as keyframes, then interpolate instead of step, no?

Cheers,

tim




Am 18.02.2015 um 20:05 schrieb Adrian Graham:
> Er, let's pretend you guys never saw that...
>
>
> From: Ben Beckett mailto:nebbeck...@gmail.com>>
> Reply-To: 
> "softimage@listproc.autodesk.com<mailto:softim...@listproc.autodesk.co
> m>" 
> mailto:softim...@listproc.autodesk.co
> m>>
> Date: Wednesday, February 18, 2015 at 5:19 AM
> To: 
> "softimage@listproc.autodesk.com<mailto:softim...@listproc.autodesk.co
> m>" 
> mailto:softim...@listproc.autodesk.co
> m>>
> Subject: Re: Aw: OT Maya: ncache hell
>
> Maya 2016!
>
> On 18 February 2015 at 04:23, Adrian Graham 
> mailto:adrian.gra...@autodesk.com>> wrote:
> Hey guys, the best way to retime nCaches is in the Trax editor. Select the 
> cached node and open the editor. You'll see a bar representing the length of 
> your cache on disk. You can expand/compress this bar to achieve the retiming 
> you desire. You can't ramp-in/ramp-out the speed, unfortunately. Not without 
> extremely unpredictable results, that is.
>
> Now it gets tricky, so I recorded a couple of videos (in .swf format) to 
> maybe provide a bit of insight:
>
> nCache_retiming_01.swf<https://autodesk.box.com/s/ves0ye66ny9sc0y78a8c
> k8xi8af2zyns> 
> nCache_retiming_02.swf<https://autodesk.box.com/s/bxwfnuupxw11fz9tvfr9
> 4k72djb9fwfv>
>
> Also, as I mentioned at the end of the second video, a suggestion from one of 
> our devs here is to goal 'classic' particles to your nParticles 
> (post-retiming), cache those out and render them, rather than the nParticles:
>
> You could export it as a classic particle cache (with dynExport) , and then 
> create a classic particle shape with exactly the same set of  attributes as 
> you exported. (which means that you either have to explicitly specify the 
> list of PP attrs so that you don't end up with ramp input attrs, or you may 
> need to add any extra cached attrs to the classic particle system).
>
> Hope this helps,
> Adrian
>
> From: 
> softimage-boun...@listproc.autodesk.com<mailto:softimage-bounces@listp
> roc.autodesk.com> 
> [mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-bounc
> e...@listproc.autodesk.com>] On Behalf Of Gerbrand Nel
> Sent: Monday, February 16, 2015 4:59 AM
> To: 
> softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com
> >
> Subject: Re: Aw: OT Maya: ncache hell
>
> Ugh
> Well thanks for the heads-up.
> G
> On 16/02/2015 11:50, Leo Quensel wrote:
> I've been through this hell.
> Long story short: Do it in Softimage, it is next to impossible to do it 
> properly in Maya and it is a buggy mess.
>
> Gesendet: Montag, 16. Februar 2015 um 10:45 Uhr
> Von: "Gerbrand Nel" 
> mailto:nagv...@gmail.com>><mailto:nagv...@gmail.com
> <mailto:nagv...@gmail.com>>
> An: 
> softimage@listproc.autodesk.com<mailto:softimage@listproc.auto

Re: Aw: OT Maya: ncache hell

[Adrian Graham]

Er, let’s pretend you guys never saw that...


From: Ben Beckett mailto:nebbeck...@gmail.com>>
Reply-To: 
"softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Date: Wednesday, February 18, 2015 at 5:19 AM
To: "softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Subject: Re: Aw: OT Maya: ncache hell

Maya 2016!

On 18 February 2015 at 04:23, Adrian Graham 
mailto:adrian.gra...@autodesk.com>> wrote:
Hey guys, the best way to retime nCaches is in the Trax editor. Select the 
cached node and open the editor. You’ll see a bar representing the length of 
your cache on disk. You can expand/compress this bar to achieve the retiming 
you desire. You can’t ramp-in/ramp-out the speed, unfortunately. Not without 
extremely unpredictable results, that is.

Now it gets tricky, so I recorded a couple of videos (in .swf format) to maybe 
provide a bit of insight:

nCache_retiming_01.swf<https://autodesk.box.com/s/ves0ye66ny9sc0y78a8ck8xi8af2zyns>
nCache_retiming_02.swf<https://autodesk.box.com/s/bxwfnuupxw11fz9tvfr94k72djb9fwfv>

Also, as I mentioned at the end of the second video, a suggestion from one of 
our devs here is to goal ‘classic’ particles to your nParticles 
(post-retiming), cache those out and render them, rather than the nParticles:

You could export it as a classic particle cache (with dynExport) , and then 
create a classic particle shape with exactly the same set of  attributes as you 
exported. (which means that you either have to explicitly specify the list of 
PP attrs so that you don't end up with ramp input attrs, or you may need to add 
any extra cached attrs to the classic particle system).

Hope this helps,
Adrian

From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Gerbrand Nel
Sent: Monday, February 16, 2015 4:59 AM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Aw: OT Maya: ncache hell

Ugh
Well thanks for the heads-up.
G
On 16/02/2015 11:50, Leo Quensel wrote:
I've been through this hell.
Long story short: Do it in Softimage, it is next to impossible to do it 
properly in Maya and it is a buggy mess.

Gesendet: Montag, 16. Februar 2015 um 10:45 Uhr
Von: "Gerbrand Nel" 
mailto:nagv...@gmail.com>><mailto:nagv...@gmail.com<mailto:nagv...@gmail.com>>
An: 
softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com><mailto:softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>>
Betreff: OT Maya: ncache hell
Hey guys
So I have to re-time my particles in Maya, and no one seems to know how
to do this properly.
Do you guys know if I can bring them into softimage, re-time, and then
re-export the ncache to maya?
Even if you know how to do it with houdini, please shout!
Thanks guys



<>

RE: Aw: OT Maya: ncache hell

[Adrian Graham]

Hey guys, the best way to retime nCaches is in the Trax editor. Select the 
cached node and open the editor. You’ll see a bar representing the length of 
your cache on disk. You can expand/compress this bar to achieve the retiming 
you desire. You can’t ramp-in/ramp-out the speed, unfortunately. Not without 
extremely unpredictable results, that is.

Now it gets tricky, so I recorded a couple of videos (in .swf format) to maybe 
provide a bit of insight:

nCache_retiming_01.swf
nCache_retiming_02.swf

Also, as I mentioned at the end of the second video, a suggestion from one of 
our devs here is to goal ‘classic’ particles to your nParticles 
(post-retiming), cache those out and render them, rather than the nParticles:

You could export it as a classic particle cache (with dynExport) , and then 
create a classic particle shape with exactly the same set of  attributes as you 
exported. (which means that you either have to explicitly specify the list of 
PP attrs so that you don't end up with ramp input attrs, or you may need to add 
any extra cached attrs to the classic particle system).

Hope this helps,
Adrian

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Gerbrand Nel
Sent: Monday, February 16, 2015 4:59 AM
To: softimage@listproc.autodesk.com
Subject: Re: Aw: OT Maya: ncache hell

Ugh
Well thanks for the heads-up.
G
On 16/02/2015 11:50, Leo Quensel wrote:
I've been through this hell.
Long story short: Do it in Softimage, it is next to impossible to do it 
properly in Maya and it is a buggy mess.

Gesendet: Montag, 16. Februar 2015 um 10:45 Uhr
Von: "Gerbrand Nel" 
An: softimage@listproc.autodesk.com
Betreff: OT Maya: ncache hell
Hey guys
So I have to re-time my particles in Maya, and no one seems to know how
to do this properly.
Do you guys know if I can bring them into softimage, re-time, and then
re-export the ncache to maya?
Even if you know how to do it with houdini, please shout!
Thanks guys


<>

RE: ICE - When will we have todays functionality in Maya?

[Adrian Graham]

Look, I can't comment exactly on where we're going with Bifrost, this is where 
I run into all sorts of SEC limitations and stuff. I could defer to ChrisV to 
answer those questions in a more official manner.

Rest assured we're aware that ICE is more than just FX, more than particles and 
simulation, that it's a complete procedural workflow involving all kinds of 
data, throughout the package.

Adrian

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sebastian Kowalski
Sent: Friday, March 21, 2014 10:38 AM
To: softimage@listproc.autodesk.com
Subject: Re: ICE - When will we have todays functionality in Maya?

thats is my concern too. as much as I embrace a decoupling from maya, its how 
ICE is capable to talk to different scene elements that makes it so powerful.
managing data until the very least work process  at render time. and we are in 
full control.
as beautiful big ass fluid sims look, its not what we day for day.
please have a look on the 'what uses is ICE?' thread 
(https://groups.google.com/forum/#!topic/xsi_list/7aGyes8lBQE)

thanks

Am 21.03.2014 um 18:29 schrieb Alastair Hearsum 
mailto:hear...@glassworks.co.uk>>:


Hi Adrian

I'm no egg head so forgive the simplicity of my question. Would this platform 
agnostic scenario actively prevent any of the procedures and scenarios that we 
currently use ICE for?  Is ICE so functional because its embedded in Softimage? 
 Can we have the same functionality with a non embedded engine?

Alastair
Alastair Hearsum
Head of 3d
[GLASSWORKS]
33/34 Great Pulteney Street
London
W1F 9NP
+44 (0)20 7434 1182
glassworks.co.uk<http://www.glassworks.co.uk/>
Glassworks Terms and Conditions of Sale can be found at 
glassworks.co.uk<http://glassworks.co.uk/>
(Company registered in England with number 04759979. Registered office 25 
Harley Street, London, W1G 9BR. VAT registration number: 86729)
Please consider the environment before you print this email.
DISCLAIMER: This e-mail and attachments are strictly privileged, private and 
confidential and are intended solely for the stated recipient(s). Any views or 
opinions presented are solely those of the author and do not necessarily 
represent those of the Company. If you are not the intended recipient, be 
advised that you have received this e-mail in error and that any use, 
dissemination, forwarding, printing, or copying of this e-mail is strictly 
prohibited. If this transmission is received in error please kindly return it 
to the sender and delete this message from your system.
On 21/03/2014 16:53, Adrian Graham wrote:

Ah, but may I respectfully point out that this was one of the problems with 
ICE, in that its complete and total integration into Softimage makes it 
difficult to engineer and manage, from a software and, unfortunately, a 
marketing point of view.



Most modern software libraries are platform-agnostic, and this is what we're 
aiming for with Bifrost. The problem with ICE is that you had to use Softimage 
in order to gain access to it. Nothing against Softimage, just that you're 
limiting ICE's exposure to the industry at large.



Would a renderer be more or less popular if it only worked with Maya, and not 
with Max or Houdini? No, it should be available on all applications, on all OSs 
if you want it to be successful.



Adrian



<>

RE: ICE - When will we have todays functionality in Maya?

[Adrian Graham]

Well, yes and no.

When you see particles in Bifrost, what you're looking at are FLIP particles, 
which are part of how the FLIP solver works. My meager brain understands it as 
the particles contain the velocity data, which generate a level-set, which 
generate voxels, and in turn the voxels affect the velocity data. There's 
people on my team much smarter than me who can explain this better.

So you can view Bifrost sims as particles or voxels, but you're not looking at 
a particle sim, per se.

When I talk about mist, foam and spray, those are generated from the Bifrost 
sim itself, as secondary sims. Now those are particles, but they're Bifrost 
particles, not Maya particles, and there's a big difference. Bifrost particles 
have been developed to utilize the new functionality in Viewport 2.0, which is 
part of the OGS project at Autodesk (One Graphics 
System<http://adndevblog.typepad.com/manufacturing/2012/05/using-intel-threading-building-blocks-tbb-in-autodesk-products.html>).
 This means you can display tens of millions of particles in the viewport 
interactively, unlike most other applications (depending on your graphics card, 
obviously).

But as of now, no, Bifrost cannot perform particle simulations and control them 
with fields/forces/collisions as you would in the classic sense. Not yet, at 
least.

Adrian


From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Chris Marshall
Sent: Friday, March 21, 2014 9:53 AM
To: softimage@listproc.autodesk.com
Subject: Re: ICE - When will we have todays functionality in Maya?

But just to be clear, everything you're talking about is essentially particles 
related? Feels like we're stepping back to ICE zero point five!

On 21 March 2014 16:45, Adrian Graham 
mailto:adrian.gra...@autodesk.com>> wrote:
Yes, this first release is liquids-focused (note: *fluids* are an entirely 
different solver, which we call the 'aero' - aerodynamic -- solver). Future 
releases could encompass more types of solvers (rigid, cloth, fluid, liquid, 
etc, all interacting). And from there, it would be amazing to see more 
procedural geometry generation, destruction and stuff like that.

But we gotta take this one step at a time, and design the foundation carefully 
if we want to accommodate all that.
Adrian

From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of joshxsi
Sent: Thursday, March 20, 2014 6:09 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: ICE - When will we have todays functionality in Maya?
Part of what made ICE so successful (in my mind) was the large amount of built 
in nodes and compounds that were included as part of the base system that were 
used in mostly non-simulated contexts (raycasting, geometry locations, etc).

>From the sound of the development stages, the first two releases will be fluid 
>focused, do you expect that the final release will include the non particle 
>functionality that ICE became so useful for?

It sounds like you're expecting the users to build a more generic set of 
functionality using the API? (mesh deforms, curve based flow tools, IK solvers 
etc)

Thanks again for the information as well.

On Fri, Mar 21, 2014 at 11:48 AM, David Gallagher 
mailto:davegsoftimagel...@gmail.com><mailto:davegsoftimagel...@gmail.com<mailto:davegsoftimagel...@gmail.com>>>
 wrote:

Yes, definitely giving them a chance! If they turn Maya/Bifrost into something 
great that can give me back what I just lost, believe me I will be one happy 
guy.


On 3/20/2014 6:29 PM, Raffaele Fragapane wrote:
The product will be released within the quarter. To be fair, that info if you 
were on beta has been consistent and available for quite a while now, so it's 
not some last minute stunt.

Marcus, Adrian and the rest of the team are nice guys, give them a chance.
On Fri, Mar 21, 2014 at 11:17 AM, David Gallagher 
mailto:davegsoftimagel...@gmail.com><mailto:davegsoftimagel...@gmail.com<mailto:davegsoftimagel...@gmail.com>>>
 wrote:
This email was fascinating. I'm curious though; we've been told we can't hear 
roadmaps because they run afoul of SEC rules. And yet, here we get a somewhat 
detailed roadmap.

Dave G





--
[http://mintmotion.co.uk/img/mint.png]
Chris Marshall
Mint Motion Limited
029 20 37 27 57
07730 533 115
www.mintmotion.co.uk<http://www.mintmotion.co.uk>

<>

RE: ICE - When will we have todays functionality in Maya?

[Adrian Graham]

Ah, but may I respectfully point out that this was one of the problems with 
ICE, in that its complete and total integration into Softimage makes it 
difficult to engineer and manage, from a software and, unfortunately, a 
marketing point of view.

Most modern software libraries are platform-agnostic, and this is what we're 
aiming for with Bifrost. The problem with ICE is that you had to use Softimage 
in order to gain access to it. Nothing against Softimage, just that you're 
limiting ICE's exposure to the industry at large.

Would a renderer be more or less popular if it only worked with Maya, and not 
with Max or Houdini? No, it should be available on all applications, on all OSs 
if you want it to be successful.

Adrian

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Chris Marshall
Sent: Friday, March 21, 2014 6:52 AM
To: softimage@listproc.autodesk.com
Subject: Re: ICE - When will we have todays functionality in Maya?

I think we can see there's some reason to look into Bifrost, but I also have a 
nagging feeling it's simply never going to achieve the same level of 
functionality as ICE, for the very reason ICE is essentially being shut down. 
ICE does what it does and is so much more than a particle system, because it is 
built into the very core of Softimage. To attempt to make Bifrost 'future 
proof' they are deliberately *not* building it into the core of Maya, thus 
allowing for the potential for it to be standalone and / or plugged into other 
software / platforms at a later date. But by approaching it in this way, it'll 
only ever be a bolt on, that surely can never achieve that level of flexibility 
that we have with ICE at the heart of Softimage. It feels that the very thing 
that makes ICE such an amazing tool is actually causing it's downfall, and is 
the reason Bifrost can never replace it. And that totally sucks!



On 21 March 2014 10:29, Juan Brockhaus 
mailto:juanxsil...@gmail.com>> wrote:

Hey Adrian,
this is some great info here. and makes me suddenly feel spmehow better ;-)
maybe in two/three years time, when Soft slowly falls back (just due to no 
further development) BiFrost will be in a state where it can take over...? 
(wishful thinking)
If I read between the lines I feel there is hope that BiFrost is not 'just' a 
fluid simulation system and can be used for far more.

Exactly what I personally (and many others) love about ICE. It is (contrary to 
past Autodesk-PR) NOT just a particle-simulation-system, but a swiss army tool 
which can manipulate almost every aspect of data in my scene/objects and build, 
create, deform, etc...
ie at the moment I build shapes/objects made out of dominos. All procedurally 
build in ICE. I made different compounds to stack and pile dominoes in 
different ways and methods. And if the objects I have to create (and even the 
domino) change (as usual in commercials..) it is all instantly updated.
Only right at the end I add a Sim node and the whole things collapses... 
(obviously controlled with nulls, forces, etc...) The Sim is basically the last 
5% of what I use ICE for.
If I can do stuff like this in BiFrost in the future I'm a happy camper.
Right now the only other software capable of that would be Houdini...
I'll keep an eye on BiFrost ;-)
Cheers,
Juan





On Fri, Mar 21, 2014 at 1:09 AM, joshxsi 
mailto:josh...@gmail.com>> wrote:
Part of what made ICE so successful (in my mind) was the large amount of built 
in nodes and compounds that were included as part of the base system that were 
used in mostly non-simulated contexts (raycasting, geometry locations, etc).

>From the sound of the development stages, the first two releases will be fluid 
>focused, do you expect that the final release will include the non particle 
>functionality that ICE became so useful for?

It sounds like you're expecting the users to build a more generic set of 
functionality using the API? (mesh deforms, curve based flow tools, IK solvers 
etc)

Thanks again for the information as well.


On Fri, Mar 21, 2014 at 11:48 AM, David Gallagher 
mailto:davegsoftimagel...@gmail.com>> wrote:

Yes, definitely giving them a chance! If they turn Maya/Bifrost into something 
great that can give me back what I just lost, believe me I will be one happy 
guy.


On 3/20/2014 6:29 PM, Raffaele Fragapane wrote:
The product will be released within the quarter. To be fair, that info if you 
were on beta has been consistent and available for quite a while now, so it's 
not some last minute stunt.

Marcus, Adrian and the rest of the team are nice guys, give them a chance.

On Fri, Mar 21, 2014 at 11:17 AM, David Gallagher 
mailto:davegsoftimagel...@gmail.com>> wrote:
This email was fascinating. I'm curious though; we've been told we can't hear 
roadmaps because they run afoul of SEC rules. And yet, here we get a somewhat 
detailed roadmap.

Dave G







--
[http://mintmotion.co.uk/img/mint.png]
Chris Marshall
Mint Motion Limit

RE: ICE - When will we have todays functionality in Maya?

[Adrian Graham]

Yes, this first release is liquids-focused (note: *fluids* are an entirely 
different solver, which we call the 'aero' - aerodynamic -- solver). Future 
releases could encompass more types of solvers (rigid, cloth, fluid, liquid, 
etc, all interacting). And from there, it would be amazing to see more 
procedural geometry generation, destruction and stuff like that.

But we gotta take this one step at a time, and design the foundation carefully 
if we want to accommodate all that.
Adrian

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of joshxsi
Sent: Thursday, March 20, 2014 6:09 PM
To: softimage@listproc.autodesk.com
Subject: Re: ICE - When will we have todays functionality in Maya?

Part of what made ICE so successful (in my mind) was the large amount of built 
in nodes and compounds that were included as part of the base system that were 
used in mostly non-simulated contexts (raycasting, geometry locations, etc).

>From the sound of the development stages, the first two releases will be fluid 
>focused, do you expect that the final release will include the non particle 
>functionality that ICE became so useful for?

It sounds like you're expecting the users to build a more generic set of 
functionality using the API? (mesh deforms, curve based flow tools, IK solvers 
etc)

Thanks again for the information as well.


On Fri, Mar 21, 2014 at 11:48 AM, David Gallagher 
mailto:davegsoftimagel...@gmail.com>> wrote:

Yes, definitely giving them a chance! If they turn Maya/Bifrost into something 
great that can give me back what I just lost, believe me I will be one happy 
guy.


On 3/20/2014 6:29 PM, Raffaele Fragapane wrote:
The product will be released within the quarter. To be fair, that info if you 
were on beta has been consistent and available for quite a while now, so it's 
not some last minute stunt.

Marcus, Adrian and the rest of the team are nice guys, give them a chance.

On Fri, Mar 21, 2014 at 11:17 AM, David Gallagher 
mailto:davegsoftimagel...@gmail.com>> wrote:
This email was fascinating. I'm curious though; we've been told we can't hear 
roadmaps because they run afoul of SEC rules. And yet, here we get a somewhat 
detailed roadmap.

Dave G



<>

RE: ICE - When will we have todays functionality in Maya?

[Adrian Graham]

Second thought: in my long-winded email I tried to explain the current 
technology in Bifrost, not what's planned for the future. So stuff like the 
Bifrost Computation Server, threading, memory management, Maya being a 'client' 
to Bifrost; these are all things in place right now in Maya 2015.

Adrian

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Adrian Graham
Sent: Thursday, March 20, 2014 5:38 PM
To: softimage@listproc.autodesk.com
Subject: RE: ICE - When will we have todays functionality in Maya?

Perhaps, but it is a general enough roadmap that has already been discussed in 
a few channels (if unofficial).

Also, the 'generalist' release is Maya 2015, so no surprises there.

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of David Gallagher
Sent: Thursday, March 20, 2014 5:17 PM
To: softimage@listproc.autodesk.com
Subject: Re: ICE - When will we have todays functionality in Maya?

This email was fascinating. I'm curious though; we've been told we can't hear 
roadmaps because they run afoul of SEC rules. And yet, here we get a somewhat 
detailed roadmap.

Dave G

<>

RE: ICE - When will we have todays functionality in Maya?

[Adrian Graham]

Thanks for the positive words, everyone.

"2nd question, is of course, when is an estimate for stage 2 ICE like node 
editing. is that likely to be a service pack in current Maya or a 2016. or?"

Sadly, this is *exactly* the kind of question I cannot answer in any official 
capacity. You guys are all free to get on the Maya beta program and be privy to 
this kind of information. That, AND be the first ones on your block to try out 
new Bifrost functionality.

If you want to be signed up for the beta, ping me and I'll get you an invite.

Adrian

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman
Sent: Thursday, March 20, 2014 5:35 PM
To: softimage@listproc.autodesk.com
Subject: Re: ICE - When will we have todays functionality in Maya?

Adrian,

well written and a lot of facts & information, thank you! the team and the 
project sounds amazing and exciting stuff indeed. am happy that you are happy, 
its refreshing indeed. so welcome!

first question:
you mention it can run on clouds, consoles , Atari 2600's will that list 
include softimage? :D

2nd question, is of course, when is an estimate for stage 2 ICE like node 
editing. is that likely to be a service pack in current Maya or a 2016. or?

again. good news. for a change!
<>

RE: ICE - When will we have todays functionality in Maya?

[Adrian Graham]

Perhaps, but it is a general enough roadmap that has already been discussed in 
a few channels (if unofficial).

Also, the 'generalist' release is Maya 2015, so no surprises there.

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of David Gallagher
Sent: Thursday, March 20, 2014 5:17 PM
To: softimage@listproc.autodesk.com
Subject: Re: ICE - When will we have todays functionality in Maya?

This email was fascinating. I'm curious though; we've been told we can't hear 
roadmaps because they run afoul of SEC rules. And yet, here we get a somewhat 
detailed roadmap.

Dave G

On 3/20/2014 5:30 PM, Adrian Graham wrote:
> 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 ot

RE: ICE - When will we have todays functionality in Maya?

[Adrian Graham]

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
M&E Film & TV Solutions
<>