fluid caches, again..

[John Cassella]

I know this has probably been  brought up  a million times  at this point,  but I'm having problems getting  a cached  fluid simulation to run on our farm.

when it loads up  a frame,  it says  "this file contains an uncached fluid....."    yet the file has a perfectly  good  full path to the fluid  in it.

the only way i've gotten it to work  in the past is to  run it  linearly  on one machine .. which is  not really an option for speed of rendering really..

I really wish/hope they fix   all the Ncache stuff in the next  version of maya.. this is really getting ridiculous..  I don't even use it anymore.


thanks for any help

-johnc

[Cosku Ozdemir]

Hi,
Here is an email I sent out to the highend3d list about a year ago:

///////////////////////////////////////////////////////////////////////////////////////////////////
If you're on windows, you can use a plugin I wrote which has built-in
functionality for custom caching (the rest is for dynamic fluid resizing).

It's uber-simple, basically it has 2 commands, one to write out the
density/temperature/fuel/velocity arrays of the fluid to binary files

on the disc, and another command to read them back in.

You can get the win32 & win64 compiles for it here:
http://coskuozdemir.com/blog/?p=45

Once you load the plugin, the 2 commands you need to use are:
--   co_fluidAutoResizeCache
--   co_fluidAutoResizeCacheRead

On any given frame, to cache the contents, you'd run:
co_fluidAutoResizeCache -o FlameShape -path "c:\\tmp\\" -basename
"flame" -density -velocity -fuel -temperature

That'd write out the files
C:\tmp\flame.density.0058.bin
C:\tmp\flame.velocity.0058.bin
C:\tmp\flame.fuel.0058.bin
C:\tmp\flame.temperature.0058.bin

etc.. So you'd loop over all the frames calling the same command, and
it fills in the currentFrame number automatically for you.

To read them back in at rendertime, you'd run this as a pre-render MEL command:
co_fluidAutoResizeCacheRead -o FlameShape -path "c:\\tmp\\" -basename
"flame" -density -velocity -fuel -temperature

And it'd overwrite all the arrays of the fluid from the files off disk.
You should be able to swap the paths with network-accessable ones.

Good luck,

-c

[John Cassella]

Cool, unfortunately  we're not  on windows tho,  working in linux  :-(   but it just confirms that there are still problems.
thanks anyway man
-john

[Duncan Brinsmead]

John, could you show the actual pathname you are trying to resolve? Also what is your Maya version?

Fluids caching should generally be less painful than it was before it switched to nCaches, but there are still some issues. Blend nodes have had a few problems. As well if you attached an existing cache to a fluid there is a problem where not all the cache channels get connected.

 

Do you have problems with a simple default fluid, cached then rendered on the farm? (i.e. is your problem specific to the settings of that scene, or can you not get any cached fluid to render on your farm)

 

Duncan

[John Cassella]

Hi Duncan,  thanks for the  response, 
the path looks like this..

/Volumes/company/show/byPrefix/ZP/ZP_004_0250/fx/maya/data/ZP_004_0250_fxDoorMayaFluid_A01_JCA

file name is  fluidShape1.xml

I don't know if it would help. but I tried changing it in the ascii file to a "relative path"   of  data/ZP_004_0250_fxDoorMayaFluid_A01_JCA 
and  it  responded that it couldn't find the   cache at 

/Volumes/company/show/byPrefix/ZP/ZP_004_0250/fx/maya/scenes/data/ZP_004_0250_fxDoorMayaFluid_A01_JCA

I am not sure if thats what it is supposed to  do in that case or not, I'm wondering if somehow our  render submit script is  not setting the project correctly or something?
all our other renders seem to work just fine tho. 

we're rendering with  mental ray  by the way. 

I haven't tried to  hook up  an existing cache to a fluid either,  that will be another test I could try.

I'm going to have to put together a simpler test scene,  strangely enough  it is still throwing the warning in the  render  log, but  it seems that its actually rendering  the fluid, but I'm not sure if its  the right  position of the fluid  at that frame, that has been our problem in the past,  that it  still renders something, but it may not be the simulation as we tested it in the  viewport.

  I need to verify if it looks the same coming out of the renderviewport and  the  batch.. 

