GImpactShape Test Added

[louhy]

As requested, here's a physics test using GImpactShapes. For the left side "floor" I used a MeshCollisionShape, the right side is a GImpactCollisionShape. All the dropping objects are GImpact.

What's interesting is how different the floors behave. The mesh shape sometimes allows objects to fall through. For me it's always on the 1st, 2nd, and 5th tests, and it's always the same objects at the same places. The GImpact floor never drops anything, and things seem to settle a little better. 😐

It's actually 6 slightly different tests which repeat:

• 1st Test: 10 solver iterations, large pot
• 2nd Test: 20 solver iterations, large pot
• 3rd Test: 30 solver iterations, large pot
• 4th Test: 10 solver iterations, small pot
• 5th Test: 20 solver iterations, small pot
• 6th Test: 30 solver iterations, small pot

I may add some additional documentation & description later but this should be enough for feedback and such now. Planning to follow up with more tests like this as time allows (open to suggestions also).

[stephengold]

Thank you for your contribution. JME needed a test to demonstrate GImpactShape. And thank you for formatting your code nicely.

Do please add more documentation, including your description (above) of what the test does.

In order to set a good example, GImpactShape should only be used where it makes some sense--not on boxes, cylinders, and spheres, for which Bullet provides more efficient algorithms. Suggestions: Torus/PQTorus, Sinbad's sword ("Models/Sinbad/sword.mesh.xml"), the signpost ("Models/Sign Post/Sign Post.mesh.xml"), and/or the rocket ("SpaceCraft/Rocket.mesh.xml").

Regarding the fall-through issue, I believe it's a bug in JBullet. I tried enabling continuous collision detection (CCD), and that didn't help. But replacing jme3-jbullet with jme3-bullet seemed to resolve the issue, even without CCD. Please open an issue against jMonkeyEngine at GitHub.

Sometimes shapes roll off the edge of a floor. In order to demonstrate the fall-through issue, the floor needs to be larger and/or more concave so that objects don't roll off.

[louhy]

Good feedback, I'll follow up with some upgrades.

Yeah with the fall-through, I ended up with the current version which demonstrates it every time consistently by chance. Tweaking things sometimes made that stop happening, so I settled with what you see to make sure someone else got a chance to see it.

Issue added: #1120

[stephengold]

Looking forward those upgrades!

[louhy]

Yeah, thanks for the reminder - it will get done, and I do plan to work on some more examples/tests. I've got some nice enhancements half ready, but need a bit more time to refine.

[louhy]

Okay, another version coming tonight. Still a work in progress but I could use some feedback. Closer to what I originally had in mind but I'm not happy with it yet. The main issue is for JBullet, some things really want to bounce far, at larger scales. Because of that bounce issue, resizing and concaving the floor further only helps so much. Native Bullet performs much better in this area... I'm very disappointed at the behavior I see from JBullet. I actually tried putting some damping on the rocket to mitigate the issue, but no luck yet.

Rocket and Teapot are the worst offenders (PQTorus was also very bad until I scaled it down.). Running JBullet, hit "+" 3 times to scale at ~1.6 to see things start to break down. The fall-through issue is still there also at this scale, but I haven't noticed it yet at the default and smaller scales.

I'll do a final description once tweaks are done. It still has mesh/GImpact shapes as the "floor" on left and right sides respectively. All dropped objects are GImpact. Solver iterations will increase automatically from 10, 20, to 30 and then repeat. Scale stays the same until a plus or minus key is pressed. Space bar repeats the test with current parameters. Another enhancement is that things should now be dropping on the same locations on both floors, so we can compare the differences a little better.

Something of note, for me the rocket falls through the mesh (left) floor at the largest scale and 20 solver iterations - for native Bullet. You're more familiar with Bullet than I, so improvement suggestions welcome. I'm particularly stumped at what we'd call a "pass/fail" (other than no fall-through), but maybe this is more of a demonstration/example anyway. 😕

[stephengold]

I'm glad you're making progress. Now you see why I wanted more physics tests: Bullet physics is very complex.

At this point, I'm uninterested in debugging jme3-jbullet. If your GImpact shape test demonstrates bugs in jme3-jbullet, that's not a show-stopper for me. But perhaps we should make jme3-bullet the default physics for the jme3-examples sub-project.

I'll take a look at the rocket model with GImpact in jme3-bullet.

Generally, I encourage you to open new issues at GitHub whenever you discover a problem. Issues that aren't tracked are at risk of being forgotten.

[stephengold]

One thing I just noticed, that perhaps you would've cleaned up yourself eventually: in a 640x480 window, the testInfo text gets cut off.

[stephengold]

Another minor point: my keyboard has 2 "+" keys and 2 "-" keys--one pair on the keypad and one pair just above the "[" key. To avoid confusion, map KEY_EQUALS and KEY_MINUS to the same functions as KEY_ADD and KEY_SUBTRACT.

[stephengold]

After running the app a few more times, I've come to dislike the way it automatically proceeds to a new scenario after 20 seconds. I'd prefer to let the test run until the user presses a key.

[stephengold]

An additional feature that'd be "nice to have" would be a way to freeze the physics simulation---without freezing camera motion. That would allow the user to study a fast-changing situation from various angles. BulletAppState.setSpeed(1-speed) should do the trick.

[stephengold]

I may have figured out the fall-through issue. See issue #1130.

[stephengold]

If you pull in the latest commits to jmonkeyengine, you'll get a fix for jme3-bullet's GImpactCollisionShape. I haven't yet looked to see if there's a similar issue in jme3-jbullet.

[louhy]

I concur with accepting JBullet's oddities, just from this testing I can see it clearly needs significant attention to reach parity with native. Making native the default for the examples makes sense in light of things.

Would the rocket's "rocketing" behavior really be considered an issue? I guess I'm just used to physics engines doing weird stuff like that, and assumed that fine tuning & tricks were always needed to get release quality stuff to behave nice.

We'll drop the auto-advance timer - this simplifies things a bit anyway. Good suggestions, thanks for the feedback, I think we can do most or all of that.

Side note: 640x480 - I'm on a 49" ultrawide curved monitor with a 5120x1440 resolution. I'm not testing at full screen, but I may have neglected testing such a puny resolution. It's literally smaller than most dialog boxes I see. 🤣

[louhy]

Just a real quick update for some of your minor tweaks committed now. I'll have more time for monkeying around with this & checking out #1130 over the weekend.

[stephengold]

Regarding the rocketing, it's OK for jme3-bullet and jme3-jbullet to behave differently. However, it's good to document unexpected behaviors and allow others to decide whether they're worth investigating further.

[louhy]

I think we're in okay shape with this now. Native "passes" at default parameters, JB almost passes with initial settings but not quite due to that rocket (never goes inactive on mesh, bounces a little excessively on GImpact). Comments and some key observations added. Let me know if anything is confusing or misleading.

Do you agree on the failure conditions? i.e. No fall-through and objects should eventually go inactive instead of sitting there and bouncing for a non-reasonable amount of time. Maybe we should also add something like "no rocketing into space, even if it's an actual rocket". 😆

...
Side note, I find it strange that things can gain so much energy created out of nowhere, just because they (presumably) fell through another collision shape a little too far. Particularly with JBullet. You'd think there would be some limiting factor which prevents something from shooting off at 1,000 mph when it was previously moving very slowly. Fun to see the rocket actually rocketing, but this definitely breaks the actual laws of physics. In an actual game/simulation, a very hard hit would likely result in damage or an explosion anyway, but in some cases seen here things can hit harder after a bounce than it hit on the initial collision.

[stephengold]

"Rocketing" behavior is frequently seen in physics simulations. Often it results from 2 rigid objects occupying the same space and the simulator trying very hard to resolve the conflict. Sometimes it results from numerical instabilities in the solver: ERP > 1, for instance. I'm unsure what's causing it in this test.

I'll make another review pass and let you know what I think.

[stephengold]

Nice work! This is already one of the best physics demos in jme3-examples.

I'm okay integrating it as is, but I'd like you to consider a few minor points:

1. Elapsed time should refer to simulated time. When the simulation is paused, the elapsed time should stop advancing.
2. Since thescaleMod ranges from 0.5 to 1.9 in increments of 0.1, displaying it to 7 decimal places is overkill and distracting.
3. In order to set a good example, the floor should actually be a HeightfieldCollisionShape.
4. When I move the camera around, it's easy to forget which floor is the MeshCollisionShape and which one is the GImpactCollisionShape. I wish there was some easy way to tell them apart. Or perhaps it would be better to test just one floor at a time.

[louhy]

1 - Oh yeah. Didn't consider that consequence of the pause feature. Will address.
2 - Yeah that wasn't intentional, just didn't seem worth fixing, but it slightly nags me too.
3 - I'll think about this one, I wanted to demonstrate GImpact-on-GImpact collisions. I did have a project a few years ago where I was forced to use GImpact for terrain because of some issue that prevented me from using a heightfield, so that's why it even occurred to me to do it this way. Certainly I'll use a heightfield in other collision shape tests.
4 - Fair enough, will consider a way to address before moving on to something different.

[stephengold]

At some point, the goals of a test and the goals of an example start to conflict.

• From a testing point of view, having GImp/GImp as an option is a good thing. It's supposed to work. But then, so are GImp/Mesh and GImp/HF. (And GImp/Plane for that matter.)
• From a didactic point of view, we probably shouldn't encourage the use of GImpactCollisionShape for non-moving objects, nor the use of MeshCollisionShape for heightfields.

Come to think of it, perhaps you could address 3 and 4 at the same time: leverage the shape limitations to distinguish the various floors: the Mesh floor could have vertical walls around the edges, and the GImp floor could rotate slowly or experience occasional earthquakes. (I'm a California guy, what can I say?)

[empirephoenix]

• From a didactic point of view, we probably shouldn't encourage the use of GImpactCollisionShape for non-moving objects, nor the use of MeshCollisionShape for heightfields.

Hm, I almost use them exclusively due to way better performance when stuff is a good bit above ground (as it often is culled in the internal tree very early) For any kind of flight simulator ect. they are way superior

[stephengold]

I'm surprised GImpactCollisionShape would give better performance than MeshCollisionShape for non-moving objects. I would expect most culling to take place in broadphase (where only the AABB matters) but apparently you have the advantage of experience here.

[louhy]

Hmm, so what's the verdict? I guess I don't mind replacing the floors, but a mental break from this particular test would be good too. I think I'll make the next one(s) a bit simpler (fewer things going on at once), but maybe more configurable.

A dynamic/random morphing mesh crossed my mind at one point. Partly because it would look cool. For this particular test I decided to go with something which was repeatable, so I scrapped that. But there's no reason that can't be a different test/example. I don't know if wanna be the dedicated "test guy" but I plan to be involved here indefinitely, so we'll get to it.

That's a good point about "test vs. examples". Since it's called "jme3-examples", but we're kind of using it as a test... what is this thing? 🤣 I was more in a test mindset here, so best practices and setting a good example didn't occur to me, until you brought it up.

[stephengold]

Hmm, so what's the verdict?

Like I said, I'm okay integrating it as is. You said you'd address the elapsed time issue, so I held off, expecting at least one more commit.

[louhy]

That should take care of most of those issues I think, sorry for the delay (general distractions).

[stephengold]

Thanks again for your contribution.