[odejava] Weird GeomTriMesh problems

Game Mechanics
#1

I’m having some issues with GeomTriMesh detecting a collision. The summary is that any part of the tri mesh that has a negative Z component will not generate contacts! ??? >:( We’re completely stumped by this and just can’t seem to find out what is going wrong. If we translate everything to positive Z, then it works fine, but leave it centerd about the origin and everything goes down the crapper.

The docs are a little hazy, and the examples don’t help at all. From what I can tell, the trimesh is running a left-handed coordinate system, with +Z upwards. However, I have tried feeding the geometry with both Y&Z reversed, opposite order triangle winding and almost every combo you can think of, and it’s still not finding them :frowning: This is getting frustrating, and my brain is quite fried (project deadline tomorrow) so any assistance on places to look at where I might be doing stuff wrong would be greatly appreciated.

#2

If it’s any help, I can confirm the presence this bug at negative Z values and at large positive Z values.

I also noticed some strange happenings in my game where the tri-mesh would fail at certain points. Thanks to your post I now know this is when the map goes into the negative and can work around the problem. Thank you, I’m very glad this bug has been discovered! As it only happened rarely in my project, I was hoping it would just go away :wink:

As to why it happens or how to fix it I don’t know. The winding of the triangles is important as you mentioned - but if it only fails for negative Z (which mine also does) then it’s certainly an ODE/Odejava problem.

Perhaps this is worth a post to the ODE mailing list asking if anyone else has the problem. It has been a while since I updated the ODE binaries, perhaps this is resolved with the latest version of ODE.

Will.

#3

Bugger :frowning: Ok. Well we had to bail on doing the trimesh anyway and now have our modellers going OT on building an abstracted model using boxes. Probably end up running faster that way anyway…

#4

Me too :slight_smile: Any news on this issue?

EDIT: Ah, however, only collisions with a negative Z component work for me :slight_smile:

Kev

#5

Kev,

It’s odd that your results are opposite - maybe your winding or gravity is reversed?

I can confirm this is still a live bug. Not sure if it’s ODE or us – or even if it is a bug at all (it could be a feature…).

Will.

#6

Its probably the winding, I’ve not payed much attention there. I was hoping to produce a relatively generic engine but with this bug its going to be hard :slight_smile:

So… so fun tho, ODE really is entertaining.

Kev

#7

im really stumped by this ??? cause I dont see this bug anywhere!

See this demo:

http://www.myjavaserver.com/~digiwired/physics-terrain.jnlp

The terrain is centered at (0,0,0) and all the collision is fine! Whats going on!

DP

#8

I still feel it’s an ODE bug rather than winding. I tried reversing the winding of our triangles going into the mesh and it made no diffference. The test we have is a simple flat triangulated mesh with a bouncing ball. As soon as the ball gets past a triangle that is completely in the negative Z axis, contact information is no longer generated. ???

#9

i haven’t looked very carefully at the ODE native code. But it looks like they might be doing (z*z) or modulus(z) somewhere on the Z component to calculate some physics equation…and if the position is in the Z ignore it…

Thats the only solution I can think of…But whats really troubling me, is if that was the answer, then why am I not getting that bug! :-/

DP

#10

DP, is your “floor” represented by a GeomTriMesh or a GeomBox?

Kev

#11

In the towers you mean? its a box.

But the terrain is a trimesh…

DP

#12

Just had a look at your physics system in the vain hope I might be able to work out whats going on with this. Its very nice.

Your terrain is origined as 0,0,0 tho, so I guess is goes out along the x and z axis in one direction only? You wouldn’t see the problem this way I don’t think…

I might have a play in a bit if I get time…

Kev

#13

Yes, you are correct, it only extends in the +z and +x. However, i have just translated everything into the -z section, and played around with different combinations of + and -ves. And all in all, the collision is fine!

Try moving the terrain -200 z and the balls -200 z. They still collide.

DP

#14

I’m not trying to get at you here… I’d just really like to know whats different between what you’re doing and what other folk are doing… I’ve tried to go through with a fine tooth comb but not managed to turn up anything yet… even down to ordering of operations…

For my purposes this issue and the non-moving trimesh issue makes ODE pretty much un-usable.

Kev

#15

Ofcourse not. Sorry if my message implied that. I was pretty tired.

And to be honest, i would like to know what I am doing to make it work! :slight_smile:

DP

#16

I think that triangle winding thing really was a bit of break through. I’m doing some nice primitive experiments and simply changing the order in which the vertices are specified effects the collision or not collision even when specifing normals it seems.

Mad!

Kev

#17

I’m still trying to resolve this issue. Has anyone had reports that ODE doesn’t work very well on large triangles… seems to be confused … shrink um down and they work quite happily.

This would explain why the terrain demos I’ve seen would work… lots of little triangles.

I’m going to write a utility to split triangles over a certain width/depth/height into multiple smaller triangles before passing it into ODE.

Kev

#18

Coo, sub-dividing all my triangles on an arbitary designed map seems to have done the trick. I’ve used Maplet to produce a B3D model, which is stuck through JME and then converted into a ODE mesh (via the sub-dividing routine) and it works quite happily.

My little alien is running all over the place interacting with the environment correctly. Excellent!

Kev

#19

Do you have one large tri-mesh or several smaller ones making up the environment?

I believe having lots of smaller Tri-mesh making up a larger one might work better better with ode, but I havn’t tried it yet.

Will.

#20

I think you’re correct (at least from trying it I do ;)). A series of small collections of triangles is better for ODE. However, the collisions not working seems to be to do with the size of the triangles rather than the size of the collection of triangle.

Infact it seem to be more to do with how far your primitive is away from the points of the triangle as to whether it would work or not.

Kev