https://github.com/formula1/jbox2d/blob/d8b11344998ffdf41ffa3d9d3f37d3a6ed1cf22f/jbox2d-testbed/src/main/java/org/jbox2d/testbed/tests/DeadParticle.java

https://github.com/dmurph/jbox2d/blob/master/jbox2d-library/src/main/java/org/jbox2d/particle/ParticleSystem.java On lines 811 and 812 appears to be the first place the NaNs are showing up. This is caused by certian contacts having NaN weight and normal values.

What I know

1. The NaNs are associated primarilly with ParticleContacts
2. There is no NaNs on Creation of a Particle Contact
3. I cannot find where the particle contacts are updating other than indexes
4. Not all of the contacts are getting NaNs, usually there is a big chunk before and a smaller chunk after the area that has errors
5. There is a pattern (every 35 or every 5) which may be caused by just the fact that theres a pattern in the particles themselves. 6a) This pattern is effected by radius increasing the number of errors the smaller it is, and increasing the number contacts between each error contact 6b) maximum radius errors start to appear is around .4761904

in addition solveSpring also has a division by 0 problem, but I believe thats more due to the NaNs showing up than anything else.

I am playing around with the particles in jbox2d. At first glance it was working fine, creating a few particles for one group works and was running stable. Now i creating more groups, but joining it together and even with two groups, it gets unstable very fast - particles jump like crazy.

I am creating particles like this, doing nothing special and later render it using opengl. And yes i am creating particle groups for every lava tile in my map.

        world.setParticleRadius(0.1f * worldScale);
        world.setParticleDamping(0.2f);
        world.setParticleDensity(0.1f);

        ParticleGroup lastGroup = null;
        Vec2f tileFluidExt = new Vec2f(1f * worldScale * 0.5f, 1f * worldScale * 0.5f);
        Transform pxf = new Transform();
        pxf.setIdentity();
        CircleShape pshape = new CircleShape();
        for (int y = 0; y < tileFluidsLayer.getHeight(); y++) {
            for (int x = 0; x < tileFluidsLayer.getWidth()-1; x++) {
                int tile = tileFluidsLayer.getTile(x, y);
                if (tile == tileFluidsSet.getFirstId() + TileFluid.LAVA) {
                    final Vec2f fluidPos = createTilePosition(new Vec2f(x + 0.5f, y + 0.5f), tileFluidExt);
                    ParticleGroupDef pgf = new ParticleGroupDef();
                    pshape = new CircleShape();
                    pshape.m_radius = (1f - 0.2f) * worldScale;
                    pxf.setIdentity();
                    world.destroyParticlesInShape(pshape, pxf);
                    pgf.shape = pshape;
                    pgf.flags = ParticleType.b2_viscousParticle;
                    pgf.position.set(fluidPos.getX(), fluidPos.getY());
                    ParticleGroup newGroup = world.createParticleGroup(pgf);
                    if (lastGroup != null) {
                        world.joinParticleGroups(lastGroup, newGroup);
                    }
                    lastGroup = newGroup;
                }
            }
        }

Lately, I have been concerned about the cross-platform capabilities of my program and thus added the strictfp tag to all float-calculating functions (except for rendering) and switched from using Math to StrictMath. This is not triggered by default as it made a fairly large difference on old systems, but now, my testing shows < 1% difference. It is difficult to allow the user to choose without using some Reflection madness.

weldjoints are soft which is good and this issue doesn't happen when all bodies are connected to eachother by weldjoints

But this issue is particularly relevant attempting to take advantage of a weldjoints softness

Reasoned Hypothesis -Collision is registered by the body a --passes collision information to body main -nobody else gets the memo (which is fine, everything will get figured out)

Next TimeStep -This may be where the issue is -main is in incorrect location according to body b --applys impulse to account for that -main is in incorrect location according to body c --applys impulse to account for that

Next Time step -main is in incorrect location according to body a --applys impulse to account for that

the loop begins

Possible Solution(s)

==Down the Chain== On impact -Solve velocities, if body b has Weldjoints -for(weldjoint w :body.jointList()) When Solving WeldJoints

this can be recreated with....

private Body function createGenericBody(float x, float y){ BodyDef bd = new BodyDef(); bd.bodytype = BodyType.DYNAMIC; bd.position.set(new Vec2(x,y)); Body b = wold.createBody(bd);

CircleShape c = new CircleShape(); c.setRadius(5);

FixtureDef fd = new FixtureDef(); fd.shape = c; fd.friction = .3; fd.density = 1;

}

