Maya fluids export to Houdini for upresing

[bubbles]

Hi there,

I read it somewhere on the forums that someone was testing exporting Maya fluids caches to Houdini before.

Is there a way to export Maya caches to Houdini as a bgeo to use Houdini's upresing tools?

Any tips, recommendations will be appreciated.

Cheers!

[lukeiamyourfather]

As long as all the data is in place it would probably work just like a Houdini simulated volume. Though you'd have to create a BGEO exporter for Maya that accounts for everything that will be needed (unless one already exists?). My question would be why wouldn't you just do it all in Houdini to begin with?

[bubbles]

We are doing big fire sims and we found Maya fluids give us faster turnarounds (sim time and decent look) than Pyro tools in Houdini. But there is an absolute need to introduce curl noise to the fluids to get the high frequency details that we can't get out of Maya.

So Bgeo will be the way to this? did anyone tried this by using Field3d?

[AdamJ]

Take a look at this for upresing maya fluids..

http://www.soup-dev.com/examples.html

He's got some other nice stuff as well, to bring some of the houdini functionality to maya.

[lukeiamyourfather]

Take a look at this for upresing maya fluids..

http://www.soup-dev.com/examples.html

He's got some other nice stuff as well, to bring some of the houdini functionality to maya.

That's pretty sweet.

I remember seeing a attribute transfer tool on that link before but it looks like quite a few things have been added since.

[ranxerox]

autodesk needs to buy soup from Peter Shipkov.. it makes maya at least twice as good (still about 1/4 as good as houdini but it's a start).

That's pretty sweet.

I remember seeing a attribute transfer tool on that link before but it looks like quite a few things have been added since.

[ranxerox]

I would also think that if you are in a production situation and the result of the maya fluid sims aren't good enough you're better off not getting involved in a research project of getting maya fluid data into houdini .. you're better off doing it in houdini in the first place.

We are doing big fire sims and we found Maya fluids give us faster turnarounds (sim time and decent look) than Pyro tools in Houdini. But there is an absolute need to introduce curl noise to the fluids to get the high frequency details that we can't get out of Maya.

So Bgeo will be the way to this? did anyone tried this by using Field3d?

[bubbles]

Yeah, we have been looking into Peter's work with SOuP, but our decision right now is to export the cache data to Houdini as a bgeo sequence.

We are Houdini based but this project requires Maya fluids and nparticles support.

We are researching to improve our pipeline and be able to transfer all sorts of data from Maya to Houdini and back.

Is there anybody experienced with field3d? would that be a better way than writing bgeo sequences?

[Solitude]

Is there anybody experienced with field3d? would that be a better way than writing bgeo sequences?

I haven't looked into field3d, but I don't think there is any reason to use field3d unless it comes with a maya and/or houdini plugin already, in which case, go for it. If not, then it'll probably require about the same amount of work either way, writing a plugin to read/write to/from maya and houdini.

http://www.digitalcinemaarts.com/dev/SOP_PDC/ might be a good starting point

Edited March 11, 2011 by Solitude

[bunker]

> Option 1

For smoke, Houdini's upres works by re-creating density from a volume source and avecting it using the lowres VEL + extra details.

What you need from Maya : lowres VEL field, objects or particles used as density source and REST for shader noise.

Houdini uses 2 REST fields to avoid noise stretching. Unfortunately, you can't get those from Maya.

For fire, the whole combustion is re-created, so you would have to match Maya's combustion model: not a viable option

> Option 2

There is a way of upresing the volumes on a per-frame basis ( 1 frame advection ).

The lowres DENSITY or HEAT field is not re-created, but just imported for advection.

This result in a slightly more blurry compared to "Option 1" but the frames can

be created in parallel on the farm, and you don't need the volume sources.

The added details in the VEL field need to flow with the DENSITY or HEAT field, so you need REST fields again.

Unfortunately you only get one rest field out of Maya, so you will see a lot of streching in the noise.

IMO, use Houdini fluids.

Houdini's Pyro solver can appear slow compared to Maya fluid ( specially for low resolution sims ),

but you should think about it as a template or a good basic solver to start with.

There are a lot of optimization that can be done that greatly improves the simulation times and memory usage.

Also the upres process allows for a lot more iterations per day.

In the end, you simply won't get the same controls, flexibility and speed in Maya.

I hope this answer your question

[bubbles]

Hi Julien,

Thanks for your detailed reply.

It helps to see what other people did and learned from experience.

We'll rethink our approach and see what fit bests for the production.

Cheers,

[Hazoc]

In the end, you simply won't get the same controls, flexibility and speed in Maya.

BTW, since you're probably pretty burnt out (har har) with pyro tools, what is your opinion about the pyro shader ? I'm pretty sure I understand how it works since I've been playing with it for quite some time, but even though I allmost know what I'm doing I still can't handle it. Every time I try to replicate some flame color, texture and looks, it only ends up making FumeFX looking even more magical to me(haven't ever used). How in the hell do they get so grispy details even with pretty lores volumes.

