FX Visual Designer: The Drama Thread - You don't want to miss this

As per the wiki… this is the (soon to be) official release post.

Well… I’m just about finished with it… and it’s really just about the last thing you’ll need to design FX for your game :wink:

This tool allows you to build out multi-particle emitter FX visually using the emitter system I’ve been tinkering with for what seems like forever now.

Before I go into a list of features, let me tell you about the best part… you visually design your FX… and then push a button and it spits out every line of code you need!

Now… onward with the feature list:

The Emitter System:

Emitter shapes–

  • Point
  • JME Primitives
  • Loaded asset (including the ability to animate the emitter shape… meaning you can simply use your game assets as an emitter shape and only have to manage the animations for your in-game assets. The emitter will do the rest for you)
  • The particle mesh from another emitter

Emission Direction Choices–

  • Normal
  • Normal Negate
  • Random
  • Random Tangent
  • Random Normal Aligned
  • Random Normal Negate

Emission Attributes–

  • Velocity-based
  • Static particles
  • Random face emission
  • Sequential face emission
  • Sequential skip pattern

Particle Shapes–

  • Quad (default)
  • Star-shaped Impostor
  • JME Primitives
  • Loaded assets as a template (These can also use AnimChannel to animate the particles)

Billboarding Modes–

  • Velocity
  • Velocity Z Up
  • Velocity Z Up Y Left
  • Normal
  • Normal Y Up
  • Camera
  • UNIT_X, Y & Z

Particle Attributes–

  • World or Local space
  • Particle Stretching

Stock Influencers–

  • Gravity
  • Radial Velocity
  • Color
  • Alpha
  • Size
  • Rotation
  • Sprite
  • Destination
  • Impulse
  • Physics

– All influencers accept as many steps as you would like to add. i.e. Size can chained with
– * v3(0,0,0) with an Interpolation of exp5Out to
– * v3(1,0.5,1) with an Interpolation of fade to
– * v3(0.5,1,1) with an Interpolation of bounceIn
– * etc, etc, making your options limitless (my PR guy made me add this line)
– These can be divided over the life of the particle or a fixed duration can be set and they will auto-cycle.
– These can use randomization within defined tolerance

Now, for the FX Builder…

Can’t begin to describe how cool this has been. Talk about putting your code through it’s paces… not to mention, I am constantly finding things I wasn’t even aware the emitter was capable of. All you need to do is drop your model/texture assets for particle effects in the project and use the UI for the rest. When you done setting up your FX scene… just push a button and the code is outputted for you. Cut / paste / and your done.

There are dependencies that you’ll just have to live with, if you want to use the FX Builder (and, honestly… you’d really need to consider getting your head examined if you pass it up):

  • The emitter system… duh
  • tonegodGUI - Whether or not you ever use it, you’ll need it for this. I believe this will require a download from the repo (download section once all is published) as community plugins still seem to not update properly through the SDK =(

Here is a short vid of the designer.

[video]http://youtu.be/LDxpBcMrDJ4[/video]

I’m looking at another week or so, before relasing the emitter + FX Builder.

At some point I’ll likely set up the FX Builder to allow timer-based and triggered emission FX. At this time it runs a constant update. Work-arounds for this at the moment is to set:

Emissions per second to 1
Particles per emission to the max # of particles, which will cycle the triggered effect every second.
Or, to double the max # to cycle it every 2 seconds, etc, etc, amen.

In a real-life scenario, you would set:

Emissions per second to 0
Then call emitAllParticles() or emitNumParticles(#)

Or

Set emissions per second to some rate as a response to some event
Use a timer to set it to 0 after the duration of the effect

IMPORTANT: As for the emitter as a plugin, I’ll be publishing it to a repo… the jars will be publicly available for download. A detailed description of how to implement an influencer, in case you are not able to do something you would like will be made available. It will be covered by the same licence as the rest of JME… The source for the FX Builder will be available… the actual source for the emitter system, however, may not be included. I’m fairly sure anyone who has been around for a while will understand my consideration in doing this. There is no real need for it, as it provides an interface for extending it’s functionality to anything you can imagine for it. If someone can think of a good argument as to why it should included, I’ll certainly reconsider. But, for now… probably not.

Well, enough for now… would love to hear some feedback on how useful you would find this… & I’ll post updates as I get closer. Feel free to post questions you may have, etc, etc.

P.S. I’m fairly sure this dead horse is good for another swing or two… and I just polished up my deceased-bovine-whacking-stick

19 Likes

Eye-Candy Section

This is just to show examples of what you can accomplish with the different Influencers & emitter options

Static Particle:

[video]http://youtu.be/AIoepB0piuU[/video]
[video]http://youtu.be/fL8sbwommL8[/video]

Gravity + Particle Stretching:

[video]http://youtu.be/OSKytdfHsK0[/video]

Radial Velocity:

[video]http://youtu.be/sX0SsSZ5GP4[/video]

Color & Alpha:

[video]http://youtu.be/QxaiRNmwDag[/video]

Physics & Particle Mesh as Emitter Shape:

[video]http://youtu.be/UhOtJhvGTDs[/video]

This is just a small fraction of what you can do.

1 Like

I understand that at the moment, it will generate the setup java code, but there will be no actual save/load format? So it won’t be possible to visually tweak already created emitter, you will have to set it from the scratch?

Is the resulting emitter jme3-graph serializable with all the influencers etc intact?

@abies said: I understand that at the moment, it will generate the setup java code, but there will be no actual save/load format? So it won't be possible to visually tweak already created emitter, you will have to set it from the scratch?

Is the resulting emitter jme3-graph serializable with all the influencers etc intact?

At initial release, it is doubtful I’ll have the time to implement this… though, will likely add some form of XML-based save/load component soon after.

EDIT: Since the builder is going to be a downloadable JME project, it should be fairly easy to add this if needed before I am able to do so.

And yes… JME’s standard read/write is supported.

Emitters are really impressive !

A bit sad cause i couldn’t put my hands in the code x) …but i know why you do that.

The FX builder is a really good feature and it seems super easy to use <3. Good job ! …And yes i’m a bit surprised too with the output format…it could be awesome to save them directly in a .j3o file as other assets (and actual jme emitters).

I love it anyway, and i can’t wait to play with it (i remember the amazing effects you’ve shown here)

EDIT : are emitters clonable ? I use it in my game.

@haze said: Emitters are really impressive !

A bit sad cause i couldn’t put my hands in the code x) …but i know why you do that.

