sdk
sdk copied to clipboard
jMonkeyEngine
Replaces Raceway scene with one that opens in the SDK. Deleted redund…
Once tested by @tonihele, it's good to be merged. Thanks for helping us out, hopefully it also sparks some motivation in everyone else 🙂
Yeah, it opens which is a major step forward. But when I press Test vehicle the SDK just crashes :O
It would be good to merge this anyway, seems to be all legit. Vehicle editor itself seems to work. Could be that the physics are not all correct in the model but at least it opens, that should enable many more possibilities fixing it.
I just added a rigidbodycontrol to each mesh because it was expected by the code. Perhaps it needs to be set up differently. I'll see if I can deduce anything else.
On Sun, 20 Mar 2022, 14:11 Toni Helenius, @.***> wrote:
It would be good to merge this anyway, seems to be all legit. Vehicle editor itself seems to work. Could be that the physics are not all correct in the model but at least it opens, that should enable many more possibilities fixing it.
— Reply to this email directly, view it on GitHub https://github.com/jMonkeyEngine/sdk/pull/308#issuecomment-1073248946, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB46MQXF34PG2ZYNUOLVS5LVA4PXLANCNFSM5RC4M6PA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
Also, mine doesn't crash, but I get an exception:
java.lang.AbstractMethodError: Receiver class com.jme3.bullet.BulletAppState does not define or inherit an implementation of the resolved method 'abstract java.lang.String getId()' of interface com.jme3.app.state.AppState.
at com.jme3.app.state.AppStateManager.attach(AppStateManager.java:141)
at com.jme3.gde.vehiclecreator.VehicleEditorController.prepareApplication(VehicleEditorController.java:101)
at com.jme3.gde.vehiclecreator.VehicleCreatorTopComponent$11.call(VehicleCreatorTopComponent.java:919)
at com.jme3.gde.vehiclecreator.VehicleCreatorTopComponent$11.call(VehicleCreatorTopComponent.java:916)
at com.jme3.app.AppTask.invoke(AppTask.java:147)
I think your exception is a version mismatch. jME version mismatch. Maybe you are using jME 3.4+ but the bullet is compiled still using the old? Something like that.
Perhaps related to the other issues, but when I choose 'Edit Vehicle' and the scene opens, the tarmac geometry seems to be rotated 180 degrees.
Just noticed that there is a ghost track also there, maybe some additional geometry that isn't really spot on:
Perhaps related to the other issues, but when I choose 'Edit Vehicle' and the scene opens, the tarmac geometry seems to be rotated 180 degrees.
This.. right...
VehicleEditorController had a couple of lines that changed the physics transform of the spatial:
track.getChild("Grass").getControl(RigidBodyControl.class).setPhysicsLocation(new Vector3f(30, -1, 0));
track.getChild("Grass").getControl(RigidBodyControl.class).setPhysicsRotation(new Quaternion().fromAngleAxis(FastMath.HALF_PI * 0.68f, Vector3f.UNIT_Y).toRotationMatrix());
track.getChild("Road").getControl(RigidBodyControl.class).setPhysicsLocation(new Vector3f(30, 0, 0));
track.getChild("Road").getControl(RigidBodyControl.class).setPhysicsRotation(new Quaternion().fromAngleAxis(FastMath.HALF_PI * 0.68f, Vector3f.UNIT_Y).toRotationMatrix());
I removed them and that fixes the visual discrepancy. I don't know if it was something that was required for the old racetrack to work properly, or something that's needed for bullet. At least it looks OK now.
In theory, if you change the physics representation, the visual representation should also be updated by the RBC, so I can only imagine this being something to setup the scene the correct way or something because it used to be wrong in the source asset?
Anyway, is this ready to merge? Because @tonihele talks about a SDK native crash? I think without that, we also get a crash though? I don't remember if it was less severe and only caused a popup to appear?
Okay, stacktrace says
j com.jme3.bullet.PhysicsSpace.stepSimulation(JFIF)V+0
so I'd also lean onto merging this and seeing if it's gone with Minie that we have to use on master anyway, and if it crashes there, it's a job for @stephengold anyway
If I were given a choice, I'd MUCH rather investigate a Minie bug than a jme3-bullet bug.
A caveat to be aware of: jme3-bullet serialization of physics controls isn't 100% compatible with Minie. I peeked at "Raceway.j3o" and saw it includes at least one RigidBodyControl. If the "Raceway.j3o" was generated using jme3-bullet, then you'll probably wind up needing to re-generate it for Minie.
Oh, that may be a blocker for that PR then, unfortunately. Since jme3-bullet-native is gone, Minie is our only chance having a reasonable physics engine in the SDK anyway, so we definitely go with that.
I added the rigidbodycontrol because it was excepted by the plugin. I can push a j3o without them. I'm away for this week, though.
On Mon, 2 May 2022, 05:05 Stephen Gold, @.***> wrote:
If you want help converting old J3Os to work with Minie, I'm willing!
— Reply to this email directly, view it on GitHub https://github.com/jMonkeyEngine/sdk/pull/308#issuecomment-1114428147, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB46MQWRI7V45I2M3I3XOLDVH4Z6FANCNFSM5RC4M6PA . You are receiving this because you authored the thread.Message ID: @.***>
We have the source .blend file, so it's mostly about converting the j3o with a minie-powered SDK or tool. So I guess for the vehicle to work we need RigidBodyControls and instead of manually generating them via code then, having them in j3o should really be best.
In theory binary format incompatibilities shouldn't be the norm I guess. But we also need to keep that in mind with the release notes, namely that the SDK can't be used on existing projects if they have physics (to some degree at least). Have you considered creating some RBC-upgrade process?
Have you considered creating some RBC-upgrade process?
Not until now. This is the first time in 4 years that the issue has arisen. I suspect that, in 90% of the cases, the correct solution would be to re-do the conversion from Blender (or glTF) as you've proposed here.
Do I need to do anything? Should the new RigidBodyControls be added through code with Minie in the classpath?
Should the new RigidBodyControls be added through code with Minie in the classpath?
That should work.
However please be aware: there's no efficient solution for porting serialized mesh collision shapes between different platforms. This relates to how Minie solves https://github.com/jMonkeyEngine/jmonkeyengine/issues/254 . Here's what's going on:
- When you create a
MeshCollisionShape, Bullet usually generates a BVH (acceleration data structure) for it. For large meshes, this takes a long time. - When Minie serializes the shape, it writes the BVH data. However this data is platform specific: last I checked, data generated on Windows won't work on Linux. So during serialization, Minie also writes the platform (as in
JmeSystem.getPlatform()) to the J3O or XML. - When loading the model from J3O or XML, Minie compares the stored platform to the current platform. If they don't match, it discards the stored BVH and generates a new one.
So everything should work. But for best efficiency, you should generate the J3O on the platform where you expect to use it.
Come to think of it, perhaps we don't need to add the RBC's before-hand, now that those lines mentioned above are removed. I'll double-check. And in that case, the plugin can add them, and the platform issue won't come into play either.
In theory, you don't need something special with Minie on the classpath, since it should be shipped with that SDK version anyway. But yeah, if it's only very platform specific, we may as well create the RBCs during runtime then. I guess we still do need RBCs though for obvious reasons.
Edit:
This is the first time in 4 years that the issue has arisen. I suspect that, in 90% of the cases, the correct solution would be to re-do the conversion from Blender (or glTF) as you've proposed here.
For the SDK, this is also luckily not a problem, but I wonder how more artist oriented teams would do that, say when they design their scene with the Scene Composer and drop in rigid body controls there, instead of like having some gltf -> j3o toolchain that also sets up stuff that is not represented by gltf. But if no-one complained, i'm only going off on hypothetical use cases here
JME is charitably described as a code-centric, developer-friendly engine. I'm guessing artist-oriented teams favor artist-friendly engines over JME. That may explain why we don't hear from such teams.
In my opinion, making JME more artist-friendly would be a very good thing. So I'm glad people are working on Scene Composer.
I was going to make the plugin do it, but then didn't feel comfortable with it saving the result. If it's not a big issue, I'll generate the RBC before-hand, but I guess preferably it should be done during installation.
Yeah, I guess we can easily generate the RBCs beforehand, especially if that happenes implicitly all the time if you don't have the right plattform
Don't know if this has the correct RigidBodyControl's, but at least it's different!