Hey folks,
In the jmetest.effects package there is a new test called TestRenParticleGUI. Basically it allows you to interactively change the various parameters that make up a particle system. In addition, it has a panel that gives you the code to recreate whatever cool particle system you have put together.
I apologize that the color choosers and the file browser sometimes take a bit to come up (the interface is done in Swing which sometimes gets a bit starved by the rendering threads.)
Check it out here:
http://www.mojomonkeycoding.com/webstart/jmedemo/effects.TestRenParticleGUI
Enjoy!
PS: Try the prebuilt examples in the Examples tab.
edit: link is now:
http://www.mojomonkeycoding.com/webstart/jmedemo/effects.RenParticleEditor
Very cool, and very well done. It’s tons of fun to mess with, not to mention being really useful! The code window feature is a great idea. Excellent job.
One small request: make closing the GUI window terminate the program, or perhaps have a jME GUI button to retrieve it if you’ve accidentally closed it.
Absolutely fantastic. In fact, I think we should make this more than a simple demo/test. I’m leaning towards making it a full fledged tool/app. It’s got true usefulness. Maybe move out of tests into it’s own little app area? Not sure. Very nice!
This is so cool! 
I like it a lot! It will definitely be useful.
Gregg
I thought I just wasn’t fast enough to click on that configuration window, then I realized you’re not supposed to run it full screen. ://
Very cool, and useful, too.
Thanks for the good words and feedback! Added some changes to force windowed mode, added a title to the control window and made the default close operation for that window EXIT_ON_CLOSE. I’ll also be adding some new particle features later today or tomorrow. 
Very cool… Added it in as a preset under "Jet" Thanks!
Whenever the particle system editor exits, however, I get this dialog:
javaw.exe - Application Error
The instruction at "0x6910f2e9" referenced memory at "0x0000004c". The memory could not be "read".
Click OK to terminate the program
0x0000004c is a suspiciously low value - it's almost as if something's trying to treat an int as a pointer.
Are you running jre 1.5? Also, does this happen when you close the render window instead?
Mojo was having the same problems on j1.5, so I modified how that window closed and it seems to fix the problem. Let me know if you still experience it.
No, I’m running JRE 1.4.2-b28 on Windows 2000. It seems to happen whichever window I close first, although I’m not sure if I’m getting the latest version of the application when I click on the link.
Sorry, that change was just to the code in CVS. I’ll be updating webstart (where the link points) later today with the fix as well as some new features and will post something here when I do.
Ok, some big changes to the particle system… It is now a Controller, thus following the model we use everywhere else. The good news is that this means it can be controlled in the same manner as our other controllers. The bad news is that switching to that method slowed things down a bit. I think it’s still pretty speedy though.
Also, it has new properties such as initial particle velocity, flow control and firing control. Play around with it a bit.
Ugh, some recent changes to controller have fouled up the particle demo… will fix shortly, got to head out though…
Ok, my bad. Fixed and updated.
Unfortunately, no I could not quite regain the original speed (still getting times of 1000FPS where before it was 1300 FPS.) If I maintain it as a controller, but use my internal clock time instead of the passed in time, I think I can straddle the fence between the two methods, allowing use of setSpeed and the start/end times, but still getting the faster speed. I’ll see if that is true before checking in the new over the old.
Well, good news, I realized why my “pre-controller” version was 300 FPS faster and have applied the same principles to the pure Controller based version. Back in FPS heaven.
I’ll now go ahead with the update over the old PS.
Not all settings are correctly updated when you switch to predefined examples. Specifically, once you’ve viewed ‘Explosion’, the setting “Respawn ‘dead’ particles”, isn’t restored by switching to ‘Fountain’, for example.
Does the performance gain come from the way that particle position is calculated? I noticed the change while playing with the ‘gravity’ setting. I can appreciate that this could be a big performance gain, because you’re not not having to accelerate each particle individually - you can just apply a formula to work out its current position. But it does make the system a lot less flexible.
You could achieve an awesome smoke effect before, for example, by gradually panning the gravity back and forth, which makes a single column of smoke behave as if it’s in a light, varying breeze. (Now, the column just bends back and forth crazily.)
Also, it would seem the new particle position calculation method makes accelerating particle emitters impossible - such as a maneuvering spaceship that’s emitting sparks. I think you could still make it work, by having the spaceship emit a stream of particle systems, but that seems to defeat the point.
Actually, sorry, that’s unintended. 
The newest particle update switched to using a timebased formula because I was trying to more correctly model physics using a new position calculation that could take into account intial velocity, individual particle acceleration and gravity… Unfortunately, it also assumes the same forces acted on the particle over time.
I’ll rework it. Stay tuned.
PS: This formula does not make it faster, if anything, it made it slower, but more accurate… (um, or so I thought)
Ok, the bug regarding the respawn check box is squashed.
Also, I have reverted to the location equation that applies force incrementally. Updated in cvs. Works ok that way. This kind of thing happens sometimes when you try to make something that works work better. ://
On a different note, I’ll soon (next couple days) be adding to the editor the ability to specify a rectangle or line segment for the particles to emit from. (already part of the particle system)
Is this interface getting too complex? Any suggestions?