Another interesting thing is that their shader settings are probably highly reusable. Today I tried to make simple but recyclable pyro shader. On the first fire ball it looked ok. When I tried it with another pyro sim, all the flames were buried under thick smoke and a complete rescaling of the fields and what not intensities had to made.

Edited March 18, 2011 by Hazoc

[bunker]

Personally, I really like the field modifiers and the black body radiation model in the Pyro shader,

but I prefer to create my own using VOPs: for me, it's much quicker to update, and so much faster to render.

I also like to be able to add my own AOVs ( noise, age, temperature, ... ), point cloud lookup

for light scattering and volume displacement at render time when required. It's much easier

to tweak the parameters when you know what they actually do under the hood.

For good details, I use my own optimized version of the Pyro solver so I can push

the resolution high ( over several machines on the farm )

Also, I'm still looking into volume displacement+noise at render time, and volume sharpening in SOPs,

it seems that there is a lot that can be done, with lower resolution sims.

Rendering volumes as points seems to be really promising too, it gives really sharp details,

unfortunately I only tried a SOP approach so far. A render DSO would be ideal.

About re-using the shader, there was an Odforce post about the Pyro shader appearing to be

resolution dependent ( voxel res ). I'm not sure I understand the problem, but I would think

it has to do with the HEAT values being different at different voxel resolutions.

Maybe If the heat values are sampled in a radius, and added together, more voxels would mean more heat.

Anyway in general the heat values are not clamped and so I don't think you can guess how

much heat you will get from sim to sim. Maybe the heat values in Fume FX's shader are averaged per area ?

I hope that makes sense

BTW, since you're probably pretty burnt out (har har) with pyro tools, what is your opinion about the pyro shader ? I'm pretty sure I understand how it works since I've been playing with it for quite some time, but even though I allmost know what I'm doing I still can't handle it. Every time I try to replicate some flame color, texture and looks, it only ends up making FumeFX looking even more magical to me(haven't ever used). How in the hell do they get so grispy details even with pretty lores volumes.

Another interesting thing is that their shader settings are probably highly reusable. Today I tried to make simple but recyclable pyro shader. On the first fire ball it looked ok. When I tried it with another pyro sim, all the flames were buried under thick smoke and a complete rescaling of the fields and what not intensities had to made.

[Hazoc]

Interesting! Would you say your shader is simple ? Grab few fields, do some scaling to them, add noises and map a color ramp based on intensities ? But that's what I thought the pyro shader is also doing, nothing too complex.

Today I continued my tests. This is lowres smoke modified by two 2(in hope of speed gains) octave noise fields. 2*2 pixel samples, 0.5 volume step and 0.8 shadow quality. One spot light with traced shadows. No preview mode. It took 5 minutes!! to render three buckets of this smoke. 8-core Xeon, 12gigs of ram.

I'm simply baffled. I could never promise to deliver any pyro stuff with this until faster rendering is available. And it's so sad since the DOP side of the things is plain awesome second to nothing.

[pclaes]

Ray traced shadows?? That is what is slowing things down -> use shadowmaps instead.

[Hazoc]

Ray traced shadows?? That is what is slowing things down -> use shadowmaps instead.

True. I just thought everybody in the industry these days just hapily raytrace everything but maybe not always in the case of volume shadows:)

[bunker]

LOL, I wish I could raytrace volumes quickly

Yes my shader is very simple. just based on the "basic smoke" shader.

have a look at at the VEX code for the Pyro shader, you'll see there

is a bit more going on

True. I just thought everybody in the industry these days just hapily raytrace everything but maybe not always in the case of volume shadows:)