A new particle system is currently available from the contribution repository, I’m having trouble getting it set up as a proper plugin so it’s not available as a plugin yet but it should be soon.
It was inspired by and uses some code from both t0neg0ds system as described in her thread here: http://hub.jmonkeyengine.org/forum/topic/first-look-at-a-new-influencer-based-particleemitter-candidate/ and the existing jME3 particle system. Unfortunately due to t0neg0d’s involuntary non-availability I wasn’t able to get in touch with her when I started work on this so it’s not as collaborative as I’d have liked.
It provides most of the functionality from hers (It doesn’t currently support animated meshes on particles, or generating of static particles that move with the parent mesh. Both of those could be provided if people have a use for them within this framework) with enhancements in a number of areas and should be as fast or faster than the current particle system, while offering massively more flexibility.
The API may need to be “jmonkified” to fit in more with the feel of the rest of the engine so should not be considered final just yet. At this stage I’m mostly looking for feedback on the API, the functionality, and any potential bugs or improvements although people are welcome to start using it for their projects (I know I am about to!).
I’ve created a wiki page that step-by-step introduces the functionality, and also a reference page for the options currently in place:
The introduction builds up to doing things like this:
Sorry for the jitter in the video, it didn’t like the recorder app state for some reason.
All feedback is welcome.
One thing I’m thinking about doing is distinguishing between “on creation” influencers and “on update” influencers. At the moment it runs through every influencer for every particle every frame, while certain influencers only actually need to do anything when particles are first initialize. By separating the lists internally it should speed up the update loop a bit, although an empty method call per influencer particle per frame isn’t a huge deal it does add up for large numbers of particles and influencers.
Its exciting to see better particle effects coming to JME
I think another enhancement that could be useful is to extend your idea of having multiple control points from the MultiColorInfluencer to the other influencer types as well. Most profession grade particles systems I’ve seen let you have some pretty fine grained control over how particles behave over time. I’ve personally had to do that for the particle effects in my project.
I could certainly do that, but I’m not sure which influencers it would be useful for?
Creating your own influencer is really really easy (it’s a very simple interface) so I expect most custom requirements can easily be met by writing your own influencers.
I’m done. Good luck all… This was wrong to do… I asked you not to, but you decided to do it anyways.
EDIT: Nehon said they were planning on integrating the particle system into core… which part of this could you not wait for. More so, just because YOU couldn’t wait, didn’t give you the right to kype my code and release it to others. You, sir, are an ass.
P.S. The way buffers are being handled in both the systems you “based” this off of have a glaring error in them. You may want to un-“base” that portion of “your” code before you release this to others.
@t0neg0d - what’s the glaring error?
@madjack - yeah, I noticed that but I’m not sure what’s caused it. It’s like the smoke didn’t draw for a frame or maybe got drawn behind the fire or something.
After reading Chris’ edit… yeah.
Not entirely convinced releasing this was a good idea. That you wanted a particle lib is understandable, but using Chris’ incomplete lib, tweaking it and releasing it as yours? Yeah. I’ll leave it at that.
Where I come from it’s called copyright infringement. It wasn’t released to the public although it was publicly available.
Anyway. Before judging anything I’ll withhold what I’m genuinely thinking until I can read both sides of the story, but yeah, very disappointing either way… :-x
I was hoping to keep this little drama private as it doesn’t really do her any favours and she’s been having a bad few months…but since she decided to bring it up:
As I’ve already told Chris several times (but it went in one ear and out the other):
This is not her code repackaged, this is my own work inspired by what she had done and taking in some elements of code from both hers and the existing one. The core framework is entirely rewritten, some elements of the mesh handling come from hers and/or the jme one, some of the influencers come from hers (but even then just some of them, and one of her influencers was seriously bugged so needed rewriting anyway although I don’t remember why off hand.
1.b. She released hers under the jME3 open source license. That means its open source and I can then use it to build off. Copyright is irrelevant.
I tried to contact her before I did anything. Initially because I was looking for some examples on how to use hers and some feedback on how some things worked. Once I’d reviewed hers and realised that I could make some improvements I waited for well over a week with no reply before I even started work on my own particle system. By that time I’d reviewed hers and found some quite large architectural limitations and since I needed a particle system myself I got on with it.
I tried to discuss it with her when she did return and even give her a heads up in private messages. All that I got back was “DONT RELEASE MY CODE AS YOURS” and her complaining to the core devs about it meaning I have to spend my time explaining the situation to them as well.
So, I’m sorry she’s upset. She’s done a lot of good stuff for jME, but she’s gone completely off the rails on this one. She released something open source, disappeared for a few months, and then came back and was upset because someone had built something inspired by what she had done.
Soooo… how are static particles workin’ for ya?
How about animated particles?
29 FPS… all sorts of amazing results from this work of art >.<
I can’t believe you’re actually asking me what the error is… un-fucking-believable.
That depends, how childish are you? If you’d rather get some petty vengeance by holding back information on a potential bug then that’s your choice. I’m sure it will get found and fixed at some point … or might even already have been fixed since I changed a few things in the buffer handling.
I guess the properties of the VideoRecordedAppState slipped your mind? It limits the framerate to 30. I get several thousand fps with 64 3d (complete with uv mapping, conversion of normals, etc) particles and thousands of 2d particles on 2 emitters. It also looks a lot smoother, in fact I’ve been thinking about re-shooting the videos using a different capture method.
Sorry, it’s not flying on my side of things. It’s actually hitting a 10 feet thick steel wall at 100 mph (160 km/h) with a wooden car. All I hear are excuses.
Removing those links and deeply apologizing to her is the only way you can start redeeming yourself in my eyes. You probably don’t give a shit, but that’s how I roll. I would also be fucking pissed if it were me.
So now I can thank you profusely because from all account Chris will also drop her gui library, making me throw out the window over 4 MONTHS of work. Maybe I should send you a fraking bill for this.
Eff you very much zarch.
Seriously… fuck you. lol
Damn straight I’m not going to help you kype my work. Congratz on this brilliant PoS! Your ability to reorganize other peoples code (and in the process fuck up many features) is just outstanding!
Thread closed. Wild accusations and all kinds of projected thoughts from all sides. jME still has no new particle system.