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 …
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.
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.
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.
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.
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…
Let me know if you need help with this. If this is the only hold-up then I might be able to spare some hours in your direction.
I’m open to enhancing Quad in v3.5, provided there’s a good PR in the next 9 days. Any changes would have to be backward-compatible with the current implementation of Quad.
By the way, my “Heart” library provides a RectangleMesh class with a number of advantages over Quad:
TriangleFan mode is used to reduce the number of indices from 6 to 4,As far as I know, the standard ParticleEmitter in jme3-core is still supported, but nobody’s working to improve it.
Personally, I hate ParticleEmitter, and I doubt it’s worth improving incrementally, though I’m happy to consider simple changes such as defining interfaces. I still use ParticleEmitter in jme-vehicles, but I have long-term plans to create a physics-oriented particle system to replace it.
I don’t know the status of Particle Monkey. Of the public repos at GitHub, Jeddic’s fork is the most advanced, but I don’t see much recent activity there.
Other alternatives to consider include Destroflyer’s effekseer and Riccardo’s effekseer native.
As you may have noticed, the trend since 2018 has been to avoid dumpingadding major features directly into the Engine. Instead, we encourage developers to develop major features as independent libraries. As @pspeed points out, that allows them to follow their own release schedules. If you’d like to follow this path, I can help you get started.
Thanks for working on the PR, I have had some free time minutes ago, I did a quick look on the new changes (but not so deep reading), I think they are better now.
Perhaps you should add yourself as an author to both the ColorAdjustmentFilter and its testcase since most of the changes are actually yours especially the docs.
Again thank you and I am very sorry, my time factor didn’t meet the jme3.5 timings, I will sure try my best on the next release 
.
As for AndroidHarness and fragmentHarness, I got them fixed (some issues on git address them) locally, I am currently testing them using appProfiler, I was planing to integrate them in the new jme3.5 but I got busy, so may be will do so on the next release and its fine they had better be tested multiple times before integrating into jme.
And Merry Christmas to all !!
EDIT : I will focus more on the animation system javadocs PR when I have some free time. I hope you add the animation docs as a separate project from the jme3.5.0.
I’ll consider adding more author tags. Usually I don’t worry about them.
The 15 December deadline is for new features and library enhancements. If your changes to AndroidHarness and FragmentHarness are bug fixes and/or documentation, they can still be included in v3.5.0-stable, even if they aren’t ready on 15 December.
The distinction between a bugfix and a feature can be subtle. If in doubt, ask!
If I run into a specific problem I will let you know. I vaguely know what I’m supposed to do, but I only used Lemur for a very specific case in my last game, so my experience and understanding are lacking at the moment. I’ve been planning to sit down and spend some more time on it soon.
I have some changes locally I’ve been making. There probably won’t be a new release until I get an alpha of the particle editor going.
The new AndroidHarness and FragmentHarness would deprecate the old ones and they will use compat androidx, fix bugs and add new features (or at least better code), they will both use the new features of JmeSurfaceView directly. So,.I think this would take time more than just fixing bugs.
Better wait for the 3.6 release, then.
I open a issue.
Expand Quad to support changing the orientation #1700
Let me know if that sounds okay.
Yes, I would make the default to lower left corner like before, so no changes to existing applications.
Alright, I will take my time on this PR, then I may commit it even before the jme3.6 milestone and convert it to a draft to be revised and merged when we open the new milestone.
Btw, do you plan to merge this PR ? :
Issue 1700 sounds okay. But honestly, I can’t imagine ever using the proposed feature. Do you have a use case in mind?
I haven’t decided whether to include PR 1652 in JME v3.5.
Mainly, I don’t understand the motivation for it. I understand why someone might want blend-space alternatives to BlendSpace, for nonlinear blending maybe. But why something so exotic: 2 parameters, with one of them having nonlinear effect?
Actually, I’m not 100% sure I understand what PieChartBlendSpace does.
If PieChartBlendSpace is intended mainly as an example, it seems unnecessarily complex. Also, examples should be in “jme3-examples” not “jme3-core”.
If it’s not an example, then I assume it’s intended for use in production. But if there’s a common use case for it, I can’t imagine what it might be.
I was also waiting to see whether @Ali_RS would make another review pass.
Hi,
I didn’t follow the whole discussion here, but just wanted to mention that I have a Macbook that I could test stuff on. I think it’s from around 2016 / 2018 and I didn’t update the OSX in a while…
If I should start testing JME on it where should I begin? Install the SDK?