Turborilla has released JopsMonkey, which is simply some code to get JOPS ( http://jops.softmed.org/ ) particle systems to render in jME. JOPS is quite a sweet particle systems lib and is under constant development.
Check it out: A particle system for jME
Teh awesomeness! 
Tobias said:
Turborilla has released JopsMonkey, which is simply some code to get JOPS ( http://jops.softmed.org/ ) particle systems to render in jME. JOPS is quite a sweet particle systems lib and is under constant development.
Check it out: A particle system for jME
It is an excellent idea! JOPS is fine and already integrated in Xith3D. When will your code be put officially inside JME 2.0?
I'm not going to do that, I use jME 1.0 
It should be a breeze for someone here to do it, just get rid of the Batch as I understand it. Is someone up for it? I'll give you dev access to the repository.
I already have a dev access to the repository. Maybe we could ask to other people if it would be fine to include it in JME 2.0.
First: RIGHT ON! (I like options :))
Second: MadSkills Motocross is looking super sweet, for a 2D scroller it is up there with some of the most playable games I have ever seen. Mainly due to the very realistic physics actions. I can't wait to play it :).
As far as including it directly into jME I think the 'adapter' classes needed to the JOPS effects should definitely be included (for jME 2.1 perhaps, 1.0 is frozen basically and 2.0 is about to be marked as stable). The main library is pretty small 150K, I would think that would be something to consider having directly in jME. I dunno about the editor though, there is no OSX compatible editor (:P) and the it will increase the effects download by over 5MB unless we modify the Ant script to not include it.
Also, someone will need to periodically check for updates and do something about them when they come along.
Although the video is quite impressive, there doesn't seem to be much information about the system.
Can you sum up it's strengths, performance etc.?
This is a completely 'self-contained' system, whose focus is only particles.
Although the current 'integrated' particle system can probably create most of those effects, there are a couple that I think would be kind of difficult.
But mainly the 2 nice things about this are:
- Options (I personally like the idea of chosing my own particle system, kinda like the renderer and GUI options)
- Leverage of an external project to ease/facilitate progress
As for performance that can only be answered when tested against the current system on a duplicate setup/implementation. (I kind of have a hunch that the performance will be as good or better though…)
Really impressive!
I think it would be a good addition to the jmex package. I also think that we should not include the editor, as that can be downloaded separately as needed, and really has nothing to do with jME.
I should have clearer in earlier post, there are currently 4(!) versions of the editor available.
Win32 - Java 1.5
Linux - Java 1.5
Win32 - Java 1.6(?)
Linux - Java 1.6(?)
(Honestly I think that's kinda screwy, especially if its just because of the natives that are required.)
Oh, yeah that reminds me. Tobias, how easy will it be for someone to create JOGL bindings for this?
(hopefully not impossible but I guess that might be more of JOPS itself…)
Fracking impressive!
Super-sweet!!!
Another impressive tool like SceneMonitor/Worker!!
jME is constantly evolving. so sweet~ XD
Hi
I'm the creator of the JOPS particle system. I gotta thank Tobias for his interest in JOPS and his willingness to create the integration code. He did a great job and the performance is fantastic.
To clarify a few points : the JOPS main library deals with particle simulation only. Therefore, it has nothing to do with rendering the particles themselves. This is the correct way to do it, because you shouldn't force a particular rendering technology. You won't find any rendering calls on the main library.
So what you need are renderers for the particle system. The renderers draw the particles according to their data.
So far there is a LWJGL renderer, used in the particle editor, there is integration code for Xith3D and this integration code for jMe1.0.
The Editor is a separate application, to create and edit particle systems with the JOPS library. It uses its own LWJGL renderer for preview and SWING GUI as interface.
There is a Java1.5 version of the JOPS library and the editor as requested by the Xith3D team, since their library is on Java1.5. I also keep a version for the most current Java release, therefore the jars are also compiled for Java1.6.
The different "versions" for Windows and linux, are just different packaging, since the binaries are different between platforms, as well as the batch scripts to run the editor.
About integrating jops directly on jMe1.0, that can be done, altough it ads the burden of keeping up with the releases. Maybe the best solution would be to create a guide or manual about fetching the library, configuring the integration code, and how to use it with jMe1.0. My 2 cents…
On the editor being included, I don't agree, because it's a separate application and its pretty big due to the binaries having to be included, and they also differ from platform to platform. Once again, I'd prefer a guide/tutorial.
The JOPS project doesn't have much documentation because I started on a project soon after I made the first release and have been pretty much overwhelmed with work. Documentation will come, eventually.
About features, JOPS is very flexible. There are a lot of options available for configuration, and the API is extensible, so you can add new stuff, such as new emitters, or modifiers, which can be everything from external forces such as gravity, or points masses, to integration with a physics engine for collision detection.
You can setup how the particle's color, alpha and speed changes with time, among other things. The control over the emitters is also extensive and so you can pretty much build what you need. The editor allows access to the particle system's properties, so you can easily edit them. As you can see from the youtube video, you can create a lot of different stuff.
About performance, the particle's position and speed are calculated on the fly, but I precalculate everything else. All of the other attributes that change over time are already precalculated and stored, so it's a question of reading the value and setting it in the particles.
I would like to see JOPS integration for jMe2.0, since jMe1.0 doesn't support some of the blend modes available in the Texture configuration.
Any more info, just let me know.
Thanx for the info guilhermegrg.
(and yes, divorcing the openGL renderer from the implementation is definitely a good thing and should fit nicely into jME's setup)
Although don't anybody get their hopes up for physics particles just yet, ODE (like a samurai) has a tendency to try and commit hara kiri when it feels ashamed that it isn't up to a task. 
(but as for me, I think physics based particles are almost required in this day and age)
Physics particles… Like volumetric simulation? I don't think ODE can do that. This is a job for a GPGPU program…
I wonder if this would be of help:
http://www.cs.princeton.edu/~traer/physics/
(I don't see a way to make the particles react to their surroundings though…)
Thanks for the info guilhermegrg. I look forward to testing it out.
I think volumetrics is a whole different beast, but having particles that act and react in a physically accurate way is a really nice prospect. On the other hand it's also a big performance challenge.
With a good editor and a good set of influences it is usually possible to create a decent illusion of accurate behaviour with much less performance overhead.
When I talked about particles and physics it was about having the collisions between the scenario and the particles properly simulated. I don't know if that fits into the category of volumetric particles or not.
I'm thinking more among the lines of explosions, where 2D debris disappears or bounces of surfaces. It is a fast effect, with maybe a few hundred particles and shouldn't be that heavy to compute. The physics engine would only need to test a few times per second if the particles have collided or not, depending on the calculation rate.
If you are talking about effects such as water fountains and such, then yes, you would better off not integrating with the physics engine and just let JOPS handle it.
I thought about GPGPU for JOPS, but currently have to time for that challenge. Also it would be difficult given NVIDIA and ATI have primarly different languages, even tough finally we have OpenCL. Both companies are supposed to support OpenCL, but I have no idea on the state of that support right now.
I would also have to change the API in order to support different simulation implementations, and then the choice would be made in runtime by auto detect or by config. It's an idea for the future.
But currently you have access to the source and the editor, so you can already start to use the provided examples, and their textures. You don't have to pay anything for any of them, the textures were made by myself to guarantee that there would be no "royalty" or copyright problems. You may use the textures and examples as you like, just as long as you reference the project in the credits :). The source is LGPL, so no probs there, just contribute back your changes.
If any help is needed with using JOPS or the editor, just let me know.