Next release of the Engine

I’ve created a milestone for a v3.4.1 release. I hope the release can take place in the coming week.

I propose to include the following low-risk/high-value fixes from “master” branch:

Also considered, but probably won’t include:

3 Likes

After this PR is reviewed, it would be good to get it in 3.4.1: Chase cam can rotate fix on re-enable by tlf30 · Pull Request #1692 · jMonkeyEngine/jmonkeyengine (github.com)

I have reached out to @clericbob who had the original issue to test and see if it works for them.

1 Like

PR 1692 probably won’t be in 3.4.1 because it’s possible some app might rely on the ChaseCamera.setEnabled() behaving the way it did in v3.4 .

I would like you to consider the following PR for inclusion in the v3.4.1 release :

This PR is low-risk because it concerns only a log in a single class, and it is (IMHO) high-value because it concerns the performances of a method in the critical path (i.e. something that must be done in the main thread during the update()). Although the perf impact may seem low, it was sufficiently high to be spotted during my investigations.

2 Likes

I agree it’s a good change and worthy of a point release.

Note: if you find detach to be a measurable “bottleneck” then there are lots of reasons not to detach so many things in a single frame.

It’s still a good change, though… because the old code is silly and from experience silly code is 100x more likely to be emulated/copypasta’d elsewhere.

2 Likes

honest question, would it be crazy to use the contributions money to buy someone a used mac?

5 Likes

@pspeed : Actually I am not detaching many nodes (just 2 or 3 in the update), so it isn’t strictly speaking a bottleneck.
My objective is to run my game on low-end Android devices at the fastest frame rate (i.e. trying to reach 60 fps…) and, even more importantly, avoid noticeable lags.
I’m thus hunting all performances issues on the critical path, and such hardware has the benefit to reveal anything suboptimal :wink: .
During my investigations, I noticed a (slight) lag when updating the node hierarchy and went to this PR.
This lag of course can’t be revealed with regular GPU hardware.

1 Like

I would like you to consider the following PR for inclusion in the v3.4.1 release :

That’s a good candidate. I’ve added it to the milestone. Thanks for the suggestion!

would it be crazy to use the contributions money to buy someone a used mac?

Not crazy. I had the same thought myself! Though looking to the future, maybe a Chromebook would make more sense…

1 Like

I thought that I could have been able to finish this 2 weeks ago, but for now I have no time (and that may be extended for another 2 weeks).

I apologize, this should not have taken all this long time.

1 Like

I think we’re nearly done with PR 1665. Perhaps I can help complete it. With your permission, I’d like to push (not force-push) commits directly to the “colorAdjustmentFilter” branch of your “BranchedJme3” repo. Would that be OK?

1 Like

You are authorized to do this, I have no problem at all, but I have no time to review any changes, so consider someone else to review the changes (if you plan to merge directly after applying the requested changes, otherwise I will be available in 2 more weeks for reviewing code and PRs).

Good luck and let us know how it goes ! :slightly_smiling_face:

EDIT : I have invited you to gain a full access on this repo and push on the branch ‘colorAdjustmentFilter’ directly, I think that would directly add commits to my PR :

1 Like

Thanks.

After you’ve created a pull request at GitHub, there’s often a checkbox in the “Discussion” tab (at the bottom of the right sidebar), which you can use to give maintainers edit permission. Since I’m a maintainer, that would’ve been sufficient in this case.

1 Like

Its activated by default.

2 Likes

Locally, I can buy (used) PowerPC-based macs (G3 or G4) for under USD 200, but I don’t think those are worth testing. A used 64-bit mac is more expensive, like asking USD 400 for a MacBook Air (1.6-GHz i5) or USD 1200 for a 4th-gen Mac Mini (3.2-GHz i7). I’ll keep looking…

JMonkeyEngine v3.4.1 has been released to GitHub and Maven Central. Details to follow …

1 Like

The big thing at the moment is apples switch to arm. I don’t mind testing anything on the intel macs, but I don’t have one of their arm ones yet.

1 Like

Are you guys open to an enhancement to Quad.

This would be nice to new people special that don’t have lower level idea, being able to change orientation for its placement.

Right now Quads are center at lower left corner. Enhancement would be able to change this, lowerLeft, LowerCenter, LowerRight, Center, UpperLeft, UpperCenter, UpperRight.

It is a simple addition to just alter the vertices so it alter the orientation.

Let me know.

1 Like

What is your guys take on Particles. Is the standard ParticleEmitter basically there but not really support and point everyone to Particle Monkey?

Just wondering, I’ve checked out Particle Monkey but have not changed to it and just wondering if you plan to make it part of JME or just be and add on?
If not planning on making it part of JME, then are you up to changing ParticleEmitter to have an interface class so if someone creates a new ParticleEmitter they can implement the interface and so class like the ParticleMesh will work.

Right now, ParticleEmitter is not extendable because of major limitation, and it forces you to write your own. But several classes rely on ParticleEmitter class instead of an interface, so a user can expand and not have to rewrite the entire system.

Your guys 2 sense on the subject.

1 Like

I agree this is useful sometimes. I created a CenteredQuad class when I needed a few years ago. Now I use this class instead of the regular Quad.

1 Like

I’m not sure how useful creating an interface for a particle emitter would be. I know the holdup for Particle Monkey at the moment is good editor support. I’ve been working on one slowly over time but I need to create some custom lemur components (IE curve editor) at the moment which I haven’t had a chance to do. I originally intended to merge it into the engine but there wasn’t a lot of support for that at the time.

1 Like

Well, the classic problem of “things include in the engine” is that their release process then attaches itself to JME’s glacial release schedule.

…for essentially 0 benefit other than a bit of visibility.

That being said, the particle emitter that is included in JME is kind of one step above trash at this point. Filled a minimum need at one time… makes a decent example for point sprites… but ultimately not great code, not extensible, etc…

2 Likes