The FX builder is a really good feature and it seems super easy to use <3. Good job ! …And yes i’m a bit surprised too with the output format…it could be awesome to save them directly in a .j3o file as other assets (and actual jme emitters).

I love it anyway, and i can’t wait to play with it (i remember the amazing effects you’ve shown here)

EDIT : are emitters clonable ? I use it in my game.

They are clone-able, as are the individual influencers.

Which brings up another thought… you can add more than one of any particular type of influencer, however the getInfluencer(Class.class) method returns the first in the list. Since the emitter allows you to add influencers either through the constructor or via addInfluencer(someInfluencer), you can pre-configure your influencers and bypass the retrieval method if you ever have a need for… say… more than one GravityInfluencer. It would look like:

[java]
// Gravity influencer 1 - world aligned gravity
GravityInfluencer gi1 = new GravityInfluencer();
gi1.setGravityAlignment(GravityAlignment.World);
gi1.setGravity(0,-4,0);

// Gravity influencer 2 - Emission point pull
GravityInfluencer gi2 = new GravityInfluencer();
gi2.setGravityAlignment(GravityAlignment.Emission_Point);
gi2.setMagnitude(4);

// The create the emiiter and add the influencers as cloned or not
Emitter e = new Emitter(“emitterName”, assetManager, 100,
gi1.clone(),
gi2.clone()
// etc, etc
);
[/java]

Since gravity can be aligned to world, emission point, emitter center or reverse velocity… a combination of multiples would allow for some interesting effects… however, the FX Builder does not support this atm.

@haze said: A bit sad cause i couldn't put my hands in the code x) ...but i know why you do that.

I’d be more likely to do this on a case-to-case basis. I’m not interested in “keeping it to myself”. I’m more interested in keep it away from people who are unscrupulous and feel it is totally appropriate to claim someone else’s work as their own.

And just to prove the point, without the source code available, I’m sure you will start to see a HUGE gap in possible functionality between this emitter system… and… the… “other” one.

Ok. Cool.

It’s a bit curious to allow multiple influencers of the same type…I would map influencers by class…i understand that you can combine differents settings to do custom things but if two settings of an unique influencer do really differents kind of results…why don’t make a new type of influencer?

@haze said: Ok. Cool.

It’s a bit curious to allow multiple influencers of the same type…I would map influencers by class…i understand that you can combine differents settings to do custom things but if two settings of an unique influencer do really differents kind of results…why don’t make a new type of influencer?

Mostly so there weren’t 6000 influencers to choose from.

World aligned gravity and reverse velocity are both gravitational pulls… it is also very unlikely that you would ever use both, but just in-case there is ever a need,… I left it open for multiples of the same type.

@t0neg0d said: I'd be more likely to do this on a case-to-case basis. I'm not interested in "keeping it to myself". I'm more interested in keep it away from people who are unscrupulous and feel it is totally appropriate to claim someone else's work as their own.

