I searched the forums but can’t find a Feature requrest for the ability to prewarm particle effects, which seems odd. Anyway - here is a feature request for that. I really think it is a key feature that is lacking.
Ah - “prewarming” vs “pre-warming”…
Anyway - it hasn’t been awarded a ticket yet in that thread, so consider it bumped
Added a ticket: DEF-2373
In my specific case, this was not necessary: Instead I have two emitters within the same , and the first one spawns a lot of particles very quickly, but then stops (it’s set to “once” not “loop”). The second one is set to loop and spawns less quickly. You can also change the size of each emitter, etc. There are many things that you can do to work around this (…however, a built-in prewarmer would also be useful)
Another related feature that would more than welcome is the ability to save a state for a given frame and start simulation from a saved state.
So - in my current project this is something of a dealbreaker. Is this something that can be expected to be added soon or should I try a workaround?
Not sure. I’ve been fiddling a tiny bit with the pfx system (DEF-2688) but I’m not yet sure of the complexity of pre-warming. How would it work? How would I pre-warm the system? A property on the emitter? An argument to particlefx.play()?
Usually that’s offered as a method on the simulation system.
Here that could translate as:
particle.stop() -- Reset sim particle.preroll(2) -- Fast forward for two seconds (no display) particle.play() -- Run and display simulation
Ok, and you want to be able to control the pre-roll time at run-time and not as an option on the particle system?
Personally, I see pre-roll as a poor’s man version of being able to author and save the state of a particle system (position, velocity and all attached parameters at a given time) so you can restore/start your simulation from a given state.
For instance, start showing snow/rain particles when it has already covered the screen, fire and smoke of a wood torch when it’s well-formed and such.
Generally speaking FX requires good control of the time component to only show the moment that is interesting/make sense. The current system is great for ‘reaction’ FX: when the actual generation of particles happens in-game as the consequence of an event.
So to answer your question, I’d say at runtime as currently you can’t access particlefx properties dynamically and therefore it would be a static value.
Unity just has a check box in the emitter properties in the editor. It runs through a full cycle—which I guess is the “duration” of the emitter, or maybe the max life of a particle? I think it only makes sense to prewarm looping emitters.
Do you really need perfect precision in how long an effect prewarms for? To be set dynamically at runtime? The effect will not remain at any “perfect moment” during the running game after all.
Personally I would be happy with a checkbox that will run a full cycle (like Unity), but having more fine grained control through scripting might be a second step.
In my use case I have a snow effect where I want it to be snowing immediately and not start drizzling (or whatever the snow equivalent of that word is…) first.
Johan in your case (and I feel there are many other cases that are similar), it is very easy to just put two emitters inside the same particle effect, one which instantly creates a very large number of particles over the whole screen, and another which gradually creates particles from the top of the screen which then move down. That’s what I did and it works fine
That is a good idea. My current hack is setting the time step to the frame rate and skipping a frame before showing the collection, which works but isn’t very elegant
Pre-warming was released in Defold 1.2.120
For other people searching for the answer HOW to implement a prewarm/offset on a particle effect:
From the documentation:
Start Offset: The number of seconds into the particle simulation the emitter should start, or in other words how long the emitter should pre-warm the effect for.