New particle fx assets from Kenney and a community challenge


Kenney will be releasing a particle fx pack tomorrow. There seems to be some really nice looking stuff in there.

The pack will contain ready to use particle fx for Unity. I’d like to challenge the Defold community to try and replicate them using Defold, preferably in a way that could be easily shared, and who knows, maybe we can get Kenney himself to include them in the pack?


I’m working on some effects using these I’ll be publishing in a few days.


Think I found a bug while trying to make a certain effect? If .particlefx files are parented to a GO they inherit initial rotation set in the editor of the chain of parents they are associated with. But once in engine they no longer get extra rotation applied, this is evident if a sprite is also added and rotation is done around z. Or did I do something wrong?

Are euler.z runtime rotations not applied to particlefx components?

go.animate(".", "euler.z", go.PLAYBACK_LOOP_FORWARD, 360, go.EASING_LINEAR, 10)


Ah, the problem is that individual particles inherit the current rotation but do not get the rotation applied to them over their lifetimes. So some effects are impossible without using raw GOs.

Another issue is that modifiers appear to operate in non-rotated space only so no matter how a GO is rotated the modifier of a .particlefx will always work as if there was no parent rotation and mess up effects.


Effects so far.


There’s a rendering technique called “blend-add” which would be useful to get working in Defold to keep the screen from getting blown out from too many simple add effects.

Once Defold gets better multi texture support, some of the other techniques mentioned in the video will be possible too.


Wow! Looks great! @Johan_Beck-Noren your thoughts on the rotation issue mentioned above?


What emission space does the emitter have?

The default value is world space meaning that when a particle spawns it will get its transform from the parent GO but will live out the rest of its life in world space.

Setting emitter space will transform spawned particles according to the emitter transform (which in turn is dictated by the owning parent GO transform).

Emitting in world space:

Emitting in emitter space:


I was missing setting the emitter to emitter space. That also fixes the modifier issue too.

Only problem now is that the modifier’s value now seems to be more powerful in the engine than in the editor. I’ll do some tests to show.

Here’s the above in editor. I’ll still make some more sample to test.


The editor uses the same code as the runtime for particle simulation (through a lib) so there shouldn’t be any difference there. One thing that can differ is of course the setup of the collection and the game object that owns the particlefx in runtime.

Does the owning gameobject for example rotate or have a uniform scale applied?


The scale is uniform. But the original particlefx is much smaller, it’s upscaled by 30 while attached to the GO. Here is the project so you can see for yourself


Hmm yes I even get the same behaviour when playing the particlefx from inside the collection in the editor (select the particlefx in the outline and hit space). It seems to be related to the scale on the parent GO. Setting the scale to (1, 1, 1) instead of (30, 30, 30) and zooming in gives the same visual result as the playback in the particlefx editor.

I think the scale should only affect the rendering and not in any way mess with the simulation. Might be we have a bug!

EDIT it looks like the GO scale gets applied to modifier magnitudes, the vortex in this case. Added ticket DEF-3355.


Bug notwithstanding, this is excellent stuff, @Pkeod! Well done! :smile: :smile:


Would a “Life Modifier” property be possible? So make a curve to define how much any associated modifiers modify particles over the particle’s lifetime.


Another issue is that modifiers are always a much larger scale visually in the editor compared to what they modify.