tzaeschke / ode4j Goto Github PK

The old homepage should be migrated to GitHub, possibly merging it with the Wiki.

This should also fix some warnings (e.g. @SafeVargs)

Found this after comparing ode4j behaviour with VRep (using the C implementation of ODE):
I was applying an off-cenetered force to a body, but it caused a VERY slow increase in angular momentum compared to VRep.
So I checked the ode4j source code and found this line:
https://github.com/tzaeschke/ode4j/blob/master/core/src/main/java/org/ode4j/ode/internal/DxQuickStep.java#L1886

Which scales the whole tacc vector three times. Compare to the C++ version (quickstep.cpp):

for (dxBody *const *bodycurr = body; bodycurr != bodyend; invIrow += 12, bodycurr++) {
    dxBody *b = *bodycurr;
    dReal body_invMass_mul_stepsize = stepsize * b->invMass;
    for (unsigned int j=0; j<3; j++) {
        b->lvel[j] += body_invMass_mul_stepsize * b->facc[j];
        b->tacc[j] *= stepsize;
    }
    dMultiplyAdd0_331 (b->avel, invIrow, b->tacc);
}

I tried a simple test to see if collision is detected between an instance of DRay and DPlane, but to no avail. So I perused the code and cannot find where DRay functions are called for collision detect. I would appreciate any help.

Jeff

While I can do...

	body.asInstanceOf[org.ode4j.ode.internal.DxBody].dBodyDestroy()
	geom.asInstanceOf[org.ode4j.ode.internal.DxGeom].dGeomDestroy()

wouldn't these be better in the helper object - or even in the body and geom front end classes

DemoPlane2D behaves weird when using world.step(). Using world.quickStep() is fine. The problem occurs only in ode4j, not in ODE for C/C++.

Weird: the red block gets a high spinning rate, sometimes jumps around and the are errors on the console:

ODE Message 3: LCP internal error, s <= 0 (s=-2.3257e+01)

Quickstep may sometimes cause an NPE:

java.lang.NullPointerException
    at org.ode4j.ode.internal.DxQuickStep.dxQuickStepIsland_Stage1(DxQuickStep.java:1323)
    at org.ode4j.ode.internal.DxQuickStep.dxQuickStepIsland(DxQuickStep.java:1006)
    at org.ode4j.ode.internal.DxQuickStep.run(DxQuickStep.java:2037)
    at org.ode4j.ode.internal.processmem.DxIslandsProcessingCallContext.ThreadedProcessIslandStepper(DxIslandsProcessingCallContext.java:235)
    at org.ode4j.ode.internal.processmem.DxIslandsProcessingCallContext.access$3(DxIslandsProcessingCallContext.java:233)
    at org.ode4j.ode.internal.processmem.DxIslandsProcessingCallContext$4.run(DxIslandsProcessingCallContext.java:228)
    at org.ode4j.ode.threading.ThreadingTemplates$dxThreadedJobInfo.InvokeCallFunction(ThreadingImplTemplates.java:388)
    at org.ode4j.ode.threading.ThreadingTemplates$dxtemplateJobListSelfHandlertemplate.PerformJobProcessingSession(ThreadingImplTemplates.java:1105)
    at org.ode4j.ode.threading.ThreadingTemplates$dxtemplateJobListSelfHandlertemplate.PerformJobProcessingUntilExhaustion(ThreadingImplTemplates.java:1084)
    at org.ode4j.ode.threading.ThreadingTemplates$dxtemplateJobListSelfHandlertemplate.PrepareForWaitingAJobCompletion(ThreadingImplTemplates.java:1056)
    at org.ode4j.ode.threading.ThreadingTemplates$dxtemplateThreadingImplementation.WaitJobCompletion(ThreadingImplTemplates.java:1403)
    at org.ode4j.ode.threading.ThreadingImpl_H$dxSelfThreadedThreading.WaitJobCompletion(ThreadingImpl_H.java:1)
    at org.ode4j.ode.threading.DxThreadingImplementation$10.run(DxThreadingImplementation.java:342)
    at org.ode4j.ode.threading.DxThreadingBase.WaitThreadedCallExclusively(DxThreadingBase.java:179)
    at org.ode4j.ode.internal.DxWorld.dxProcessIslands(DxWorld.java:844)
    at org.ode4j.ode.internal.DxWorld.dWorldQuickStep(DxWorld.java:472)
    at org.ode4j.ode.internal.DxWorld.quickStep(DxWorld.java:1131)
    at org.ode4j.tests.TestIssue_0018.simLoop(TestIssue_0018.java:72)
    at org.ode4j.tests.TestIssue_0018.step(TestIssue_0018.java:192)
    at org.ode4j.tests.TestIssue_0018.test(TestIssue_0018.java:227)

lwjgl 2.x does not work well with newer Java version. Investigate lwjgl 3.

ODE uses by default the OPCODE trimesh collider. ode4j has currently only the GIMPACT collider which is a secondary option in ODE.

For more compatibility and to add flexibility, it would be nice to support OPCODE as well.

