Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (552)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  [odejava] Weird GeomTriMesh problems  (Read 9681 times)
0 Members and 1 Guest are viewing this topic.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #30 - Posted 2005-03-06 09:00:14 »

Umm...even more puzzeling...

I have a demo (from the jme site), a box doesn't pass through it, while a sphere does...It seems that if you have a flat trimesh (i.e a quad), OPCODE cannot detect the depth of intersection with spheres and so they just straight through...

I have also seen some better reliability from collisions if you pass onto the GeomTriMesh the normals of each of the triangles...

Just a little experimentation here and there...

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Ole Friis

Senior Newbie




Java rocks! Games are fun!


« Reply #31 - Posted 2005-03-09 17:02:34 »

Hi DP!

Thanks for the suggestions. However...

I tried creating boxes instead of spheres, in order to see how they interact with the trimeshes when they fall down. (You can do the same, just alter the createSphere method in my demo.) They interact in exactly the same way with the trimes as the spheres do. And even fall through _exactly_ the same trimeshes.

Setting the normals when creating the trimeshes makes no difference either. Exactly the same behaviour.

A posting on the ODE list looks exactly like this problem:

http://q12.org/pipermail/ode/2005-March/015300.html

However, it's hard to convince people that it's an ODE problem, as opposed to wrong usage of ODE:

http://q12.org/pipermail/ode/2005-March/015302.html

So perhaps there's an obvious mistake somewhere in my code, but I cannot find it. And I cannot find a way to make it even simpler than it is now :-)

Anyway, DP, thanks for your ideas and thoughts. Keep them coming, please ;-)

Ole
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #32 - Posted 2005-03-13 00:36:31 »

In the Odejava CarDemo, spheres used to be fine while the boxes would go straight though :-/

Have you tried reversing the winding on the triangles?  Make sure that your height (normally Y) is positive.

I managed to get my terrain working just by moving the whole lot up 100 units on the Y axis, and by trying different triangle windings.

I plan to update the Odejava natives soon with the latest from ODE CVS, perhaps we might see an improvement? We can only hope.

Will.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ole Friis

Senior Newbie




Java rocks! Games are fun!


« Reply #33 - Posted 2005-03-13 05:52:13 »

Hi William!

I've tried different windings of the triangles, and reversing the direction of the normals. Nothing changes the behaviour. I've also tried to translate all of my scenery to various other places to see if that made any change, but I haven't done that systematically, so there may be a chance there.

I tried to boil down my example to just a single static triangle and a single sphere falling down. The sphere falls down nicely, until it hits the triangle, and then my JVM crashes (a HotSpot error, referring to the native ODE trimesh collision function).

Anyway, before spending too much time on that, I think I'll just wait for the new release of the ODEJava natives. Thanks for taking your time to compile a new release of those!!

BTW, William, while compiling the new ODEJava natives, do you think you could spend a little time updating the Wiki page on how to compile them? I still haven't found the Makefile patch (probably because it has moved from the "contrib" folder to the real makefile?), and applying the dCylinder2 patch is not just a matter of following the instructions in the readme file in the "contrib/dCylinder2" folder, I found out. Just a thought, and something I would really appreciate :-)

Kind regards,
Ole
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #34 - Posted 2005-03-17 20:25:54 »

Hi, I didn't end up recompiling the natves as it turned out nothing had changed

I did however update the docs.

Will.

Offline harryk

Senior Newbie




Stone golems rock!


« Reply #35 - Posted 2005-04-04 07:24:37 »

Weird trimesh troubles indeed. These are my findings regarding this matter. My settings:
ODE v0.2.4.
I've tried both trimesh-sphere as well as trimesh-box.
Trimesh being a geom and sphere/box being a body falling towards the trimesh.
Gravity = -9.82y.

HashSpaces don't like trimeshes with a lot of triangles. I have a mesh with about 2900 triangles and collisions are not detected. However, if I reduce the number of triangles to about 600-700, the collisions are detected fine if vertex coordinates are positive. If coords are negative (especially y-coords), collisions are detected some times.

Simple spaces and quad spaces works with my 2900 triangle mesh, but only if vertex coordinates are positive. In that case, collisions are detected fine.

Anyone else experienced different results for different types of spaces? Could there be a partitioning error of some sort?

I'd like to try the same mesh in ODE to see if I get the same result as with odejava but I haven't got that running yet since I haven't got a .obj loader and I dont want to write one. Setting up the mesh in the source isn't really an option since it will take some 10 thousand lines of vertex and face data to set up the mesh Wink
Offline Ole Friis

