sheldonrobinson / jinngine Goto Github PK

What steps will reproduce the problem?
1. make a hinge joint
2. set the limits to [0;PI]
3. stretch the joint to the PI limit side.

What is the expected output? What do you see instead?
The constraint should be enforced. Instead, a blowup is observed, the joint 
seems to be accelerating in the wrong direction


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. run demo1
2. create situations where an edge of a box is pushing some other geometry
3. The it is sometimes possible to create severe penetrations, apparently
with out any correction being activated

This is most likely caused by the contact determination, since it is here
observed by edge-* cases. Could be caused by wrong penetration depth
estimation by the EPA

Hi,

I'm playing with jinngine svn revision 182, on windows.

Context & Scenario:
I create a convex hull of a centered cube of size 2.
To reproduce the defect check the attached file TestCase.

What's happening:
* When trying to draw the hull, I call ConvexHull.getFaces() and get only 
Vector3(Nan,Nan,Nan). I would have expected real coordinate.

* I get a mass == 0., and I would have expected a mass > 0.

First analysis:
The issue comes from the mass calculation, that computes totalmass=0
Then things goes wrong computing the center of mass (Nan,Nan,Nan) 
(MassProperties.java:30)
Finally the hull vertex are translated by (Nan,Nan,Nan) which clears every 
coordinates.

Sorry, I can't analyze further because but I don't understand the algorithm...

Thanks, and good luck

The implementation, as is, does not take into account that when splitting a
given triangle, the polytope may no longer be convex, due to the presence
of other triangle faces, whose supporting plane is "beneath" the new
splitting point. This is an error that results from naively extending EPA
from 2d to 3d, where in 2d, this problem doesn't exist. 

Hi,
Purpose of code changes on this branch:
I changed a loot of files to remove calls to deprecated methods.
All tests are OK.

Pay attention to isEpsilon which is a week version of different from 
abs().lessThan(epsilon).

Thanks

External forces are missing in the constraint b vector, causing animaiton
artifacts

Purpose of code changes on this branch:

Preliminary test of the functionality. 

When reviewing my code changes, please focus on:

Using the new method Body.addGeoemetryIncremental() to add geometries to 
bodies. Check that it works as expected in 3. party projects.


After the review, I'll ... continue working in geometry_rework

If a constraint is removed from a deactivated group of bodies, the entire 
group must be activated to account for potentially changed constraint forces 
in the group

What steps will reproduce the problem?
1. Run the demo.
2. Play with the round object.
3. Once it starts to vibrate leave it for about 5min.

What is the expected output? What do you see instead?
Object should stand still. It should not move or vibrate without stop.

What version of the product are you using? On what operating system?
http://mo.silcowitz.dk/demo2-0.7.jnlp WindowsXP Java6-u16.

Please provide any additional information below.
Think this is a very low priority problem. I suppose it's just the model's
fault. So just F.Y.I

What steps will reproduce the problem?
1. Create Java 1.6 project in eclipse with Class from TriggerExample
2. Add jinngine.0.8.jar to buildpath
3. Run program

What is the expected output? What do you see instead?

Expected Output: 
Demo program runs and shows animation

Actual Output:
Demo program quits with NullpointerException:

Exception in thread "main" java.lang.NullPointerException
    at jinngine.util.HashMapComponentGraph$6.<init>(HashMapComponentGraph.java:952)
    at jinngine.util.HashMapComponentGraph.getConnectedEdges(HashMapComponentGraph.java:951)
    at jinngine.physics.DefaultScene.getConstraints(DefaultScene.java:491)
    at jinngine.physics.ContactTrigger.setup(ContactTrigger.java:140)
    at jinngine.physics.DefaultScene.addTrigger(DefaultScene.java:474)
    at TestTrigger.<init>(TestTrigger.java:67)
    at TestTrigger.main(TestTrigger.java:95)

What version of the product are you using? On what operating system?
jinngine.0.8.jar

Example Code from: 
http://code.google.com/p/jinngine/source/browse/trunk/jinngine.examples/src/jinn
gine/examples/TriggerExample.java

Eclipse Helios
Java 1.6
Ubuntu Precise

