Particle System Revamp

User Code & Projects
41

JME core… where good code goes to die.

42

Huh?

43

I mean, I just think something cool like a brand new particle system will want to evolve a bit more and harden up a little before it enters 3 year release cycles.

…but maybe that’s just me. That’s why i’ve resisted having some of my stuff sucked into core. It’s better if I can fix it and release it “now” instead of “some unknown time from now far in the future”.

To me, there is no point unless you are abandoning the code, basically.

1 Like
44

Would it be wiser to create an add-on library and publish it to JMonkeyStore?

45

For me, yeah that would make more sense.

I’m not sure what the motivation of glh3586 was so I can’t say if there are other reasons important to them. For example, perhaps contributing it to core was a way of handing it off to others to take over.

1 Like
46

I have every intention of supporting it. There are still a number of features I want to add. Part of the motivation is because I want to build it into the SDK. To me, one of the biggest drawbacks of jME at the moment is the lack of good tooling built around the engine. I wasted a TON of time on Spoxel that would have gone much quicker if I was tweaking particle effects in an editor instead by code. This is especially true when you start tweaking curves. If I made it an outside library there isn’t a good way to do that and then I’m stuck making a scene editor.

I agree that that the release frequency isn’t ideal, but shouldn’t the focus be fixing that then? What is the point of contributing to jME then? Honestly, this conversation is more than a little disheartening. Having to piecemeal different components together to get a functional engine is one of the biggest drawbacks to jME for me.

4 Likes
47

Weird. That’s a big strength for me. Generally just another depends line in my build.gradle. In fact, for me personally, a bintray/jcenter release is way more important than core inclusion.

The more things added to the engine, the longer the release cycles will be. Fact. Always fact. Everything we add extends the release cycle. (And while I didn’t look at the patch in detail, “50 files changed” gave me pause… sounded like a lot of extra code to support.)

On the other hand, things outside of the engine can release as often as they like.

Are SDK plugins broken? If so then I guess we should fix that. Because including something in core just because “I wanted to write an SDK plugin”… is not the best reason. That’s one of the reasons we have a terrain library that’s rarely updated.

Though I’d also be curious to know what percentage of JME users even use the SDK at this point. It’s a top notch way for new users to get started but I suspect many of the more experienced devs have moved on at this point.

1 Like
48

I wasted at least a year trying to pull together everything into a cohesive system to work together. When developing a game as a team of one that is a lot of wasted effort that other dev’s have to replicate. So yes, that isn’t a strong point to me.

So what is the point of jME to you then? Why bother with it instead of just using lwjgl and pulling in different libs?

2 Likes
49

To me the SDK excels in the area of managing assets. Like being able to view them as they would look in the engine is awesome. Being able to visualize the node structure is also a great plus. There are some other tools in the SDK that are also very sweet.

After discovering that you can combine gradle with the SDK, now I use gradle for dependancy management and the SDK for asset management.

If it were possible to marry the SDK and Gradle it would be a perfect system for me.

50

IMHO new particle system should go to jme3-effects module not jme3-core.

51

I use the JmeConvert util for this now… it dumps the scene structure and I can write repeatable scripts to do the edits.

…I still have to visualize it “in game”, though.

I think I haven’t had a JME SDK installed on any machine in about 5+ years.

52

Do you mean in SDK?
We can add a dependency to your add-on in SDK.

53

Doesn’t that still put it in the figurative same boat then since the SDK release frequency is the same as jME? What would that accomplish at that point?

Personally, I would love to see the SDK functionality moved to a stand-alone app along with project creation. That way you could use whatever code editor you want.

54

SDK is released independently from the engine.

My suggestion would be:

  • Release your particle system add-on jar into Bintray JCenter and publish it to store.jmonkeyengine.org

  • Create an SDK plugin for particle editor

  • We release new SDK v3.2.4-stable-sdk2 which includes new particle editor and adds a gradle dependency to particle system jar just like we have done for jme3_xbuf and gdx-ai:

56

There’s no prebuilt version of 3.3 sdk, but sdk’s master branch is fully 3.3 compatibile, as both me and darkchaos tend to compile the sdk against the latest master engine branch while working on it.

2 Likes