Effekseer Library (Particles) for jMonkeyEngine 3

Hey guys,

it’s really been a while since I posted here, always been lurking and working on my jME projects though - I don’t want to write a big essay, so I’ll keep it short: I remember reading a while ago, that some users were wishing to read & render Effekseer (A tool to compose particle effects, Effekseer - Particle Effect Creating tool) files in jME. With a quick search, I found this topic (Anybody tried Effekseer?), but I also remember another one with some sort of wishlist for jME where someone mentioned it.

I started writing the according code and it finally starts looking like something: :slight_smile:

During the next weeks, I will try to publish the code in a sustainable way and probably offer the library as a Maven+Gradle dependency, so you can include it in your projects and easily get updates/fixes. As the video description says, it doesn’t nearly support all features of Effekseer, but the most important ones are in, so the next step will be optimization, which I didn’t do any of - I was too busy reverse engineering their file format and how their system works internally. Therefore, since the visuals won’t really change in the next time, I decided to post the video so you guys are aware of it and as such a tool might be helpful for someone.

Best regards,
destro :slight_smile:

P.S.: The Effekseer samples come with around 300 ready-to-use (and actually very good looking) particle effects (the ones you see in the video are all part of those), which is a huge motivation as it means with a good “connector” library, we will have all of them instantly available.


Amazing :grinning:

Thank you so much, dear @destroflyer :heart:

Woow :open_mouth:
Realy nice effects @destroflyer !!

This is amazing. It would be fantastic to have this quality of particle effects so easily obtainable.

Is this using the jme particle emitter? If yes, would it be possible to base it on top of this?

No, it’s not based on the jME ParticleEmitter which is included per default (not sure if it’s in the core, I think so?). It’s an own codebase and has to be, as its doing a lot more than just quads. It builds ring meshes, modifies them at runtime, connects particles to tracks and ribbons, interpolates colors, scrolls UV values etc. You can check out the tool and browse through the sample effects to get an overview what is the overall scope.

That all said, I havent optimized anything yet - Main points will be evaluating to what extent I can use instancing here. Which will be possible for the simple parts I think, but probably not for all parts. But just for these complexity reasons (which are e.g. not covered in the default emitter, which is fine) there is probably no way I can base this on another system, it has to be its own I think.

What I can already say, is that 90% of the shininess of particle effects is dependent on the texture quality. And there are quite some good ones in the samples, so I really recommend to check them out if you are interested in the topic and are playing around yourself. :slight_smile:


@destroflyer would it be needed to add their native runtime library and plug-ins or there is no dependency to them at all?

And from what I understand we can modify the effects from the code at runtime, yes?

No, it’s completely seperated, you don’t need any depedency to them or their native stuff. The library simply reads the file and translates it to jME stuff. The final interface is currently a control which you add to a node, which then attaches the effect there.

Edit: Yes, you can control it then via code. I read the file into a data structure, which you then could modify (or even generate dynamically in the first place) via code before playing the effect.


Cool, thanks!

This is a wonderful piece of art!
Well done, @destroflyer!

Excellent contribution! Can’t wait to use its stable version. Thanks!

@destroflyer had a chance to check it out today, effects look pretty cool, in some of them fps goes very low (less than 10) for me, maybe needs some optimization :slightly_smiling_face:

By the way, can you please let us know approximately when this might be ready to use? :slightly_smiling_face:


I don’t know by when, since I can only work in my freetime on it. Can be days, can be months. But as I said, it will have to be refactored a lot anyways for the optimizations I plan to do, so I would ask not to checkout and use it in your projects.
It will anyways only be offered and supported via a Maven/Gradle dependency. I made very very bad exerperience with the last framework I published, that people immediately forked, changed to their needs and then asked for support when soemthing didn’t work (that’s why I was a bit afraid tbh when you already star-ed the empty github project before I even posted a link to my Github at all) (Nothing personal, it just reminded me a lot of that old situation :smiley: ). The only reason I put the repo public was honestly that I wanted to drag it in via jitpack to try something out in another project without going through all the authentification/token stuff for private repos. And maybe I should have done that before unfinished versions of the project fly through the internet.

