Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replaces Raceway scene with one that opens in the SDK. Deleted redund… #308

Merged
merged 15 commits into from
Oct 7, 2022

Conversation

neph1
Copy link
Contributor

@neph1 neph1 commented Mar 18, 2022

…ant textures. Tested on master
Fixes #278

@tonihele
Copy link
Contributor

Nice nice.. I'll try to check this tomorrow

@MeFisto94
Copy link
Member

Once tested by @tonihele, it's good to be merged.
Thanks for helping us out, hopefully it also sparks some motivation in everyone else 🙂

@tonihele
Copy link
Contributor

Yeah, it opens which is a major step forward. But when I press Test vehicle the SDK just crashes :O

@tonihele
Copy link
Contributor

Probably
hs_err_pid3640.log

@tonihele
Copy link
Contributor

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.

@neph1
Copy link
Contributor Author

neph1 commented Mar 20, 2022 via email

@neph1
Copy link
Contributor Author

neph1 commented Mar 20, 2022

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)

@tonihele
Copy link
Contributor

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.

@neph1
Copy link
Contributor Author

neph1 commented Mar 24, 2022

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.

@tonihele tonihele added this to the 3.4 release milestone Apr 21, 2022
@tonihele
Copy link
Contributor

tonihele commented Apr 21, 2022

Just noticed that there is a ghost track also there, maybe some additional geometry that isn't really spot on:
image

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...

@neph1
Copy link
Contributor Author

neph1 commented Apr 23, 2022

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.

@MeFisto94
Copy link
Member

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?

@MeFisto94
Copy link
Member

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

@stephengold
Copy link
Member

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.

@MeFisto94
Copy link
Member

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.

@stephengold
Copy link
Member

If you want help converting old J3Os to work with Minie, I'm willing!

@neph1
Copy link
Contributor Author

neph1 commented May 2, 2022 via email

@MeFisto94
Copy link
Member

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?

@stephengold
Copy link
Member

stephengold commented May 2, 2022

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.

@neph1
Copy link
Contributor Author

neph1 commented May 10, 2022

Do I need to do anything? Should the new RigidBodyControls be added through code with Minie in the classpath?

@stephengold
Copy link
Member

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 jMonkeyEngine/jmonkeyengine#254 . Here's what's going on:

  1. When you create a MeshCollisionShape, Bullet usually generates a BVH (acceleration data structure) for it. For large meshes, this takes a long time.
  2. 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.
  3. 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.

@neph1
Copy link
Contributor Author

neph1 commented May 11, 2022

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.

@MeFisto94
Copy link
Member

MeFisto94 commented May 15, 2022

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

@stephengold
Copy link
Member

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.

@neph1
Copy link
Contributor Author

neph1 commented May 16, 2022

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.

@MeFisto94
Copy link
Member

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

@tonihele tonihele modified the milestones: 3.4 release, 3.5 release Aug 22, 2022
@neph1
Copy link
Contributor Author

neph1 commented Aug 25, 2022

Don't know if this has the correct RigidBodyControl's, but at least it's different!

track.getChild("Road").getControl(RigidBodyControl.class).setPhysicsRotation(new Quaternion().fromAngleAxis(FastMath.HALF_PI * 0.68f, Vector3f.UNIT_Y).toRotationMatrix());
if(track.getChild("Grass").getControl(RigidBodyControl.class) == null){
track.getChild("Grass").addControl(new RigidBodyControl());
track.getChild("Road").addControl(new RigidBodyControl());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we'd want individual if's here? Though that would look ugly and be broken use-cases, I guess.
If we know that the Raceway.j3o doesn't have any RBCs at all anymore (which is very likely, considering we don't have them in blender and probably it would need a gltf extension anyway), we can probably also remove the if clause.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I've added them manually to the j3o. So in that case the whole clause could be removed. Or should I remove them from the j3o and generate every time?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh. I mean if they'd be dynamically generated, then we'd probably get rid of the problem that caused #278.
Otherwise, we may have another breakage when/if physics is changing again.

I guess both ways are fine for now though, especially since you already had the work to add it as well.
Do you see any downsides with code adding them though? any tweeks?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're to keep the lines generating the RBC's (and keep the j3o with the RBC's) I think it would also be better to do a check first. Or how would it handle generating a new control if there already is one?

Cleanup; removed warnings, made a lot of lambdas, formatting
@neph1 neph1 merged commit ab1ebdd into jMonkeyEngine:master Oct 7, 2022
@neph1 neph1 deleted the 278-raceway branch May 6, 2023 07:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Vehicle editor crashes when opening it
4 participants