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.
@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 .
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.
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?
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 !
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 :
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.
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 …
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.
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.
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…