So long story short: I don’t know by when. You always have the option to already fork and use it (and I don’t forbid that or anything, it’s open source after all), but it honestly just reduces my motivation if it’s being used via a fork before being optimized


I see, thanks.

I have no intention to fork it and change it. I star-ed and am watching it because I am interested in it, and looking forward to use it in my game. :slightly_smiling_face:


Any status update? I am excited to see this work.

The thing I feared the most happened - I got distracted by another project I’m working on :confused:

I thought about it and because I don’t think I will have time for the big improvements the next weeks, it should be fine to already try to integrate it on your sides via github + jitpack.io - That way, you can normally include it via Maven/Gradle and when I will have time to setup the deployment to the central repos, you will just have to change the groupId+version.

You can find the latest commits here: Commits · destroflyer/jme3-effekseer · GitHub

For jitpack.io (or any other tool that lets you use github repos as dependency), there are tons of tutorials on the internet (and their own page), but you can use something like the following:




… where version is the commit hash. I did the same to try it out in another project of me (which was the reason why I wrote this in the first place) and it worked. I haven’t done any further work in that area yet though. So this is pretty much the situation right now.

It’s far from a perfect solution, but it will at least work for now, so you guys can play around with it and give feedback. I would like to ask you guys to use the codebase via a dependency like Maven/Gradle instead of copy-pasting/forking though, because otherwise it will be impossible to support / develop it further, before it even started :smiley: If you find any bugs, I am happy to fix them. The big refactoring I was talking about is really only related to performance, the visual results should already look ok, so if you don’t use a million of particles, it could already be usable in your projects. There is a test project with code that plays a few animations in the same repository - I didn’t make a real documentation yet, but it should be easy to figure out how to play the animations, it’s basically just a jME control which acts in the normal jME lifecycle.

Sorry, that it’s not more I can offer right now. But the project is on my to-do-list which sadly happens to be as long as ever :frowning:


I’m trying to test your library and for every effect I tried I’m getting an IndexOutOfBoundsException:

	at java.nio.Buffer.checkIndex(Buffer.java:540)
	at java.nio.DirectFloatBufferU.get(DirectFloatBufferU.java:253)
	at com.jme3.collision.bih.BIHTree.initTriList(BIHTree.java:87)
	at com.jme3.collision.bih.BIHTree.<init>(BIHTree.java:135)
	at com.jme3.collision.bih.BIHTree.<init>(BIHTree.java:139)
	at com.jme3.scene.Mesh.createCollisionData(Mesh.java:991)
	at com.jme3.scene.Mesh.collideWith(Mesh.java:1032)
	at com.jme3.scene.Geometry.collideWith(Geometry.java:472)
	at com.jme3.scene.Node.collideWith(Node.java:615)
	at com.simsilica.lemur.event.PickEventSession.cursorMoved(PickEventSession.java:567)
	at com.simsilica.lemur.event.MouseAppState.dispatchMotion(MouseAppState.java:94)
	at com.simsilica.lemur.event.BasePickState.update(BasePickState.java:239)
	at com.jme3.app.state.AppStateManager.update(AppStateManager.java:356)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:255)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:153)
	at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:193)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:234)
	at java.lang.Thread.run(Thread.java:745)

do you have any idea why?



I received the same error when integrating it in an application with raycasting.
I’m not sure what causes it, I didn’t have time to analyze it yet - But it’s definitely happening when the raycast is taking place, as can be seen in the stracktrace. Maybe the timing of buffer update vs raycast is just wrong.


You mean raycasting from my side? because I didn’t do any.
I can see there is a lemur component handling a mouse move event. I guess that’s where the raycasting happens but I thought it was your code.
I’ll check if I’m adding any lemur buttons or something , try disabling them see if it helps…

Yes, It’;s lemur library that collides with your code. Even if I’m not adding any lemur components, just initiating it by running: GuiGlobals.initialize(this);
I guess this adds some GUI related stuff like checking mouse move etc.
Anyway, I can’t not use GUI / Ray casting in my code so If you will be able to check why is that happening I’ll be glad to try using your lib. because it looks so cool :slight_smile: