tzaeschke / ode4j Goto Github PK
View Code? Open in Web Editor NEWJava 3D Physics Engine & Library
License: GNU Lesser General Public License v2.1
Java 3D Physics Engine & Library
License: GNU Lesser General Public License v2.1
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.
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)
Android supports Java 7 since Android KitKat (4.4 / buildToolsVersion 19).
However, maybe we should not switch to soon, because of legacy Androids
For HiDPI screens all demos are rendered in the lower left quarter of the screen:
The PR: #125 fixes this issue for Java part
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.
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?
Please put your opinion in the comments, thank you!
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.
After setting up a DTriCallback
, I found that it does nothing. Looking into the code, it's never called.
I believe we need a forum or something similar.
There are many options:
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?
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
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" );
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..
Boxes sometimes fall very slow or not at all:
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.
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.
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);
}
Removing the first or a middle object may fail, see TestIssue0019_BodyRemove.
bodyRemove is called for example from DGeom.destroy().
Remove ENABLE_CONTACT_SORTING once the following has been fixed:
https://bitbucket.org/odedevs/ode/issue/36/fix-gimpact-contacts-handling
setTorques() can cause an NPE:
DAMotorJoint j = OdeHelper.createAMotorJoint(world);
j.setNumAxes(3);
j.addTorques( 1, 2, 3 );
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)
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
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.
Is there a way to set ode4j to use a y-up orientation? @tzaeschke
DVector3.cross() always returns 0
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");
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).
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
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
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?
Also look into disabling logging more easily.
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).
There are two issues, both point to a (two?) problems in the collider:
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.
lwjgl 2.x does not work well with newer Java version. Investigate lwjgl 3.
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.
When I look at a method in ODE4J I get (for example)
public interface DCylinder extends DGeom {
void setParams(double var1, double var3);
but in the original source I see
public interface DCylinder extends DGeom {
void setParams (double radius, double length);
which is way more informative. If I had source then maybe it would have kept radius
and `length?
Also where is it worth it for me to add method description comments so the API is more intuitive?
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.
DLCP.solve1()
has been translated incorrectly from C/C++ such that it may call FastColve.solveL1Straight
even when nC == 0
.
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.
This should also fix some warnings (e.g. @SafeVargs)
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?
DxSpace.dSpaceCollide2 line 260 should iterator over s2 instead of s1
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
What is the preferred way of citing ODE4J?
Thank you,
Kyle
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.
v0.5.3
Error message appears as "LCP internal error, s <= 0 (s=%.4f)"
in src/main/java/org/ode4j/ode/internal/ErrorHdl.java
I tried a version 0.5.4 with
public static void dDebug (int num, String msg, Object ... ap) {
// va_list ap;
// va_start (ap,msg);
if (debug_function != null) {
debug_function.call (num,msg,ap);
} else {
// changed here
logger.debug("ODE INTERNAL ERROR " + num + ": " + String.format(msg, ap));
}
// *((char *)0) = 0; ... commit SEGVicide
//abort();
throw new RuntimeException("#"+num + ": " + String.format(msg, ap));
}
but the error message came out the same. Perhaps I am failing to install the package?
The old homepage should be migrated to GitHub, possibly merging it with the Wiki.
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
It seems the module name for the core is just core
instead of org.ode
(as specified in the core module file).
It should be org.ode
or org.ode.core
.
Is this related to the module names specified in the pom?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.