I'll  keep the thread alive as soon as I can figure it out, but either way the warning  does seem wrong if its acutally working.?

thanks

-johnc

[Duncan Brinsmead]

It is possible that that warning is being falsely triggered during file load, before everything is hooked up and initialized. But I’ll look into it so see if there is something with your setup. The fact that it only complained about the path when you changed it suggests that it was getting and using your cache initially, despite the uncached fluid message. Is it possible your scene has some other fluid that is not cached? (for example a fluid wake on an ocean or a pond)

 

Are you using single or per-frame caches?

[John Cassella]

hmm,  The warning  was issued  no matter what,  relative path or  non relative path,     I just tried changing it to relative path  style  to see if that would make it go away.   when I tried this I did get blank frames,  vs  with the absolute path  it did render the fluid.  so it appears that maybe it is  as you suspect, the warning is getting issued falsely before everything is loading up.

 It is the only  fluid object  in the scene,   and I'm using  one file per frame  caching.

-john

[Duncan Brinsmead]

In terms of the paths, it does seem odd that your cache directory is the scenes folder. Normally the data folder is directly under your project, not inside “scenes”. (however that should not mess up the cache read)

[John Cassella]

Fluid caches... still having same weirdness, now in 2011.

OK so I have a really simple file.  Its a  big  cloud bank,   its cached up 100 frames.  
there are 2 directional lights,   default  persp camera and  the fluid, thats it.


The problem I'm having is  super slowness  at  batch render time, in mental ray.

I raced the files  to see what the diff  is.

On the same machine:

I run  from the command line:

Render -mr:v 5  -s 82 -e 82  testRenderClouds2.ma

it takes  36 secs   to load up mayarender  and load the scene

then it pauses... for about 2:45-4:00 minutes ??????????? 

then it renders  in   20 secs.

total: about 5 minutes.

Now,  I can  do the same exact process within a GUI session of maya  and   to do the entire thing
it takes under  2 minutes.

28 secs   maya load time.
20 secs to load the file
14 secs to jump to frame 82
18 secs to render the frame

Total about  1:30ish  give or take  user speed.

now as a theory tester,  I rendered frame 10  from the render command.
the pause now only lasted under  15-20 seconds..    right in line with my theory..


so here's  what I think is happening:

when you  launch a render thru the command line:  
Maya errors out with:
Warning: This file contains an uncached fluid; rewind and playback to see correct current state, no matter what, if you have a cache  on your fluid or not.

I've been seeing this error for at least the last 3 versions of maya now, probably since the  switch  to Ncache style caches?

once this flag is  set,  to maya,   it cannot jump  to the frame  it needs to  anymore,  so  it "rewinds and playback to see correct current state"  to get to the frame you want to render.
It is definintely  not  running up  the whole cache   in this case  because  these  fluids are generated by an emitter that is not even in the scene anymore, but it eventually DOES render a proper frame,  so it   is obviously still reading the cache to render.   but its not able to jump to the frame immediately  like it should.   on MASSIVE caches, in length and data size this  runup hit  is bringing our  farm to a screeching halt every time we throw a render on the farm.  becuase  every machine thats rendering the fluid sim is  pulling  the data from the  entire cache thru  the network  one frame at a time until its  designated frame  to render.  which is  a  ton of wasted overhead and farm time. 

I am pretty certain that this is the problem I've been seeing and working around for the last  2+ years now  and  I am now in search of  solutions.   perhaps a  pre-render mel command  to  jump to the frame?     or  is  there  a   specific script thats throwing this  uncached fluid error that we can modify  or fix  to  get rid of  the problem entirely?

I'm open to suggestions and  ideas,  anybody else ever see this before? 

thanks  in advance..   whatever I come up with  I'll share back with the group  asap.

-thanks

johnc
redpawFX

[matt estela]

definitely, DEFINITELY not a fix, but if you're really under some
deadline pressure there's a few scripts around to render a sequence
directly from the renderview. A mate of mine was caught in this bind
recently, said this one worked really well:

http://www.creativecrash.com/maya/marketplace/scripts-plugins/rendering/misc/c/ikas-render-view-renderer

re the problem itself, i wonder if its problems in terms of just not
having enough control over the maya -> .mi (either on disk or in
memory) -> render process. Could be doing something awful like trying
to reload and re-write the entire fluid cache for the whole sequence
per frame. Ugh.

Other things you could try, forgive me if some sound obvious/outlandish/insane:

-if you're not using FG/raytracing effects, try using the maya
software renderer? With fluids I've found it doesn't need all the
grunt (and associated problems) that mentalray gives
-write out an .mi sequence for the fluid, then read it back in via a
proxy? I wrote some notes on this process:
http://www.tokeru.com/t/bin/view/Maya/MayaMentalRay#Proxies
-get mentalray standalone, avoiding the above process?
-go an alternative renderer that does fluids, like 3delight or prman
(3delight free for 1 license, prman... not so much)

Let us know how you go.

-matt

[Sagroth]

Sorry, I had no time to read your posts thoroughly now (I'm in a
hurry), but I was fighting this issue last week in maya 2009 - when
renderfarm started rendering frames separately, first ones were 10
minutes and then progressively raising to 2 hours just to begin
rendering one of the last ones, and network load was over the top.

I've found info about this issue from many years ago - that's a known
bug from the ancient times (I'm not really surprised though - maya is
a pack of revolutionary stuff that never really work without a
headache and until the project is almost completely f*up) - it makes a
runups for each frame you start rendering from, and actually not just
once, but multiple times. To eliminate this problem the solution was -
to set startFrame of the fluids to the starting frame of your current
rendering. But I guess there're new "improvements" nowadays - fluids
render black at the first frame of this setup, so I need to set
"starting frame of my rendering - 1" - then it works.

That could be done with prerender MEL (I also disable evaluation of
all particles in the scene and then enable them with postrender MEL):

prerender MEL:
setAttr fluidShape1.startFrame (`getAttr
defaultRenderGlobals.startFrame`-1); string $pts[] = `ls -type
particle`; for( $pt in $pts ) setAttr ($pt + ".isDynamic") 0;

postrender MEL:
string $pts[] = `ls -type particle`; for( $pt in $pts ) setAttr ($pt +
".isDynamic") 1;

Hope that helps.

[Duncan Brinsmead]

Hi John,

 

Could you submit a bug report for that scene? The scene file should be good enough without the cache files. It definitely sounds like a runup is getting triggered, which should not be happening given that everything in your scene is cached. The suggested workaround of setting the fluid start frame to the start frame of each render sequence is the best one I know of currently to stop a runup. If you want to do it automatically you can’t simply key the startframe value on the fluid to be the current frame, but rather need to set it in a script.

 

There is another problem with runups currently in that they tend to happen twice… once on file load then a second time at the start of the render sequence( the renderer usually does a preframe evaluation step, which ends up triggering a runup). However in the case of a cached fluid it should not happen. (however if there were any other uncached dynamics entities in the scene then they could be triggering a runup) However even with a cached fluid this problem means the fluid cache will be read 3 times at the start of a sequence. (although in all cases it should only be read once for frames within a render sequence)

 

I’ve been thinking that we need an attribute to allow users to disable batch render runups( generally if you render on a farm,  out of sequence, or with motion blur , you should always have everything cached anyways).

The logic to generate runups can be confounded in different cases. For example playing beyond the range of a cache can cause a simulation when a user may just want to see nothing or the end step of the simulation. We recently fixed a problem where if the simulation start frame was high it did a runup to the start frame.

 

Duncan

[Duncan Brinsmead]

It turns out there is a known caching bug(that we are currently fixing) that was introduced with nCaching on fluids where one always gets a runup at the start of a render sequence. The workaround is to set ALL your dynamic fluid grids to static after caching. ( I can’t say when the proper fix will become available.)

 

Duncan

[John Cassella]

Hi Duncan,  so since  you guys have an existing bug do I need to submit another report?  It sounds like its already in the works.   

Just as a quick update: 
before  I got your  message  I gave the   setting startFrame  to  currentRender frame -1 thing  suggested by sagroth and  it seemed to work pretty well,  we're currently  going to
try to get that into  the pre-render on our farm calls  and see if it helps..   its good tho that there may be yet another fix we can try if we continue to have issues or something else weird crops up 


ultimately right now we're implementing       something like 