This is an initial strategy to handle trimesh geometry in a general manner 

It is important for the library to be able to do efficient ray-casting
against multiple objects

Hi,

The sample create a convex hull made of 270 vertex. The vertex list contains 
duplicates. I create 57 convex hull of this type to build a body.

1. Download the attached test case
2. Run the test case

The computation takes a long time which is surprising.
Do you know why ? Is there a way to improve performances ?

Thanks for your help !

There is a need to do exhaustive testing of this vital algorithm.
Especially the underlaying simplex solver has some uncleared issues about
handling inaccurate determinant calculations. This should be cleared up.

for instance, a drawing that illustrates the meaning of interaction point
and normal would be great

Hi,

I delivered a Matrix3 & Matrix4 proposal. 
Plus paranoiac unit test of these two classes.

There are not lot of impact on Jinngine code, but a double check is welcome.

Documentation still remains to be done.

After the review, I'll merge this branch into /trunk

Bye

Hi, 
  I come back with a new proposal. What do you think of this new implementation ? Every feedbacks are welcome.

Purpose of code changes on this branch:
I wrote a new class to compute mass center, mass & inertia matrix.
It is fast, and look accurate on the two test cases : a box and a sphere. 

This calculation helps a my project by reducing loading time.

When reviewing my code changes, please focus on:
The implementation is a port of a C program, plus a Newell’s normal 
calculation method. Unfortunately the algorithm is not well documented.

Best would be to find new test cases.

After the review, I'll merge this branch into:
/trunk

Purpose of code changes on this branch:
I've written some updates to the collision detection system and the contact 
point generation. 

When reviewing my code changes, please focus on:
Review of the code is not explicitly necessary, but i'd like if to hear how the 
CapsuleExample works out. Maybe play around with the shapes and see if there 
are some weird things going on.  

After the review, I'll merge this branch into:
/trunk

Sometimes Handler.separation is called with a Geometry pair that has never
been reported using Handler.overlap. 

A configuration setup will not result in the same outcome when simulated twice. 
This is most likely caused by undefined iteration order in Maps. 

Purpose of code changes on this branch:
To enable handling of capsule shapes. This means that changes are made in some 
places, such that sphere swept shapes are now handled indirectly by support 
maps and by ray-casting.  

When reviewing my code changes, please focus on:
It may be sufficient to run the CapsulesExamples file, and verify that it works 
as expected. For more detailed review, the are some critical changes to 
ORourke.java.

After the review, I'll merge this branch into:
/trunk

What steps will reproduce the problem?
1.In CapsuleExample
2.Add Sphere Geometry to the scene
3.Run the example

What is the expected output? What do you see instead?
Sphere passes through into Capsules.

What version of the product are you using? On what operating system?
r286 branch : geometry rework

Please provide any additional information below.
A Capsule with 0 length seems to be functionnal.

Currently there is no way of controlling this joint with motors or limits

Hi, 
ConvexHullPCS.java creates a new ConvexHull from a blender model. That contains 
57 collision shapes of the same kind.

Note that the Vertex list passed to ConvexHull constructor contains duplicates.

1. Download the testcase ConvexHullPCS.java
2. Add it to you local test cases
3. Run the test

The computation time is surprisingly high. Do you know why ?
Thanks for your help!

With the current project structure, creating a Netbeans project requires 
copying folders. The reason is that the 'src' and test packages need to be 
separate. So I was wondering if it would be possible to change the directory 
structure? Ideally would be a maven compatibly tree like:

jinngine/src/main/java
jinngine/src/test/java
and
jinngine.examples/src/main/java
jinngine.examples/src/test/java

Even just separate the test package would save some work after a 
checkout/update.

jinngine/src
jinngine/test


Thanks,
 Michael

The 2d convex intersection algorithm described by O'Rourke et. al. in 

"A new linear algorithm for intersecting convex polygons", Computer Graphics 
and Image Processing
Volume 19, Issue 4, August 1982, Pages 384-391

seems like a simple and efficient method for performing feature 
intersection. The algorithm should be implemented and tested as a 
replacement for the current brute force approach in 
SupportMapContactGenerator.java