Particle Monkey

User Code & Projects Particle Monkey
1

Since the feedback has been overwhelmingly to let the particle system percolate for a while and mature… I give you particle monkey!

I’ve added it to bintray and it should be available here:

repositories {
    maven {
        url  "https://dl.bintray.com/jeddic/EpagaTools" 
    }
}
dependencies {
    compile 'com.epaga:particlemonkey:1.0.1'
}

I’m going to take some time to refine the API and enhance some of the features I haven’t gotten around to yet. Some sort of visual editing integration is up next. As well as any bug fixes that come up.

20 Likes
2

Looking nice! You’d probably want to put it up on the asset store as well.

1 Like
3

Yea, that is on my todo list :slight_smile:

1 Like
4

Cool, going to try it soon.
Thank you so much @glh3586. :slightly_smiling_face:

5

@jayfella can we have a new forum category for Particle Monkey? (User Code & Projects - Particle Monkey)

6

@glh3586 maybe you like to add the ParticleTweens as an extension to Particle Monkey and release it separately.

See Lemur extension for example:

7

Why release it separately? I don’t imagine that it will change much other than maybe adding a few and it’s not like it would be used without the library in the first place. Lemur is a bit different in that respect.

8

So that Particle Monkey itself wont depend on JME 3.3 to use.

I mean to just put the ParticleTweens.java into the extension and make it depends on Particle Monkey library and JME 3.3.

See lemur props extension, it just contains one class and is released independently :

9

Done did.

4 Likes
10

Thank you so much Jay :slightly_smiling_face:

11

Is the visual editor (for sdk, intellij, standalone… - I don’t care) available somewhere already? Particles are not something easily done in code, at least for me.

12

When trying to run the example from github readme I get this:

SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.NoSuchMethodError: java.nio.FloatBuffer.flip()Ljava/nio/FloatBuffer;
	at com.epaga.particles.particle.ParticleDataTriMesh.initParticleData(ParticleDataTriMesh.java:124)
	at com.epaga.particles.Emitter.initParticles(Emitter.java:218)
	at com.epaga.particles.Emitter.initParticles(Emitter.java:198)
	at com.epaga.particles.Emitter.<init>(Emitter.java:176)
	at com.grizeldi.particleTest.Main.simpleInitApp(Main.java:24)
	at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:237)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:130)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:211)
	at java.lang.Thread.run(Thread.java:748)

Does Particle Monkey require java > 8 by any chance?

13

Ah sorry for my ignorance @glh3586, never mind the above suggestion. I made the above suggestion because in my previous check I thought you have removed particle tweens, I just figured out you have already included them in a new class ParticleHelper.java.

Just run the tests in the Main class. They work fine for me. Great job. :heart:

14

btw, in gradle version 5+ I needed to add these into afterEvaluate 

            afterEvaluate {
                artifact sourcesJar
                artifact javadocJar
            }

else it fails with this error:

> Could not get unknown property 'sourcesJar' for object of type org.gradle.api.publish.maven.internal.publication.DefaultMavenPublication.

15

It shouldn’t. The project is configured with java 8. I’ll double check that it didn’t get compiled with a later java version by accident.

As far as the visual editor goes… I had it mostly working in the SDK before I moved it into its own plugin. I’m trying to figure out how that should all work with the SDK now. I agree that editing particle systems in code is no fun at all.

1 Like
16

Thanks for the info! I really need to spend some time figuring out what has changed in gradle with 5+.

1 Like
17

Thought it would be best to post here instead of leaving messages on discord.

You have two methods to add an influencer, but none to remove any. This is a bit of a pain to bind getters and setters. I’d appreciate it if you could add the following methods:

removeInfluencer(Class<? extends ParticleInfluencer);
removeInfluencer(Class<? extends ParticleInfluencer, boolean reload);
18

Doh, that is a bit of an oversight. I’ve added it to my local copy. I have a few other changes I’m still working on and then I’ll push them to git.

1 Like
19

Tried giving the library another shot with various versions of Java. All of the used jdks are openjdk builds from the official Ubuntu repositories.

  • On Java 8 it crashes with the before mentioned NoSuchMethodError. Stack overflow says that this tends to happen when the library was compiled with java > 8 and is run on java 8 jvm, as Java 9 introduced overloaded versions of the flip() method.
  • On Java 11 it crashes with Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed! This is a known issue with openjdk11 which plagues the sdk as well and I think @jayfella had similar problems with the engine itself once. Not the library’s fault.
  • On java 13 it crashed with some error about the class major version being unsupported. Turns out my local gradle install wasn’t compiled with java 13 or above, so it doesn’t work. Again not really the library’s fault.

Then I kinda ran out of Java versions to test.

20

More precisely, it’s an issue with lwjgl2/jogl 2.3

Lwjgl3 and the upcoming jogl2.4 so far seem to fix this.