getAll fluids in scene,   iterate thru them  setting   startFrame to    max(renderFrame, existing startFrame)   just in case some fluids have a  startframe later than the current  render frame.

I'll let you know how it all goes..  and thanks again for the info  and  quick responses guys, I can always count on folks here to help, its definitely appreciated.

-johnc
redpawFX

[ranxerox]

hey Duncan, would setting 'disable evaluation' on the fluid be
another solution ? I would be afraid the changing all the contents
methods to static grid might cause a problem if you were doing
multiple iterations of a scene and forgot to turn one of the contents
methods back to dynamic grid or something like that.

-G

On May 27, 2:03 pm, Duncan Brinsmead <Duncan.Brinsm...@autodesk.com>
wrote:

[John Cassella]

We implemented Both the startframe fix and  the  static grid fix  at render time only,  as a premel script.  

The  Static grid fix  by itself seemed to be less stable and  ended up crashing  some scenes we threw at it, so we ended up adding the start frame thing to it as well..
Actually,  my question would be  if  with turning the grids to static  will the  fluid still motion blur properly?   all our tests are on pretty slowly moving stuff so  we haven't had time to try moblur yet.    Either way  moblur has its issues I guess... 

hope this all helps

-johnc
redpawfx

[Duncan Brinsmead]

It is strange that setting the fluid to static resulted in a crash… if the fluid is cached it really should make no difference other than to avoid the runup. (which setting the start frame also does)

If you are getting a crash it might be worth submitting a bug file. It also should make no difference for motion blur, either, as this is not computed for fluids currently.  Motion blur does do sub frame evaluations, which can result in calls interpolating the start/end frame caches. Or if the fluid is not cached it could cause added simulation steps for the sub frames.

 

Disabling the fluid evaluation may also fix your runup problem, although I’ve not tested it. Probably best if you test it on your setup.

 

Duncan

 

From: maya...@googlegroups.com [mailto:maya...@googlegroups.com] On Behalf Of John Cassella

Sent: Friday, May 28, 2010 12:42 PM
To: maya...@googlegroups.com

[Phinnaeus OConnor]

Working late again...

Why is it when it comes to the nParticles core in Maya, that the caching sooooo sloooow.

14% of my cpu is being used when I cache. 

Directors don't understand this especially when they creep up behind you asking why you are watching youtube and not watching their particles literarally grow.

BTW has anyone checked out Realflow 5?, now that is speedy simulation!

Phin

---

From: Duncan Brinsmead <Duncan.B...@autodesk.com>
To: "maya...@googlegroups.com" <maya...@googlegroups.com>
Sent: Thu, May 27, 2010 7:03:26 PM

[Duncan Brinsmead]

Do you have a scene where the caching is particularly slower than playback(while simulating)? If you have a scene that that seems unusually slow please submit it with a bug report. As we work on optimizing nucleus code it helps to have a variety of customer references to see typical setups.  

[Chris Mills]

Does anyone know why it is not possible to add two ramps together with a
plusMinusAverage node and use the output3D to provide the color of a
single colorEntryList for the ramp that drives the advanced twist
controls for a splineIK solver?

I've also also seen this fall apart with particles where the swatch
looks like what I'd expect, but somehow the data coming through has
changed and Maya won't pay any attention to it and decides that it is
now a single value and no longer a ramp.

Thoughts?

Thanks!

Chris

Lizard Lounge Graphics, LTD.
Wellington, NZ
http://lizardlounge.com

Int'l: +644-977-5400 / +642-174-8770
NZ local: 04-977-5400 / 021-748-770

[Chris Mills]

My solution has been to use an expression to assemble together my new
ramp from the various sources by running colorAtPoint and summing the
ramps together to get my color values for my colorEntries. It's a hack,
but it works.

Chris

Lizard Lounge Graphics, LTD.
Wellington, NZ
http://lizardlounge.com

Int'l: +644-977-5400 / +642-174-8770
NZ local: 04-977-5400 / 021-748-770

[Phinnaeus OConnor]

Hi Duncan, yes I'm using the new surface tension settings in nParticles to create flowing mercury drops turning into letters. It is working well but very slow to playback or cache and this is a brand new high spec CPU. Will submit a bug report now...

