The Minie physics library

because its caused by “weight issue” so issue caused by other asset issue. but user friendly would be if it could skip this geoms like JME 3.3 anim do. :slight_smile:

1 Like

Since it’s important enough for you to open an issue at GitHub, I’ll certainly try to address it there.

1 Like

Just tried to move a copy of my project over to Minie and my base game works out of the box, so sweet, however there are changes to CharacterControl and BetterCharacter that break classes that extend them, I expected that there would probably be breakage, but it appears that a lot of it is due to removed “access” to values, in many instances they were made private without getters, I recently found a BetterCharacter based class that introduces implements stepHeight like CharacterControl to enable climbing of slopes, vanilla BetterCharacter had issues with that. Due to minie being in development, not knowing the reasoning for the changes and me being just a hobbyist, I am wary of making adjustments or forking the code to recreate the access, at least not blindly.

note my base game still work because the extended classes are only used in tests at presant

1 Like

To which private fields do the extending classes want access?

I think it might be best to understand why the changes were made at this stage, so here is the class in question, The more I understand the more I can fix without causing more issues

package hkr.start.actor;

import com.jme3.bullet.PhysicsSpace;
import com.jme3.bullet.collision.PhysicsRayTestResult;
import com.jme3.bullet.control.BetterCharacterControl;
import com.jme3.bullet.objects.PhysicsRigidBody;
import com.jme3.math.FastMath;
import com.jme3.math.Vector3f;
import java.util.List;

public class CharControl_HKR extends BetterCharacterControl{

    boolean tooSteep = false;
    boolean isWalkableStep = false;
    boolean helpingUpStep = false;
    
    float maxSlope = 85;
    float maxStepHeight = 2f;
    
    
    public CharControl_HKR(float radius, int height, int mass) 
    {
        this.radius = radius;
        this.height = height;
        this.mass = mass;
        this.rigidBody = new PhysicsRigidBody(getShape(), mass);
        //jumpForce = new Vector3f(0, mass * 5, 0);
        rigidBody.setAngularFactor(0);
    }
    
    
    @Override
    public void prePhysicsTick(PhysicsSpace space, float tpf) {
        super.prePhysicsTick(space, tpf);
        
        checkSlope();
        checkWalkableStep();
        
        System.out.println("TooSteep = "+tooSteep+", isWalkableStep = "+isWalkableStep);
        if(tooSteep && isWalkableStep)
        {
            rigidBody.setLinearVelocity(rigidBody.getLinearVelocity().add(0, 5, 0));
            helpingUpStep = true;
            return;
        }
        
        if(helpingUpStep)
        {
             helpingUpStep = false;
             rigidBody.setLinearVelocity(rigidBody.getLinearVelocity().setY(0));
        }
    
    }
    
    
    protected void checkSlope() {
        if (this.getWalkDirection().length() > 0) {
    
            List<PhysicsRayTestResult> results = space.rayTest(
                    rigidBody.getPhysicsLocation().add(0, 0.01f, 0),
                    rigidBody.getPhysicsLocation().add(
                            walkDirection.setY(0).normalize().mult(getFinalRadius())).add(0, 0.01f, 0));
            for (PhysicsRayTestResult physicsRayTestResult : results) {
                float angle = physicsRayTestResult
                        .getHitNormalLocal()
                        .normalize()
                        .angleBetween(
                                physicsRayTestResult.getHitNormalLocal()
                                        .setY(0).normalize());
    
                System.out.println(Math.abs(angle * FastMath.RAD_TO_DEG - 90));
    
                if (Math.abs(angle * FastMath.RAD_TO_DEG - 90) > maxSlope && !physicsRayTestResult.getCollisionObject().equals(rigidBody))
                {
                    tooSteep = true;
                    return;
                }
            }
    
        }
        tooSteep = false;
    
    }
    
    private void checkWalkableStep() {
        if (walkDirection.length() > 0) {
            if (tooSteep) {
    
                List <PhysicsRayTestResult> results = space
                        .rayTest(
                                rigidBody.getPhysicsLocation().add(0,
                                        maxStepHeight, 0),
                                rigidBody
                                        .getPhysicsLocation()
                                        .add(0, maxStepHeight, 0)
                                        .add(walkDirection.normalize().mult(
                                                getFinalRadius())));
    
                for (PhysicsRayTestResult physicsRayTestResult : results) {
                    isWalkableStep = false;
                    return;
                }
    
                isWalkableStep = true;
                return;
            }
        }
    
        isWalkableStep = false;
    }

