avoid baking box#2 physx particles

#1

Hi Guys,

I was wondering if there’s a way to avoid having to cache/bake the physx world particles in box#2.
When I render a frame that looks good in viewport, it screws up in the render, and seems to do this all the time. The problem is that I can’t bake them, because I’m using a script to change the simulation continuously.
Now I could probably script the baking of the particles as well (no idea how though), but there’s another problem that I have multiple physx world drivers in the scene.

Is there no way to render exactly what’s in the viewport, without resimulating? (my iteration steps and viewwport % are the same BTW)

thanks in advance

#2

Nope, not really or should I say, not consistently.

 Especially since you are using multiple worlds you really need to cache each source/world set individually. IE any set of events connected to PhysX World 01 would need to be cached in Disk Cache01 and so on. In fact, it is almost always better to cache any system that is system taxing.
 
 In the case of a single world just adapt the habit of hitting the bake button instead of the play button. That has worked the best for me personally.

… (my iteration steps and viewwport % are the same BTW)

hehe, that is the first rule of box2 club ;)

the second rule is bake


BTW, What is your script doing to the system that you can't bake it?
#3

Thanks for the answers.

I’m experimenting with an idea that I had: Setting up a simulation, render frame X, changing something within the simulation slightly, render frame X etc…

Kinda like moving/rotating a particle-emitter, while with the time-slider after the birth time, and seeing realtime what effect it has.

This needs stable, reliable and most of all reproducible simulations.

#4

Setting up a simulation, render frame X, changing something within the simulation slightly, render frame X etc…

The simulation baking can be done with a script. So your workflow should look like this:

  1. Set the animation range to 0-X
  2. Setting up a simulation ( with a script, I guess )
    2a. $‘PhysX World Driver name’.BakeSimulation()
    2b. $‘PhysX World Driver name’.Run_Baked_Simulation = on
  3. Render frame X.
    4a. $‘PhysX World Driver name’.BakeSimulation()
    4b. $‘PhysX World Driver name’.Run_Baked_Simulation = on
  4. Render frame X.
    etc.

Thanks,
Oleg B.

#5

thanks!

I suppose this is quite obvious, but I couldn’t find this in the help file as far as i remember.
very helpful indeed.

#6

Julius,

It’s a general paradigm of scripting in Max (regardless PFlow) - if you want to know how a specific functionality can be maxscripted, you need to open MAXScript Listener, turn On for Enable in MacroRecorder menu, and then do the “button/parameter” functionality. If the functionality is implemented properly, you will see the maxscript “reflection” in the Listener.

For example, for baking you need to click on “Bake PhysX Simulation” button, and you can see how this functionality can be done in maxscript.

Thanks,
Oleg B.

#7

Thanks, Oleg.

Even though I knew this of course, it seems I have overlooked it this time. Maybe because I didn’t realize the physx world driver is an object like any other in Max.
It makes perfect sense now. Thanks.

#8

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.