Thanks for getting back to me, 

Phin

---

From: Duncan Brinsmead <Duncan.B...@autodesk.com>
To: "maya...@googlegroups.com" <maya...@googlegroups.com>

Sent: Mon, May 31, 2010 10:42:26 AM
Subject: RE: [maya_he3d] simulation gripes

[Duncan Brinsmead]

OK, so it is likely the speed of the fluid simulation. Make sure selfAttract and selfCollide are both off or they will slow down your liquid simulation. Also the meshing can in some cases be much heavier than the simulation to compute so hide your output mesh and turn off intermediate object on the nParticles  then switch this back before rendering. (I may have hit some cases where even with it hidden the mesh was getting computed… if this is happening you could try instead making the maxTriangleResolution temporarily 0)

 

 

Duncan

 

From: maya...@googlegroups.com [mailto:maya...@googlegroups.com] On Behalf Of Phinnaeus OConnor

Sent: Tuesday, June 01, 2010 7:16 AM
To: maya...@googlegroups.com

[Phinnaeus OConnor]

Hi Duncan, yes selfAttract and selfCollide were turned off in the simulation. 

The simulation would slow down significantly when a negative force field was applied to them from a passive rigid. 

Meshing was being done in Realflow 5, which still has better controls for the look of the mesh.

Really my main gripe was that just one of the cores on the CPU was being used when simulating, is this something that AD will address in the next version?

Phin

---

From: Duncan Brinsmead <Duncan.B...@autodesk.com>
To: "maya...@googlegroups.com" <maya...@googlegroups.com>

Sent: Mon, June 7, 2010 9:33:23 PM

[Duncan Brinsmead]

The surface attraction can be slow for a detailed mesh with a lot of particles. Lowering the maxDistance can help when possible. We are continually looking at threading and optimizing as much of the solve as we can, but I can’t say whether such improvements will appear in the next release of Maya or not.

[Duncan Brinsmead]

You might also consider using particle goals to form the letters. This is more efficient than general surface attraction and can result in a more uniform distribution of the particles along the surface( although if you want the liquid to pour into the letters then the surface attraction might look more natural, because with the goals each particle is forced to a target position on the surface)

 

I did a scene with some smoke forming letters a while back and found that  goals worked much better for me than surface attraction.

[Phinnaeus O'Connor]

Ok, good to know, cheers Duncan :)

Sent from my iPhone

[Phinnaeus O'Connor]

Yes I did think of Goals but the combination of Axial curve fields and force fields was working so well. The project is finished now and the surface tension really really rocked it. Cheers :)

Sent from my iPhone

On 8 Jun 2010, at 22:44, Duncan Brinsmead <Duncan.B...@autodesk.com> wrote:

You might also consider using particle goals to form the letters. This is more efficient than general surface attraction and can result in a more uniform distribution of the particles along the surface( although if you want the liquid to pour into the letters then the surface attraction might look more natural, because with the goals each particle is forced to a target position on the surface)

 

I did a scene with some smoke forming letters a while back and found that  goals worked much better for me than surface attraction.

 

Duncan

[blossom ghuntla]

Hi,

I know the topic is old but this related to the to situation that i am facing and reading the whole topic i didnt see any conclusion or if it got resolved

So, I have been facing the similar issue fluid not rendering on renderfarm 

I am using maya 2017

When we try to render Maya Fluids in batch mode it either come blank or static.

We have tried rendering same file in different mode

Inside maya - Render Sequence - Works fine

Inside maya - Batch Render  - Does not work

From terminal - Batch Render  - Does not work

Only Render Sequence is giving proper renders other are blank

[desig...@gmail.com]

Are you talking about a mesh exported from Bifrost?

Are you talking about old maya fluids?

Are you talking about a mesh?

Are you talking about an isosurface made by Arnold?

Are you talking about an nParticles fluid sim?

Thanks,

R

--
You received this message because you are subscribed to the Google Groups "maya_he3d" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maya_he3d+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Deke Kincaid]

Also which renderer?

[desig...@gmail.com]

Doh, missed one. XD

R

[blossom ghuntla]

Hi,

Using maya arnold

fluids with nparticles

normal 3d container(fluids)

Thank You.