   public Vector3f getPos()
   {
       return rigidBody.getPhysicsLocation().add(0, 0.01f, 0);
   }

   public Vector3f getDir()
   {
       return rigidBody.getPhysicsLocation().add(walkDirection.setY(0).normalize().mult(getFinalRadius())).add(0, 0.01f, 0);
   }

    public boolean isTooSteep() {
        return tooSteep;
    }
    
    
    public void setTooSteep(boolean tooSteep) {
        this.tooSteep = tooSteep;
    }
    
    
    public boolean isWalkableStep() {
        return isWalkableStep;
    }
    
    
    public void setWalkableStep(boolean isWalkableStep) {
        this.isWalkableStep = isWalkableStep;
    }
    
    
    public boolean isHelpingUpStep() {
        return helpingUpStep;
    }
    
    
    public void setHelpingUpStep(boolean helpingUpStep) {
        this.helpingUpStep = helpingUpStep;
    }
    
    
    public float getMaxSlope() {
        return maxSlope;
    }
    
    
    public void setMaxSlope(float maxSlope) {
        this.maxSlope = maxSlope;
    }
    
    
    public float getMaxStepHeight() {
        return maxStepHeight;
    }
    
    
    public void setMaxStepHeight(float maxStepHeight) {
        this.maxStepHeight = maxStepHeight;
    }
}
1 Like

I’ll investigate. Meanwhile: How to type code blocks

  1. The constructor should invoke the superclass constructor, like so:
    public CharControl_HKR(float radius, int height, int mass) {
        super(radius, height, mass);
    }
  1. To access the rigid body (in Minie), the subclass should use getRigidBody(), like so:
        PhysicsRigidBody rigidBody = getRigidBody();
        if (tooSteep && isWalkableStep) {
            rigidBody.setLinearVelocity(rigidBody.getLinearVelocity().add(0, 5, 0));
            helpingUpStep = true;
            return;
        }
  1. In Minie, getWalkDirection() requires a Vector3f argument. Unless you’re worried about generating garbage, you can pass null, like so:
        if (this.getWalkDirection(null).length() > 0) {
  1. To access the PhysicsSpace (in Minie), the subclass should use getPhysicsSpace(), like so:
                PhysicsSpace space = getPhysicsSpace();
                List<PhysicsRayTestResult> results = space.rayTest(
  1. In order to modify walkDirection, you’ll need to use the setter, like so:
    public Vector3f getDir() {
        PhysicsRigidBody rigidBody = getRigidBody();
        Vector3f walkDirection = getWalkDirection(null);
        Vector3f location = rigidBody.getPhysicsLocation().add(
                walkDirection.setY(0).normalize().mult(getFinalRadius())).add(0, 0.01f, 0);
        setWalkDirection(walkDirection);
        return location;
    }

That last assumes you intended to modify walkDirection in getDir(). If you didn’t, then Minie has revealed a potential bug in getDir().

yeah I remembered there being a function to post code, but could not find it, not here much anymore other than to search or ask for answers, so changes to the site often escape me
thanks for the answers otherwise…

1 Like

expand please

1 Like

In your version of getDir() you actually modify the walkDirection vector. Since it’s odd for a getter to actually manipulate data (ie: it’s doing more than just ‘get’), it might be a bug. sgold didn’t know so mentioned it.

In this case, because minie didn’t let you just stomp all over a poorly protected instance field, it points out a bug that was hiding in your code. (if it’s a bug and not done on purpose)

1 Like

thank you

1 Like

@sgold

just wanted to tell about Centos 7 (default yum repo) issue. On Centos 8 it build/work fine :slight_smile:

error Is about cloned Minie project build

see below(end of my post) error, i will just mark that Centos 7 is using GCC 4.8.5, while CXXABI_1.3.8 based on internet comment is since GCC 4.9

JME default bullet was working on Centos 7, so i belive its some of Minie addon into bullet C lib, right?

im not sure if this is important for you to have it working for Centos 7 tho, since there is now fresh Centos 8. and Centos like to have stable old versions anyway. But if you mind lower version a little, it could work on Centos 7 too :slight_smile:

if im not wrong, cxxabi-1-3-8 require bigger version than 4.8.5 GCC? 4.9 probably.

Task :MinieAssets:compileTestJava NO-SOURCE
Task :MinieAssets:processTestResources NO-SOURCE
Task :MinieAssets:testClasses UP-TO-DATE
Task :MinieAssets:test NO-SOURCE
Task :MinieAssets:check UP-TO-DATE
Task :MinieAssets:build

Task :MinieExamples:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

Task :MinieAssets:models FAILED
Exception in thread “main” java.lang.UnsatisfiedLinkError: /##############Minie/MinieAssets/libbulletjme.so: /lib64/libstdc++.so.6: version `CXXABI_1.3.8’ not found (required by /##########Minie/MinieAssets/libbulletjme.so)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at com.jme3.system.NativeLibraryLoader.loadNativeLibrary(NativeLibraryLoader.java:685)
at com.jme3.system.JmeDesktopSystem.initialize(JmeDesktopSystem.java:348)
at com.jme3.system.JmeDesktopSystem.newContext(JmeDesktopSystem.java:271)
at com.jme3.system.JmeSystem.newContext(JmeSystem.java:159)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:461)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:442)
at jme3utilities.minie.test.models.ImportCgms.main(ImportCgms.java:104)