Remove ENABLE_CONTACT_SORTING once the following has been fixed:
https://bitbucket.org/odedevs/ode/issue/36/fix-gimpact-contacts-handling

From the comments that were made, I understood that we can compile ode4j to Java 7. But I'm having trouble compiling to Java 7. Can someone explain how with the new changes in place?

There are two issues, both point to a (two?) problems in the collider:

• Letting DemoCrash sit still for a few second will occasionally show the box stack becoming "active", as if one of the boxes moved slightly or was brushed by another object.
• Choosing ReorderingMethod.REORDERING_METHOD__DONT_REORDER in DxQuickStep line 147 causes DemoCrash to become unstable.

Both could be a good starting point for debugging a problem in DxQuickStep.

I believe we need a forum or something similar.
There are many options:

• Google Forums
• StackOverflow
• Anything else?

What is you opinion on these options? Any other proposals?
Google forums would be a classical forums to discuss topics in length. However Stackoverflow would make it easier to cross-link related topics (they also list related topics in the sidebar).
What do you think?

After setting up a DTriCallback, I found that it does nothing. Looking into the code, it's never called.

Hi,

It looks like the following assertion is not correct:
public void dGeomSetBody (DxBody b)
{
//dAASSERT (g);
dUASSERT (b == null || (_gflags & GEOM_PLACEABLE) == 0,
"geom must be placeable");

Instead it should be:
dUASSERT (b == null || (_gflags & GEOM_PLACEABLE) != 0,

Respective line of code in ODE:

dUASSERT (b == NULL || (g->gflags & GEOM_PLACEABLE),"geom must be placeable");

Also look into disabling logging more easily.

What is the preferred way of citing ODE4J?

Thank you,
Kyle

For HiDPI screens all demos are rendered in the lower left quarter of the screen:

The PR: #125 fixes this issue for Java part

As mentioned in issue #35, ode4j appears to allocate significant amounts of memory in some situations/systems ("3-4 MB/s").

The problem may be in the stepper which allocates large arrays for the solver during each step.

A solution could involve array pooling.

ode4j now builds with Java 9.
Currently, the source code (except modularization/Maven) still builds with Java 7. The point is that Java 7 is compatible with most Android versions, whereas Java 9 is not. The poll is intended to be closed on April 30th 2018.

Question/Poll, what is your take on this?

1. I'm in favor of moving to Java 9 source code?
2. I'm undecided / don't care
3. I require Java 7 source code to build for Android (or other reasons)

Please put your opinion in the comments, thank you!

Move to Java 8.

This should be easy, and if Android compatibility is "fine" we may to Java 9 or later soon afterwards (i.e. before the next major release).

See also #62..

Can you remove slf4j dependency from core?

As I see it used only in ErrorHdl class.
Can you replace it with some interface, that can be implemented externaly, like as plugin?
For example you can create some global object like Log, which has static variable imp for storing logging interface implementation. This object may be used internaly in odej4. And users can implement any loggers that they like. For default implementation in core, can be simple System.out.println

slf4j internally using reflection, so I can't use ode4j with teavm.
Is odej4 using reflection?

Also I think the fewer dependencies the better.

DxSpace.dSpaceCollide2 line 260 should iterator over s2 instead of s1

More out of curiosity than anything else, has anyone compared ode4j to jBullet?

There is PAL (http://www.adrianboeing.com/pal/index.html) which has some comparisons of C/C++ engines. However, I've seen a number of folks using jBullet these days, and was just curious if there is any comparative information out there.

I recall that there were some arguments that ODE was better than Bullet for realistic physical simulation, which is what brought me to ode4j in the first place (for robots).

Boxes sometimes fall very slow or not at all:

• DemoTrimesh: If the fourth dropped body is a Box, it will land on an edge and then fall very slowly
• DemoHeightfield: If the first item is a box, it will land on it's edge and just stay there until it is knocked over by another item.

In summary, box collision is recognized just fine, but the resulting forces on the box appear to be much too weak.

The DemoTrimesh problem is reproducible in ODE (16.3), the DemoHeightfield problem is not reproducible in ODE.

Preliminary findings

The DemoHeightfield problem goes away when using the ODE/C++ order for randomized position (x,y,z). Using the Java order in C++ does not reproduce the problem.

Even with identical starting positions, ODE and ode4j show slightly different initial contact positions. Also, ode4j reports around 803/806 collisions before the second contact appears while ODE shows only 527/529.
When counting only contact, for ode4j the 22nd contact is the first double-contact, while for ODE it is the 18th.

Hello,
I have looked over your port of ODE and I can see that you don't prevent from garbage collection.

In documentation I can read:
ode4j is in certain cases faster that ODE. I have investigated this only briefly, but I have the impression that Java can draw its advantage from using the garbage collector for arrays. This means de-allocation in Java occurs in a 2nd thread in parallel to computations, while in C/C++ de-allocation (which is expensive) occurs in the main thread.

what platforms have you considered? I think you weren't looking at Android or Web (after compilation to JavaScript using GWT, that's what libgdx does). Anyhow, allocation (of array of primities) itself is in fact fast but it's not the case for deallocation. Garbage collection takes CPU cycles and it's definetely not costless, especially when some more memory is allocated AFTER your array to be deallocated. 2nd thread does not help much since it causes memory fragmentation.

But enough about array of primitives. I see a problem about instantiating DContact too much.

private DNearCallback onCollisionCallback = new DNearCallback() {
    final int N = 100;
    DContactBuffer contacts = new DContactBuffer(N);

    @Override
    public void call(Object data, DGeom o1, DGeom o2) {
        int n = OdeHelper.collide(o1, o2, N, contacts.getGeomBuffer());
        for (int i = 0; i < n; ++i) {
            DContact contact = contacts.get(i);
            DJoint c = OdeHelper.createContactJoint(physics, contactGroup, contact);
            c.attach(contact.geom.g1.getBody(), contact.geom.g2.getBody());
        }
    }
}

I wanted to create contacts once but it's buggy, seems I can't reuse those DContact objects, so I have to allocate contacts every time a potential collision occurs (of course, N number would be smaller).Objects in DContactGeomBuffer could be reused but the class is final so I can't do much without modifying library.

I'd like to introduce possibility of reusing DContact/DContactGeom objects. Are those stored somewhere or just used for step simulation and forgotten?

• internal version identifier is still on 0.4.0
• DQuaternion.inverse() has wrong name

Is there a way to set ode4j to use a y-up orientation? @tzaeschke

Removing the first or a middle object may fail, see TestIssue0019_BodyRemove.

bodyRemove is called for example from DGeom.destroy().

DVector3.cross() always returns 0

The ASSERT in the Common class all check for arg==null. However, only certain cases verify (Boolean)arg == false. No method checks for (Integer)arg == 0.
Moreover, many checks are redundant in Java because the code in the proxomity of the check would trivially throw an NPE.

Issue #8 is fixed, but to avoid regressions, a test harness would be nice. I attempted a test harness, but it fails to reproduce the problem (TestIssue8_Gimpact.java).

public class ODEPhysicsTests {
	@Test
	public void planeGetQuaternionFail() {
		OdeHelper.initODE2(0);
		DSpace space = OdeHelper.createHashSpace(null);
		DPlane plane = OdeHelper.createPlane(space,0,0,1,0);
		DQuaternionC q = plane.getQuaternion();
	}
}

if getQuaternion exists for all DGeom it should succeed for all DGeom or documented that it is known to fail deliberately. Because DGeom/DPlane are interfaces what's going on behind (in DxPlane?) is invisible to me.

Remove @brief, @section,@InGroup, @group, ...
Fix bad @param declarations

When running the demos, instrumentation or debug code is outputting. Don't know if that were the author's intentions. It is showing what look like to be time duration output.

Jeff

setTorques() can cause an NPE:

  DAMotorJoint j = OdeHelper.createAMotorJoint(world);
  j.setNumAxes(3);
  j.addTorques( 1, 2, 3 );

The additional features should have factory methods and possibly some documentation on the WIki.
This should allow removing direct references to Dx...Joints from the Ragdoll demo

Hi, in my WalkOnTheMoon Applet, the observer is a sphere object.
Unfortunately, if I do not set damping on the observer, it can happen,
that he falls through the terrain. I can help fix this, but I need to know,
which files are to be touched.
Sincerely
Thorsten

This shouldn't be hard. Just create new ODE class with OdeHelper functions. Internally very few things are static that need to be migrated to instances.

Android supports Java 7 since Android KitKat (4.4 / buildToolsVersion 19).
However, maybe we should not switch to soon, because of legacy Androids

What can I do (in general) to improve these types of collisions? I have a vehicle and a pilot that will sit inside the vehicle. The cockpit in the vehicle is open so the pilot is visible and I plan to animate the pilot while inside the vehicle. But it should have a "ragdoll" behavior when colliding with other objects. So I can't use a box geom for the vehicle or it will be difficult to place the pilot inside the vehicle.

Thanks!
Jeff

Currently the according wiki page only describes how to use maven for the 'core' artifact.

The problem with importing the whole project is to get the import of native libraries to work, which are used by lwjgl.
For eclipse there is a special Maven-native plug-in, but seems to collide with the hierarchical project structure of ode4j.

MTJ/MTJ-n:
https://github.com/fommil/matrix-toolkits-java

EJML:
http://code.google.com/p/efficient-java-matrix-library/

Comparison:
https://code.google.com/p/java-matrix-benchmark/wiki/RuntimeCorei7v2600_2013_10

Also, any inclusion of such libraries should consider that ODE partly takes special precautions to improve mathematical instability.

The method DxJointTransmission.dJointSetTransmissionAxis2(...) performs an assignment instead of equality check.

dUASSERT(mode = TRANSMISSION.dTransmissionIntersectingAxes, "can't set individual axes in current mode" );
should be changed to:
dUASSERT(mode == TRANSMISSION.dTransmissionIntersectingAxes, "can't set individual axes in current mode" );