Hello all !

I am trying to make an asset to simulate flip fluid in Maya
It doesn't work when the sim start at a frame greater than 1 . The maya console return this message :

QObject::startTimer: Timers cannot be started from another thread
QObject::killTimer: Timers cannot be stopped from another thread

It's seems the solver compute something but is unable to output it.
Is it possible to start sim at another frame than the first one within HouEngine?

Thanks for or time,


Vincent

oh …
it's seems i Have to set the nulceus correctly to control the start frame.
Is it right ?

Let me give that a try. In the meantime, is the flip fluid interacting with animated maya collision geometry? If not, you could try retiming the asset (and nucleus) node instead

If you sync the asset at a frame before the actual start frame, the output nParticle system will not be created because we didn't find any particles at sync time.

If you had a particle emitter in the asset, you'd still see the intermediate particles from the emitter, because they are static and exist before the start frame. So this would look extremely confusing when you did playback, because you'd only see the static particles, and not the sim particles that you really wanted.

In order to be able to output the sim to Maya, you need to go to the actual start frame and then sync the asset again.
You will see that an nParticle system has been now been created, and you will see the particles when you play back.

The nucleus startFrame does matter because it's connected to the nParticle startFrame. Although since we're connecting on the cache input, the nucleus start frame just needs to be before the houdini start frame for it to work once it is synce'd properly. So if your houdini start frame is after the default nucleus startFrame (1) it will just work, but it the houdini start frame was before the default nucleus startFrame, you would need to set the nucleus startFrame in order to see the beginning if the sim.

I'm not if there is a really good way to automate startFrame setting/connections. We have no way of knowing what the startFrame is unless its exported and we know what it's exported as. I guess we could adopt a convention of using a startFrame parm if it existed, but then there are still frame vs time vs units questions…

Not creating nParticles for only temporarily empty particle objects seems like a bug, but creating nParticle systems that never do anything is also cluttering up the scene. Any thoughs?

hi Juliap,

Sorry for the late reply.

Finally , following your explanation, we manage to simulate at a given frame, syncing the asset at the startframe of the sim and adding an expression to the Nucleus startframe accordingly.

The last tests we made showed us a new issue.
We can't use the substeps of the dopnet properly. In Maya , it changes the sim but we notice the steps are more visible when the step is high (!).

What's your opinion about it ?

I will give it a try and let you know - in the meantime a couple of questions about how the sim is getting invoked in Maya:

Is this in regular playback? (or are you doing a cache create or runup or something else)
What is the Playback speed set to in the time slider prefs? Also the frame rate and the playback by.
Is runupToCurrentTime on in your dynamics prefs? (not that it necessarily should be, I just wonder if it is)
Are there any other Maya dynamics objects in the scene (besides the ones attached to your asset)
Evaluation Manager mode or DG mode? (and if it's in EM mode, does it do anything different in DG mode?)

Do you have any animated geometry from Maya connecting in to the asset?

…
So I did give it a try - in my simple test (case emit some particles have them collide with another object, where I exported the substeps), it looked pretty much the same, frame by frame, for different numbers of substeps, whether I ran the sim in houdini or Maya. I guess I need a more complex test case.

I also tried setting the playbackBy in Maya (e.g. to .25 frame for 4 substeps) - this did not work so well, so it would appear to not be a useful workaround.

to answer your question :

regular playback
play every frame
playback by 1
runupToCurrentTime off
no other dynamics
Evaluation mode Parallel

Haven't been able to repro with the my simple test cases - the only really bad behavior that I saw was trying to use Maya's time stepping to force substeps instead of using the real substeps.
The way that I compared my sim with substeps was to compare a couple of frames at random between houdini and maya to see if the maya frame was significantly different and/or had particle distribution artifacts.
I also playblasted the sim in maya with different numbers of substeps, and then looked at the movie files playing back. (i.e. I was just concerned with the quality of the sim in each case, as opposed to how Maya's playback of it looked).

What's the mimimum complexity of sim that exhibits the substep problem - how many particles, how many pieces of collision geom, how many of them animated?

If you're getting a correct sim, but it's playing back poorly once it's cached if you have lots of substeps it might be memory issue too - also are you running with houdiniEngine in process or in a separate HARS process?