Senior Newbie




Java rocks! Games are fun!


« Reply #36 - Posted 2005-04-04 16:12:22 »

Hi!

Fancy. Sounds a bit difficult to reproduce for the rest of us, though. I posted a simple example to this thread some time ago, which demonstrates severe problems in sphere-trimesh collision detection. Perhaps my problems are related to my OS (Fedora Core 3), my processor (an AMD Athlon), the version of Java (5.0, but I've also tried 1.4.2 which has the same behaviour), or the OdeJava version (newest from the archive, with newest natives, but the behavious is similar with newest OdeJava from the CVS, and also some older OdeJava and native versions from the archive). Or a programming error on my side, though nobody has been able to point it out.

I've tried to move the whole scene various combinations of 100 units along the X, Y, and Z axes. The result is weird: In no combination do all the spheres collide correctly, but each sphere changes collision behaviour in various positions.

Since I posted the sample program, I have not had the impression that anybody has tried to compile and run it, although this is a very quick excercise. This could be interesting. Therefore: Is everybody else seeing the same problem as I am, or is it just on my OS, processor, and Java version?

Ole
Offline harryk

Senior Newbie




Stone golems rock!


« Reply #37 - Posted 2005-04-04 18:24:18 »

I haven't tried your code since I'm not using Xith3d, but perhaps I'll give it a shot tomorrow. I'd really like to get trimesh-collision working reliable.

Stepsize is also a factor I think, as well as how fast the sphere or box is travelling towards the trimesh.

Lots of variables to play with to get this working Wink
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #38 - Posted 2005-04-04 19:40:46 »

Yes!  My terrain works just fine with SimpleSpace and QuadTreeSpace.  I guess HashSpace was my problem.  I'm using positive and negative x, y, and z coordinates with no problems (yet).

Edit:
It actually seems that I can use all-positive or all-negative z coordinates but not mixed positive and negative z coordinates.  Interesting but consistent with what other people are seeing...
Offline harryk

Senior Newbie




Stone golems rock!


« Reply #39 - Posted 2005-04-05 07:06:31 »

Ole, I tried your code now, and yes, only 4 spheres manage to collide properly. I tried moving the trimesh around and doing all sorts of things to it and eventually it did collide but the tuning seems really arbitrary. This is what I did in createRampGeom(..) to get them colliding (dont laugh).

 float moveX = 20f;
 float moveY = 0f;
 beforeLeft.add( new Point3f( moveX, moveY, 0f ));
 beforeRight.add( new Point3f(moveX, moveY, 0f ));
 afterLeft.add( new Point3f( moveX, moveY, 0f ));
 afterRight.add( new Point3f( moveX, moveY, 0f ));
 
 int scaleFactor = 2;
 beforeLeft.x = (int) beforeLeft.x *scaleFactor;
 beforeLeft.y = (int) beforeLeft.y *scaleFactor;
 beforeLeft.z = (int) beforeLeft.z *scaleFactor;
 
 afterLeft.x = (int) afterLeft.x *scaleFactor;
 afterLeft.y = (int) afterLeft.y *scaleFactor;
 afterLeft.z = (int) afterLeft.z *scaleFactor;

 beforeRight.x = (int) beforeRight.x *scaleFactor;
 beforeRight.y = (int) beforeRight.y *scaleFactor;
 beforeRight.z = (int) beforeRight.z *scaleFactor;
 
 afterRight.x = (int) afterRight.x *scaleFactor;
 afterRight.y = (int) afterRight.y *scaleFactor;
 afterRight.z = (int) afterRight.z *scaleFactor;

It didn't work with just vector.scale(scaleFactor) but it did work when I typecasted to int. Pretty obvious huh? Wink

I dont feel like I'm seeing a pattern here when the collision fails, rather it seems very arbitrary.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline harryk

Senior Newbie




Stone golems rock!


« Reply #40 - Posted 2005-04-06 06:31:06 »

I have a question regarding vertex stride in GeomTriMesh.java.
Shouldn't vertex stride be 12 instead of 3 since we're using float arrays for the vertex data? Changing the vertex stride to 12 and Ole's example suddenly works... better (but not perfect).

Edit: Okey, feel like I'm spamming this thread. Smiley
I discovered that if I do my own collision checking with dCollide (colliding every geom against each other manually), then I get contacts where the space-collision approach doesn't. I can't however, get dCollide to work with more allowed contacts than 1, probably since I'm not sure how big the skip-parameter should be.
If anyone is interested, I'll post my code.

Is there some bug in how trimeshes are added to spaces?
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #41 - Posted 2005-04-06 14:16:39 »

Which Space type are you using?  As noted above, there seem to be some problems with HashSpace.
Offline harryk

Senior Newbie




Stone golems rock!


« Reply #42 - Posted 2005-04-06 15:41:46 »

well, actually it was me who pointed out the trouble with HashSpaces Wink but there seems to be issues with SimpleSpaces and QuadSpaces as well, since changing the space-type in the code posted by Ole does not help at all.

Changing the vertex stride to 12 helps, but all sphere's are still not colliding.

Manually collision check all geoms against all other geoms and create the contacts and contactjoints really helps. All sphere-trimesh collisions are detected but I can't figure out how to get more than one contact per geom. If anyone can help with dCollide(...) I'll be grateful.
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #43 - Posted 2005-04-06 19:00:14 »

Sorry about that  Smiley  Your observation about Space types really helped me!

From the ODE user guide:

// as long as dReal == floats
dGeomTriMeshDataBuildSingle (TriMeshData,
       // Vertices
       Bodies[BodyIndex].VertexPositions,
       3*sizeof(dReal), (int) numVertices,
       // Faces
       Bodies[BodyIndex].TriangleIndices,
       (int) NumTriangles, 3*sizeof(unsigned int),
       // Normals
       Bodies[BodyIndex].FaceNormals);

So it looks like both the VertexStride and TriStride should be 12?  Have you tried changing both?  I find it difficult to believe GeomTriMesh would work at all if both values are actually wrong.  I'll play around with it today or tomorrow if I have time...

Edit:
fixed typo
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #44 - Posted 2005-04-06 19:39:15 »

Update:

GeomTriMesh seems to work really well with both VertexStride and TriStride set to 12.  It works with all three space types, but I haven't tried mixing positive and negative z coordinates.  This would sure explain some of the TriMesh weirdnesses.  I would like a few more people to confirm that things are better with this change (and agree that it is correct), and then I will commit it (or someone else can).
Offline gilead

Senior Newbie





« Reply #45 - Posted 2005-04-06 21:31:14 »

Quote
I would like a few more people to confirm that things are better with this change


Where can this version be downloaded from?
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #46 - Posted 2005-04-07 00:00:38 »

That's sort of a catch-22 Smiley  I think the best thing to do is grab the latest CVS from the Odejava project home page, change the 3s to 12s on lines 249, 253, 259, and 263 of GeomTriMesh.java, and then recompile the .jar.
Offline harryk

Senior Newbie




Stone golems rock!


« Reply #47 - Posted 2005-04-07 05:59:24 »

yeah, I agree that Tristride should probably also be 12. However, I get hotspot crashes for certain meshes after changing the stride parameters to 12 (I'm loading from .obj files). Not sure what to make of it.

And I still think there is some space-bug, since I'm still not getting all triangles to generate contacts using spaces.


# Java VM: Java HotSpot(TM) Client VM (1.5.0_01-b08 mixed mode)
# Problematic frame:
# C  [odejava.dll+0xc57e]

Stack: [0x00030000,0x00070000),  sp=0x0006f838,  free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [odejava.dll+0xc57e]
C  [odejava.dll+0xc941]
C  [odejava.dll+0x64f6d]
j  org.odejava.ode.Ode.dGeomTriMeshDataBuildSingle1(Lorg/odejava/ode/SWIGTYPE_p_dxTriMeshData;Lorg/odejava/ode/SWIGTYPE_p_float;IILorg/odejava/ode/SWIGTYPE_p_int;IILorg/odejava/ode/SWIGTYPE_p_float;)V+24
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #48 - Posted 2005-04-07 16:26:19 »

That's troubling...  I certainly don't want to commit a change that will break some people's apps.  However, I think this change is needed to make TriMeshs behave properly.  What to do?

I don't think there's a Space bug on the Odejava side, but there might well be one the ODE side.  Are your objects traveling at velocities great enough to cause tunneling effects?  I have noticed that TriMeshs are particularly susceptible to tunneling due to the lack of volume in the TriMesh planes.
Offline harryk

Senior Newbie




Stone golems rock!


« Reply #49 - Posted 2005-04-07 17:53:24 »

well, I'm modding the code example posted by Ole Friis earlier in this thread. A few spheres don't collide, even with the trimesh-loading changes. I also get different results if I add another geom to the space before the trimeshes. Not high velocities at all, only gravity -9.8 affecting the spheres.

Perhaps someone could try the code example and verify this as well.

Doing collisiontesting without spaces does work as noted earlier.
Offline Ole Friis

Senior Newbie




Java rocks! Games are fun!


« Reply #50 - Posted 2005-04-09 06:17:38 »

Hi!

You guys rock! Yes, by changing the 4 lines in GeomTriMesh.java, it almost works! Sometimes when I run the demo, all the collisions are detected, and no spheres go through the trimeshes. But sometimes two certain spheres pass through. It's got nothing to do with changing anything in the code, since I don't do that, I just run the demo again and again :-)

This behaviour does seem like a problem with some algorithm based on nondeterministic behaviour, just like I suppose a HashSpace is. (Though I haven't looked at the code, so I don't know if it actually does behave in a deterministic manner.)

I guess this is a big step towards getting rid of these trimesh problems. Let's hope somebody find out how to get rid of the last problems. (My girlfriend needs to use the computer this week-end, so I'm afraid I don't get that many chances at having a look at it...)

Anyway, thanks a lot to you people for the work so far!

Ole
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #51 - Posted 2005-04-11 14:48:07 »

harryk - what's the status of the native crash caused by the VertexStride and TriStride change?  

I would like to commit this, but not if it will break some standard code.
Offline harryk

Senior Newbie




Stone golems rock!


« Reply #52 - Posted 2005-04-12 04:36:43 »

I say submit! Smiley
I only had native crashes on one or two meshes, but most work great.
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #53 - Posted 2005-04-12 16:49:22 »

Done and done!
Offline irrisor

Junior Member





« Reply #54 - Posted 2005-05-01 06:56:04 »

I just fixed a bug concerning this:
The invocation of dGeomTriMeshDataBuildSingle and dGeomTriMeshDataBuildSingle1 with correct stride (12) caused crashes and strange collision behaviour here. I debugged into the natives and found ode to read beyond the limits of the vertice array. This was caused by the wrong VerticeCount - it must be vertices.length/3  !

So the correct invocation would be

Ode.dGeomTriMeshDataBuildSingle1(data, tmpVertices, 12,
                             vertices.length/3, tmpIndices, indices.length, 12, tmpNormals);

(this also explains why it kind of worked before changing to 12, too)

Additionally I have to mention that the value 12 is platform dependent - on a system where the floating point numbers are different size than 4 bytes everything will go wrong again.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #55 - Posted 2005-05-01 12:01:59 »

sorry to be naive, but on which OS is a float not 4 bytes?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline ewills

Junior Member




Java skeletal animation systems rock!


« Reply #56 - Posted 2005-05-01 16:26:37 »

The ODE user's guide says:

// as long as dReal == floats
dGeomTriMeshDataBuildSingle (TriMeshData,
       // Vertices
       Bodies[BodyIndex].VertexPositions,
       3*sizeof(dReal), (int) numVertices,
       // Faces
       Bodies[BodyIndex].TriangleIndices,
       (int) NumTriangles, 3*sizeof(unsigned int),
       // Normals
       Bodies[BodyIndex].FaceNormals);

So yes, I agree that the call wants the vertex count and not the number of vertex coordinates.  I'll commit this change as soon as I post this.

Also, I'm not aware of a Java equivalent to sizeof... any ideas?

Edit:
Thanks for debugging this, irrisor.

I committed the change and TriMeshs seem to be working really well.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #57 - Posted 2005-06-22 12:28:05 »

Sorry to bring this up again, but im having trouble with this...and none of the above seems to make a difference to it.

Its really strange, imagine 9 squares in a trimesh in a grid like manner (its part of a larger mesh btw). Each square is made up of 2 triangles...When i pass this mesh to ode, most of the triangles work fine, but some dont. The objects go straight through some of the triangles (esp the middle square's left triangle). Also, it can't be the winding because the triangle fails from both sides.

I also tried not passing any normals, seeing if that helped, it didn't....Undecided

Any ideas?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline harryk

Senior Newbie




Stone golems rock!


« Reply #58 - Posted 2005-06-22 12:41:18 »

Space-bug perhaps? Have you tried collisiontesting not using spaces or used a simple space?
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #59 - Posted 2005-06-22 13:04:09 »

Im using HashSpace, i changed to SimpleSpace and the problem is still there...

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (23 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (41 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!