search

stephengold / Libbulletjme

A JNI interface to Bullet Physics and V-HACD
https://stephengold.github.io/Libbulletjme/lbj-en/English/overview.html
Other
84 stars 10 forks source link

Please revise your math classes to not be final. (Compatibility with other Math APIs) #26

Closed SkyAphid closed 7 months ago

SkyAphid commented 9 months ago

Hello,

I'm trying to integrate this API into an LWJGL3 project. With LWJGL3, we often use JOML, which is an extremely powerful math API. Unfortunately, they also use the same naming scheme (Vector3f, etc). My plan was to make a wrapper class for your Vector class to hide this similarity, but you guys have made your math classes final, which is a tad inconvenient. Is there any way you can consider this change in future iterations? For now I'll pull the project myself and make the changes.

Thank you!

stephengold commented 9 months ago

Thank you for getting in touch.

The com.jme3.math classes (Matrix3f, Matrix4f, Quaternion, Transform, Vector3f) are declared final because they were extracted from JMonkeyEngine, where they are final. I don't know any reason they must be final, but neither do I want to diverge further from JMonkeyEngine without a compelling reason.

Despite the final constraint, it's easy to use Libbulletjme with JOML---see LbjExamples and VSport. To avoid ambiguity, these projects occasionally qualify class names (for example, com.jme3.math.Vector3f or org.joml.Vector3f). Perhaps your project could do the same.

Leaving this open for now, in case a compelling reason emerges.

SkyAphid commented 9 months ago

If I'm not mistaken, the reason why Libbulletjme is separate from Minie is because it's meant to not be so reliant on jMonkeyEngine? We're trying to attach this to our own game engine since there's not really any good physics solutions available in Java. Maybe I'm just mistaken and Minie the one that's supposed to be more standalone?

I appreciate the quick response!

stephengold commented 9 months ago

Minie has JMonkeyEngine dependencies and Libbulletjme does not.

In order to reduce the maintenance burden, Minie and Libbulletjme share a lot of source code. To make this work, certain source code from the jme3-core and Heart libraries has been embedded in Libbulletjme. The com.jme3.math package falls into that category.

SkyAphid commented 9 months ago

Okay! Got it. I really appreciate the help! We should be able to build a wrapper around this to work with our engine, so all of the clarifications you provided are very helpful. Have a great day!

stephengold commented 9 months ago

off-topic question for @SkyAphid: Would it be appropriate to list NOKORI.WARE as one of the "Projects using Libbulletjme" in the "Project Links" sidebar of the Libbulletjme website?

SkyAphid commented 9 months ago

Well, we just started looking into it the day that I made this question. We have a lot of work to do when it comes to researching how this library works and making our own wrapper for it to integrate to our own game engine (We call it NNGINE, pronounced "engine", short for Nokori Engine). We'd be happy to be listed, we just need a bit more time to make sure that it's a good fit for us! I'll be sure to comment on here or send an email once we know for sure we'll be sticking with it.

stephengold commented 7 months ago

@SkyAphid any updates on NNGINE's physics?

SkyAphid commented 7 months ago

@stephengold Hi Stephen! Unfortunately, this library wasn't working with our project, so we've decided to stick with our implementation and just go forward with upgrading it. That said, it's a pretty cool API and we appreciate your help! The issues we had were more of a limitation with Bullet itself rather than your code, so no worries on that front either. Thank you again for your help!

stephengold commented 7 months ago

@SkyAphid You're welcome. Best of luck with your project!

stephengold commented 7 months ago

@SkyAphid I'm curious: could you briefly describe the limitation you encountered with Bullet? Perhaps it's something I could address in a future release...

stephengold commented 6 months ago

For the record, here's an unofficial explanation why the jme-core math classes are final:

https://hub.jmonkeyengine.org/t/wiki-why-shouldnt-you-remove-the-final-attribute-from-the-vector-and-quaternion-classes/47485

SkyAphid commented 6 months ago

@SkyAphid I'm curious: could you briefly describe the limitation you encountered with Bullet? Perhaps it's something I could address in a future release...

Hey! Sorry for the slow response.

The limitation was more of a limitation with Bullet itself than your Java bindings. We ended up using ode4J instead. Our world is "voxel based", similar to Minecraft in a way. Bullet simply couldn't handle us placing hundreds of thousands of block objects into its physics space. The math/final aspect I initially reported was easy to work around and wasn't a problem, so don't worry!

stephengold commented 6 months ago

@SkyAphid Thanks for the reply. Bullet has been used to simulate voxel-based worlds in the past, so I'm sure there's a workaround for the limitation you encountered.

The bottom line is that you found a physics solution for your project. I hope it works great for you, and I wish you every success!

YanisBDF commented 6 months ago

@SkyAphid I'm curious: could you briefly describe the limitation you encountered with Bullet? Perhaps it's something I could address in a future release...

Hey! Sorry for the slow response.

The limitation was more of a limitation with Bullet itself than your Java bindings. We ended up using ode4J instead. Our world is "voxel based", similar to Minecraft in a way. Bullet simply couldn't handle us placing hundreds of thousands of block objects into its physics space. The math/final aspect I initially reported was easy to work around and wasn't a problem, so don't worry!

We actually made it work using Bullet for our Minecraft mod. I would like to have more details on your implementation if possible ?

stephengold commented 6 months ago

@YanisBDF Perhaps we need a SPORT demo showing the best practices for simulating physics in voxel-based worlds. A novice might be tempted to create millions of static, box-shaped rigid bodies.

I haven't looked closely at what DynamX does, but I assume it doesn't do that! Does it create a static rigid body for each chunk?