FAILURE: Build failed with an exception.

  • What went wrong:
    Execution failed for task ‘:MinieAssets:models’.
    Process ‘command ‘/usr/local/jmonkeyplatform/jdk/bin/java’’ finished with non-zero exit value 1

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

  • Get more help at https://help.gradle.org/

BUILD FAILED in 10s

1 Like

Minie gets its native libraries from the Libbulletjme project. In particular, Minie v1.5.0 uses Libbulletjme v5.0.0 . The 64-bit Linux native library was built using GCC 5.4 on a xenial system:

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609

I don’t know much about the Linux kernel or its ABIs. Are you saying that SOs compiled with GCC 5.4 are incompatible with the Centos 7 distro?

1 Like

I don’t know much about the Linux kernel or its ABIs. Are you saying that SOs compiled with GCC 5.4 are incompatible with the Centos 7 distro?

seems so. lets look below again.

  • GCC 4.8.3: GLIBCXX_3.4.19, CXXABI_1.3.7
  • GCC 4.9.0: GLIBCXX_3.4.20, CXXABI_1.3.8

thats exectly difference of 1 version why centos 7 dont have it.

while you compile on GCC 5.4 im not sure why it use 1.3.8 not 1.3.9 based on it,

but i belive it is it.

Since centos-7 use GCC 4.8.5 and here below:

  • GCC 3.1.0: GLIBCPP_3.1, CXXABI_1
  • GCC 3.1.1: GLIBCPP_3.1, CXXABI_1
  • GCC 3.2.0: GLIBCPP_3.2, CXXABI_1.2
  • GCC 3.2.1: GLIBCPP_3.2.1, CXXABI_1.2
  • GCC 3.2.2: GLIBCPP_3.2.2, CXXABI_1.2
  • GCC 3.2.3: GLIBCPP_3.2.2, CXXABI_1.2
  • GCC 3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1
  • GCC 3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1
  • GCC 3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1
  • GCC 3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1
  • GCC 3.4.0: GLIBCXX_3.4, CXXABI_1.3
  • GCC 3.4.1: GLIBCXX_3.4.1, CXXABI_1.3
  • GCC 3.4.2: GLIBCXX_3.4.2
  • GCC 3.4.3: GLIBCXX_3.4.3
  • GCC 4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1
  • GCC 4.0.1: GLIBCXX_3.4.5
  • GCC 4.0.2: GLIBCXX_3.4.6
  • GCC 4.0.3: GLIBCXX_3.4.7
  • GCC 4.1.1: GLIBCXX_3.4.8
  • GCC 4.2.0: GLIBCXX_3.4.9
  • GCC 4.3.0: GLIBCXX_3.4.10, CXXABI_1.3.2
  • GCC 4.4.0: GLIBCXX_3.4.11, CXXABI_1.3.3
  • GCC 4.4.1: GLIBCXX_3.4.12, CXXABI_1.3.3
  • GCC 4.4.2: GLIBCXX_3.4.13, CXXABI_1.3.3
  • GCC 4.5.0: GLIBCXX_3.4.14, CXXABI_1.3.4
  • GCC 4.6.0: GLIBCXX_3.4.15, CXXABI_1.3.5
  • GCC 4.6.1: GLIBCXX_3.4.16, CXXABI_1.3.5
  • GCC 4.7.0: GLIBCXX_3.4.17, CXXABI_1.3.6
  • GCC 4.8.0: GLIBCXX_3.4.18, CXXABI_1.3.7
  • GCC 4.8.3: GLIBCXX_3.4.19, CXXABI_1.3.7
  • GCC 4.9.0: GLIBCXX_3.4.20, CXXABI_1.3.8
  • GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9
  • GCC 6.1.0: GLIBCXX_3.4.22, CXXABI_1.3.10
  • GCC 7.1.0: GLIBCXX_3.4.23, CXXABI_1.3.11
  • GCC 7.2.0: GLIBCXX_3.4.24, CXXABI_1.3.11
  • GCC 8.0.0: GLIBCXX_3.4.25, CXXABI_1.3.11
  • GCC 9.0.0: GLIBCXX_3.4.26, CXXABI_1.3.11

source:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Anyway im not sure if Centos 7 is that much important since there is Centos 8 now, but im sure many people still use it. If you will fix it, it would be nice, but i just let know.

I think all other distributions should be fine, because its Centos that like stable old versions.

Same as blender Beta 2.8 was unable to run on Centos 7(due to old libs) and needed compile it manually, and on Centos 8 there is no problem. We have both centos here, so if you could fix it anyway, then we can test it easly on both.

1 Like

I’ll try building with an older GCC toolchain then.

1 Like

Actually, it looks like I could use a modern GCC with -fabi-version=7.

1 Like

I have a fix ready for testing on Centos 7:

        git clone https://github.com/stephengold/Minie.git
        cd Minie
        git checkout -b latest 892204e0
        ./gradlew build
1 Like

there is still an issue on Centos 7:

$ git clone https://github.com/stephengold/Minie.git
Cloning into ‘Minie’…
remote: Enumerating objects: 2108, done.
remote: Counting objects: 100% (2108/2108), done.
remote: Compressing objects: 100% (917/917), done.
remote: Total 30617 (delta 968), reused 1854 (delta 772), pack-reused 28509
Receiving objects: 100% (30617/30617), 73.90 MiB | 34.30 MiB/s, done.
Resolving deltas: 100% (15109/15109), done.
$ cd Minie
[sara@localhost Minie]$ git checkout -b latest 892204e0
Switched to a new branch ‘latest’
[sara@localhost Minie]$ ./gradlew build

Welcome to Gradle 6.2.2!

Here are the highlights of this release:

  • Dependency checksum and signature verification
  • Shareable read-only dependency cache
  • Documentation links in deprecation messages

For more details see https://docs.gradle.org/6.2.2/release-notes.html

Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

Task :MinieLibrary:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

Task :DacWizard:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

Task :MinieExamples:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

Task :MinieAssets:models FAILED
Exception in thread “main” java.lang.UnsatisfiedLinkError: /#####/_TEST/Minie/MinieAssets/libbulletjme.so: /lib64/libstdc++.so.6: version `CXXABI_1.3.8’ not found (required by /#####/_TEST/Minie/MinieAssets/libbulletjme.so)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1946)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1828)
at java.lang.Runtime.load0(Runtime.java:810)
at java.lang.System.load(System.java:1088)
at com.jme3.system.NativeLibraryLoader.loadNativeLibrary(NativeLibraryLoader.java:685)
at com.jme3.system.JmeDesktopSystem.initialize(JmeDesktopSystem.java:348)
at com.jme3.system.JmeDesktopSystem.newContext(JmeDesktopSystem.java:271)
at com.jme3.system.JmeSystem.newContext(JmeSystem.java:159)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:461)
at com.jme3.app.LegacyApplication.start(LegacyApplication.java:442)
at jme3utilities.minie.test.models.ImportCgms.main(ImportCgms.java:104)

FAILURE: Build failed with an exception.

  • What went wrong:
    Execution failed for task ‘:MinieAssets:models’.

Process ‘command ‘/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64/bin/java’’ finished with non-zero exit value 1

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

  • Get more help at https://help.gradle.org

BUILD FAILED in 39s
33 actionable tasks: 32 executed, 1 up-to-date

1 Like

Thank you for testing and reporting back. I’ll study the documentation some more and hopefully come up with more ideas.

1 Like

Perhaps this Forum should have category for Minie, under “User Code & Projects” …

Edit: done!

5 Likes