public void createSwimmingWeldJoints(){

Body main = createGenericBody(0,100); Body a = createGenericBody(0,60); Body b = createGenericBody(40,100); Body c = createGenericBody(0,140);

WeldJointDef wjd =new WeldJointDef(); wjd.initialize(main, a, main.getPosition()); world.createJoint(wjd);

wjd =new WeldJointDef(); wjd.initialize(main, b, main.getPosition()); world.createJoint(wjd);

wjd =new WeldJointDef(); wjd.initialize(main, c, main.getPosition()); world.createJoint(wjd);

}

Settings.velocityThresold needs to be modifiable, as it is in other languages.

I needed that because my world has no gravity, and objects without friction and with full restitution. Having velocityThreshold caused my bodies to stick to walls.

I am trying to use body and joint to build robot and found that if 2 bodies are connected by 2 joint, revolutejoint, then this robot will move in a strange way. It will rotate by itself without any force or motors involved. But if the 2 bodies are just connected by 1 joint, then it is fine and the robot will just stay on the ground without any weird movements. I am not sure if this is an issue or reasonable in physics.

Here's the code mentioned in issue #43. I created a separate jbox2d-testbed-javafx project, to make it cleaner. But note there are some changes in jbox2d-testbed.

These are some small fixes for the TimeOfImpact class. I was experiencing occasional stalls in the main loop under certain circumstances. These changes seem to fix those.

I compared the TimeOfImpact class to the latest C++ Box2D source and ported some of the changes found there.

b83f937 is not based on the Box2D source and is probably the most important change here as it prevents a whole lot of useless loop iterations under certain conditions. If the root loop is exhausted (performs 50 iterations without reaching a solution) nothing will have changed in the enclosing loop (since neither t1 nor t2 will have changed), so the enclosing loop will continue looping and calculating the same thing without reaching a solution.

In the README it says: "If you've downloaded this an archive, you should find the built java jars in the 'target' directories of each project." But in the 2.3-BETA or 2.2.1 there is no target directory. If I download the 2.2.1 build from google code, there is a target directory.

Incorrect results when Particles are flagged as b2_colorMixingParticle:

Error: bytewise color-difference https://github.com/jbox2d/jbox2d/blob/master/jbox2d-library/src/main/java/org/jbox2d/particle/ParticleSystem.java#L1178

Fix: & 0xFF before subtraction

        int dr = (colorMixing256 * ((colorB.r & 0xFF) - (colorA.r & 0xFF))) >> 8;
        int dg = (colorMixing256 * ((colorB.g & 0xFF) - (colorA.g & 0xFF))) >> 8;
        int db = (colorMixing256 * ((colorB.b & 0xFF) - (colorA.b & 0xFF))) >> 8;
        int da = (colorMixing256 * ((colorB.a & 0xFF) - (colorA.a & 0xFF))) >> 8;

There is a spelling mistake on line 30. "the body origin, which may no coincide with the center of mass. However, to support dynamics we" should be changed to: "the body origin, which may not coincide with the center of mass. However, to support dynamics we"

When removing items from bubble-picker by using Jbox2d.

a source with a bug: https://github.com/tuxxon/Bubble-Picker

    Process: com.touchizen.bubblepicker, PID: 30187
    java.lang.AssertionError
        at org.jbox2d.collision.broadphase.DynamicTree.destroyProxy(DynamicTree.java:115)
        at org.jbox2d.collision.broadphase.BroadPhase.destroyProxy(BroadPhase.java:104)
        at org.jbox2d.dynamics.Fixture.destroyProxy(Fixture.java:314)
        at org.jbox2d.dynamics.World.destroyBody(World.java:344)
        at com.igalata.bubblepicker.physics.Engine.move(Engine.kt:66)
        at com.igalata.bubblepicker.rendering.PickerRenderer.onDrawFrame(PickerRenderer.kt:75)
        at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1571)
        at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1270)

More detail = https://stackoverflow.com/questions/65137339/when-removing-items-on-bubble-picker-the-following-errors-occur

Does anyone help me?

It seems like JBox2d is missing the API from liquidfun to apply a force to a ParticleGroup. How could I do it with the current JBox2D API? Alternatively, is there any workaround? If not, how would I go about adding support for this?

Thx.

This takes the code from the C++ particle solver that handles iterations and ports it to Java. It works in the cases that we are using it in, but I haven't tested it very broadly. It seems to follow the C++ code pretty closely, however.

Hello, could you please update maven repo with latest stable version? As I can see, maven repo contain 5-years old version.

Currently I'm trying to pull changes from jitpack, but I'm waiting more than hour and dependencies still not resolved. Have no idea what is going wrong there, but most probably I will pull repo as archive.

The version of the lib is 2.2.1.1. Can we create a polygonshape-world? Here is the constructor. World(Vec2 gravity) World(Vec2 gravity, IWorldPool pool) World(Vec2 gravity, IWorldPool argPool, BroadPhaseStrategy broadPhaseStrategy)

Show me a demo please. I'll appreciate it very much.