And just to prove the point, without the source code available, I’m sure you will start to see a HUGE gap in possible functionality between this emitter system… and… the… “other” one.

I would love that <3 (for myself promised, i’m just a curious by nature ^^…i can’t use a lib which i don’t understand the mechanisms…much of the despair of my former teacher =D )…yeah i remember this shitty part…i don’t want to dig up this debate once again…it has already spilled enough ink i think.
And yes, it’s obvious that your particle emitters are a lot more advanced !

@abies & @haze

A bit more info on the choice to output the code for emitters: (and thoughts, ideas for this would be greatly appreciated)

The thought behind this was:

  1. Most people will have a very unique way of pooling & reusing emitters for effects. Likely, they will setup influencers that are clone-aable and have a pool of emitters they re-configure for each effect type.
  2. There is also the problem of what to do with emitter shapes that references your in-game assets… if you modify the asset (by setting a new animation, etc) the emitter reacts to the change in the mesh.
  3. The physics influencer checks against a geometry list that is defined by the user. This list will need to be maintained by the user and will be completely different soley based on where the emitter is and what needs to reflect particles.

The designer spits out everything you need to create a a group of emitters that produce an effect. It is highly doubtful that you would not take the code, break out the influencers and emitter settings and use them with your FX pooling system.

The code output is more to minimize (or hopeful negate) the time it takes to learn to use the particle system.

@t0neg0d said: Mostly so there weren't 6000 influencers to choose from.

World aligned gravity and reverse velocity are both gravitational pulls… it is also very unlikely that you would ever use both, but just in-case there is ever a need,… I left it open for multiples of the same type.

Hum, i know but it has the merit to be clear and simple if each influencer do only one thing…the hard part is to find a simple expressive name to facilitate the search ^^.
As it is it can have unexpected effect if you combine some settings with inverse props ^^.

@haze said: Hum, i know but it has the merit to be clear and simple if each influencer do only one thing...the hard part is to find a simple expressive name to facilitate the search ^^. As it is it can have unexpected effect if you combine some settings with inverse props ^^.

I think once you have played with the builder and try out the gravity and radial velocity influencers (as examples), you’ll see why the influencers are combined the way they are.

If I was to create a new influencer for all of the possible alignment options for radial velocity, you’de need to buy another harddrive just to store the influencer classes :wink:

For instance… radial pull can be aligned to:

  • Emission Point or Emitter Center

However! There is a secondary option of setting that alignment to use:

  • Absolute position
  • Relative X, Y or Z (i.e. Y = the particle continues to move up, away from the emitter, however the pull still revolves around x/z coords of the emission point or emitter center.

These have DRASTICALLY different results in how the particle orbitis… say… the difference between an orbiting planet and the cyclone.

And this doesn’t even cover the idea of altering the up-alignment relative to:

Normal,X, Y, Z, etc

The combination (i.e. potential number of influencers) is now growing exponentially.

Don’t worry about save format right now - prepare what you have and let us play with that. There might be some suggestions which would change the needed format anyway, so maybe it is better to let it stabilize before spending too much effort on that.

1 Like

@t0neg0d if i may to donate you a bit for your hard work?

2 Likes
@mifth said: @t0neg0d if i may to donate you a bit for your hard work?

That’s a very sweet offer, but really not necessary. I just have fun working on projects.

Can you post source of this? I like to improve a bit. It would be better if editor was in SDK, how I run editor in other window and its not save in j3o?

@t0neg0d said: I'd be more likely to do this on a case-to-case basis. I'm not interested in "keeping it to myself". I'm more interested in keep it away from people who are unscrupulous and feel it is totally appropriate to claim someone else's work as their own.

And just to prove the point, without the source code available, I’m sure you will start to see a HUGE gap in possible functionality between this emitter system… and… the… “other” one.

How did I know this would be visited by the down-vote fairy?

Instead of down-voting… speak up! If you feel I have misstated what happened in this ordeal.

@t0neg0d said: How did I know this would be visited by the down-vote fairy?

Instead of down-voting… speak up! If you feel I have misstated what happened in this ordeal.

You don’t listen to me anyway :stuck_out_tongue:

@rabs said: Can you post source of this? I like to improve a bit. It would be better if editor was in SDK, how I run editor in other window and its not save in j3o?

Not sure I understand what your asking for…

If you need the output saved as a j3o, simply cut & paste the code into a project, add the controls to a node and save the node… Savable is supported by the emitter.

Otherwise, everything needed to write an SDK editor is available through the API. The sources for FX Builder will be available as well and should have everything you need to quickly port it over, but I think you’ll find the builder easier to use.