I’ve been posting some screenshots in the WIP and I am ready to start gathering feedback on the particle system i’ve been working on for jME. This code was originally based on early code from t0neg0d which I then heavily modified to allow for animation over time in Spoxel. I’ve spent a lot of time cleaning it up and incorporating some new concepts i picked up from other particle editors / systems. I’m working on SDK integration as well but I wanted to get some feedback on the particle system itself before I finished that.
I’m still working on some of the documentation, but I think the API has mostly stabilized at this point.
The particle system is an extension of the node class and holds 1 or more geometries as children depending on what modules a particle system contains. Modules each work upon the particle system in some way IE control speed / color / particle trails. At the moment I have the following modules:
Color Module - Change the color of the particle over time
Emission Module - This allows you to make additional “extra” particle emissions during the life of the emitter
Gravity Module - Applies gravity to the particle over time
Impulse Module - WIP… kind of a duplicate of the velocity module… not sure if it will stay
Preferred Destination - Attempts to force a particle to travel to a given position over time
Preferred Direction - Tries to force a particle to travel a given direction
Random Module - Adds noise to the particles position
Rotation Lifetime - Controls a particles rotation over it’s lifetime
Rotation Velocity - Controls a particles rotation based on velocity
Size Module - Handles particle size over time
Sprite Module - Controls sprite animation for particles
Trail Module - Adds trails for each of the particles… There are still a few things I want to polish here
Velocity Module - Controls the velocity over time of a particle (includes linear and rotational)
One of the big design changes for this particle system is that most “attributes” can be animated. This breaks down into 3 different object types. They are ValueType (Float), VectorValueType(Vector3f), Gradient (Color). Each of those types can be set / animated.
Value / Vector
Constant / Float Value
Random Between two values
Curve - Animated curve over time
Random between two curves - Each particle has a random value assigned to it between 0-1 which is then used to interpolate between both curves
Gradient / Color Type
Constant color
Random color
Random between two colors
Gradient over time
Random between two gradients - Each particle has a random value assigned to it between 0-1 which is then used to interpolate between both gradients
Currently there are a handful of emitter shapes which includes circle, cone, line, sphere and mesh. Each of those shapes has a handful of attributes you can edit to control how particles are emitted using that shape that will be pretty familiar to anyone that has used unity before.
So every Module would be a Geometry or are there just a few Modules which would lead to multiple Geometries? Because usually people expect a Particle System to be one Geometry.
However I can see that for more advanced particles this assumption fails (multiple particles with different Materials).
Regarding the Animation: I think here it would be wise to somehow unify this in the whole engine, like currently we don’t have a way to set the camera speed in a cutscene using a curve. So there could be your code. On the other hand both the new animation system and lemur are using tweens, which are also some kind of curves which can be chained together.
A unification would be awesome (like I could use the same code I use for the animation for the particles), however I guess tweens are more than curves, like a velocity doesn’t need a “pause tween” etc.
Anyway thanks for sharing back your hard work to us Particles definitely needed an improvement!
The design behind the new JME Tween based animation system:
AnimClip : The replacement for Animation. It’s mostly the same: a stateless class holding raw animation data. It can be a Joint animation or a spatial animation or both. It’s holding TransformTracks : basically animation data for something that has a transform.
AnimComposer : Basically what replaces the AnimControl. As its predecessor it allows you to change the playing animation, but in a different way. It allows you to create actions from the AnimClip, and play these actions on demand.
Action : An action is a composition of Tweens. It can be a single tween, a sequence of tweens, or tweens called in parallel way or a mix of all this. An Action is also a Tween, so it can be composed as part of another action and so on. An action can be provided with a Mask that will define a subset of targets on which it applies (a subset of Joints in an Armature or a subset of spatials for spatial animations)
Notables built in actions : (this may change a bit) BaseAction : An action that wraps a Tween ClipAction : an Action that plays an AnimClip BlendAction : an Action that allows you to blend AnimClip together (think half walk / run animation varying depending on the forward speed)
That’s basically it. Note that Tweens can be basically anything, so the base action already provides virtually endless possibilities:
Stock Tweens that I plan to provide:
SoundTween : play a sound
EffectTween : fire a particle emitter
MaterialTween: animate material’s properties
ChangeActionTween: tells the AnimComposer to change the current Action
Stock Tweens available in Lemur (will probably be ported to jme’s core):
Sequence tween: a tween that plays tweens in sequence.
Parallel tween: a tween that plays tweens in parallel.
Delay tween : a tween that just waits…
Stretch tween: a tween that wraps another tween and change its duration.
Camera tween: moves the camera…
Then… your tweens. Tween are very easy to implement and you can definitely make your own and compose them in actions.
Anyway, you got it, with this composition system you can do pretty much anything.
All of this will come with factory like methods to easily construct them.
more on Tweens
Edit:
I guess a module/influencer could be implemented with a tween thus we can chain them together to make a complex tween. It can be also chained with other kinds of tweens ex audio/camera tweens.
In that screenshot I just have a light added to the node. I know unity has some sort of light linking system but I haven’t looked into it enough yet to decide if that should be a built in module. You can change any of the modules at runtime and it should work. I’m about 90% done on integrating it into the SDK and you can make changes and see the results instantly.
So I have a couple of reasons I changed it to module instead of influencer. My goal was to integrate this directly into jME and the existing particle system uses the term influencer so it was a way to help separate the name. Some modules such as the trails module and the emissions module don’t influence a particle as much as the emitter as a whole. Also, I wanted to standardize as much as I could and unity uses the term modules. My hope is that we can all breath new life into jME and I want to make it easy for people coming from unity to understand the particle system.
A basic physics module / influencer is one of the features on my todo list. There is a small list of things I still am working on adding, but I need to think through how it would work with the SDK. For example, i’m not sure how to expose linking meshes to use as particles in the sdk.
Not every module adds geometry. t0neg0d’s original particle system extended geometry but that breaks down when you use something like particle trails. The trails module adds it’s own particle geometry underneath the emitter node which has it’s own material. If someone has a use case for it, they could theoretically add their own module that does the same.
I haven’t looked at the new animation system too much yet, but I would be open to suggestions on how to best handle that. I’ve actually used the lemur tween system in Spoxel for a few effects that required animating a node. I already have a node editor working inside the SDK so it wouldn’t take much to allow you to animate objects. I’ll take some time to look at the new animation system, but if you guys have any suggestions I would love to hear them.
I have in no way tested this jar, but I think this should work if you want to try it and look around. I plan on writing up a detailed tutorial once I know i’m not going to be renaming anything or making any major structure changes.
Hopefully, someone with more knowledge of this will comment. My understanding is that should look like this:
public class ParticleTweens {
public static Tween changeColor(args...) {
...
}
public static Tween emmit(args...) {
...
}
public static Tween applyGravity(args...) {
...
}
public static Tween applyImpulse(args...) {
...
}
public static Tween applyPreferredDestination(args...) {
...
}
//.... and so on for each module
}
So one can chain as much of these tweens they want with sequence or parallel tweens and play it with AnimComposer.
see how SpatialTweens, CameraTweens look like:
Edit:
Anyway, It might require some code refactoring. There is no force to do it with Tweens. So please feel free to do it as you think is better
“module” seems an odd choice as it’s super generic and highly overloaded in software development. When I hear the word “module”, I immediately think of a jar with a bunch of classes in it or a whole pile of resources.
I suppose I’m really not tied to the term so i’m fine changing it back.
So I took a look at the new animation package. I’m not sure it makes sense to use tweens for particle influencers. Generally the tween system acts upon a single object but particle influencers act upon a large number of objects and don’t always just work on the particle data (IE particle trails compute their own geometry and interface with the emitter). The particle tweens also wouldn’t be applicable outside of the particle system so i’m not sure it would be useful.
The one area that could potentially have some overlap looks like the interpolation system. There is an existing spline class within jME that could probably be refactored to be used instead of the curve class I used. Otherwise i’m not sure what I would do to integrate with the animation system.
This is just a basic particle physics integration that takes a spatial and does collision against it. I don’t plan in the near term to do something more advanced like integrate with bullet or build a faster collision setup.
I didn’t see a difference in performance using the box for collision but it would be much worse for a larger collision mesh without some sort of collision structure to reduce the number of collision tests. From what i’ve read, unity uses some sort of voxel like collision system for their particles when used with static meshes.
So i’ve made some good progress. I’ve been working on adding an example file with a bunch of particle system examples. It’s been really useful finding several bugs inside the particle system that are now fixed.
Based on feedback, I renamed the “modules” to “influencers”. I’m still thinking about how this could integrate with the new animation system. So far, the paths i’ve gone down have been somewhat dead ends. I have a few ideas still floating around my head that i’m mulling over.
It will be nice to have a test for emitter shapes also.
And one more suggestion regarding naming. IMHO it will make more sense for EmitterShapes (EmitterCircle, EmitterCone, EmitterLine, EmitterMesh, EmitterSphere) to be named as CircleEmitter, ConeEmitter, LineEmitter, MeshEmitter, SphereEmitter. What do you think?
Maybe we just need a simple EffectTween which gets a path to a particle emitter file and fire the particle emitter and updates the emitter by feeding the time into it?
I guess this is what @nehon was meaning by the EffectTween:
Stock Tweens that I plan to provide:
SoundTween : play a sound
EffectTween : fire a particle emitter
MaterialTween: animate material’s properties
ChangeActionTween: tells the AnimComposer to change the current Action
Yeah that way you can add some particles to your animations (could be opening, blasting a door or just having some sparkles at the tip of your robe when walking)
Edit: And even when not, I don’t know how one could unify the APIs, now that I see that tweens != interpolators/curves though, my initial idea doesn’t make sense anymore, so maybe one cannot combine them that tightly.
I’m really not tied to the term so i’m fine changing it back.
now i really want to use it! i hope FPS is fine too.