Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Need help with Vertex Data and Tri Meshes!

Author
Message
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 28th Jan 2010 18:14
Link
Hi,
I'm trying to convert a DarkGDK mesh to a TriMesh that I can use for collision in ODE.

Here is what I have so far:



Well, there is some collision response, but it looks like not all vertices are in the data or something. I don't really know what's wrong.
Has someone ever tried this before?

And I have some more general questions:
1) What exactly is an Index and how is it related to vertices?
2) Why does a standart DGDK primitive box have 24 vertices when it should just have 8?

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 28th Jan 2010 19:25
Link
You may want to look into whether dbMakemeshFromObject() removes all the indices, I had a similar problem and think that was the issue.

If you don't use dbMakeMeshFromObject() then you need to loop through all the limbs in the object and make a triangle mesh from each one, thats what I do.

1)
Each vertex in your mesh is given a number(Index) which represents that vertex.
So, a triangle may have a vertex(0, 5, 0), then that is labelled 1.
Do this with each vertex then you can group any three index values together to make a triangle.

Index array(1, 3, 2, 4, 5, 6, 7, 8, 4)
This is really((1, 3, 2) (4, 5, 6) ( 7, 8, 4))

2)
One side of a box has two triangles, each triangle has 3 vertices:
3*2*6 = 24. This means that some vertices are repeated in the mesh data. There are different ways to draw meshes(triangle lists etc) which one is being used will affect how many vertices it needs.


I THINK LOL.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 28th Jan 2010 19:41 Edited at: 28th Jan 2010 19:49
Link
Hey, thanks for your help!

Ok, I've replaced dbLockVertexDataForMesh with dbLockVertexDataForLimb, and used it for limb 0 (I'm testing with a primitive box, so all vertex data should be in this limb). But the result is still the same.
It may have something to do with how ODE reads the mesh data?!
I'm googling like hell to find out right now...

The problem is that the sample that came with ODE uses a simple float array of a fixed size to create the vertex data, and my array dVector3 * vertices = new dVector3[vertexcount] depends on the vertex count. I'm not a C++ pro (but not a noob either), so I don't know how to dynamically create a 2-dimensional float-array! Can you help me out?

Thanks on 1) and 2), you explained it very well These wicked primitives...
Now I know what I'm dealing with

EDIT:
Here are a few snippets of how the ODE tri-mesh sample does it:

Data structure:



Vertices-Array is filled with data like this:



Indices-Array is filled like this:



And finally the tri-mesh is build like this:



Maybe someone is so kind to guide me a little

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 28th Jan 2010 20:52
Link
I cant help with the dynamic float array but I would be interested in the answer.

I would do a quick check to make sure primitives have indices as I dont think they do. If they dont you need to be testing your code on something else, terrain etc.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 28th Jan 2010 21:00
Link
I just checked the primitive, and it definitly has Indices!

And I loaded a simple X-model and it behaves like a primitive (weird collision).

I'm doing some further research right now...
C++ can be very confusing sometimes.

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 28th Jan 2010 21:13
Link
Ah, maybe my problem was with repeat vertices in primitive objects, in PhysX the triangle mesh must not contain repeat vertices or you get strange results, this of course may be different in ODE but its something to be aware of.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 28th Jan 2010 21:20 Edited at: 28th Jan 2010 21:21
Link
Hmm, yes that could be a problem!
How did you figure out what vertices are just repeated (exist twice)? Just check for identical coordinates??
And how did you cope with it?

The mesh has indeed a strange behaviour when bouncing. Sometimes it looks natural, then again it starts penetrating the ground or it suddenly picks up unnatural velocity.

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 28th Jan 2010 21:31
Link
You can check for identical vertices but it was not a problem for me as physX has commands to make primitive objects as I'm sure ODE probably does. So you just put the dimensions of the primitive (cube, sphere etc) in and it will look the same as your rendered primitive(cube, sphere etc).

I only use triangle-mesh for non-primitives (terrain or loaded objects etc) and it works fine. In physX triangle meshes are always static, you use convex meshes or compound shapes for complex dynamic objects.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 28th Jan 2010 21:49
Link
Yes I have all kinds of primitives (box, sphere, capsule,...) already supported in my Physics Lib. ODE is very easy to understand considering primitives.

But I need triangle meshes for more complex scene geometry, terrain and such things.

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 28th Jan 2010 22:07
Link
I was just making the point that your function to make terrain(triangle mesh) may be useless on primitive objects, so maybe try testing it on a terrain instead.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 29th Jan 2010 01:23
Link
Quote: "so I don't know how to dynamically create a 2-dimensional float-array!"


You can't in the same way as you're using there, the whole 'float blah[x][y][z]' construct is compiler based and efffectively gets translated into 'float blah[x*y*z]' which is why the sample uses 'Vertices[0]', because that will result in a 'float*' which I assume is what the function expects.

Their function wants a list of floats, you have a list of vectors, but because your vector is just 3 floats(I assume) you can just pass that because it's the same thing, your initial code should work. Just make sure you're passing the right values for the indices and such.

Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 29th Jan 2010 02:06
Link
Quote: "because your vector is just 3 floats(I assume) you can just pass that"


Ok, I'm still working with my initial code with the dVector3 class (which contains 3 floats).

But I think it has something to do with the vertex/index data structure I receive from DarkGDK. Something seems to be wrong with some normals of the collision tri-mesh (which depend on a correct vertex order).
Does the vertex/index ID start with 1 or 0 in DarkGDK commands?

Beacause the resulting behaviour is not easy to describe, I attached a compiled EXE to illustrate the problem.
(I'm just using a primitive box there, so it's media-less. Loaded x-models behave the same.)

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.

Attachments

Login to view attachments
Back to top
Profile PM Email Website
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 29th Jan 2010 02:59
Link
Quote: "Does the vertex/index ID start with 1 or 0 in DarkGDK commands?"


0.

The demo seems to work some of the time and fail at others, that could just be a limit to the accuracy of the mesh collision, aren't there any physics debugging tools for ODE?

Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 29th Jan 2010 15:52
Link
No, didn't find a debugger yet.
In the meantime I posted on the official ODE mailing list, maybe someone there has encountered the same problem.

I still think it may have something to do with how normals are generated from the vertex order somehow. It just feels like some of the faces seem to have the wrong direction (normal points inside the mesh?!).
But it's hard to sort something out, because it seems to work and in the next second it doesn't!

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 30th Jan 2010 02:18
Link
It may be that ODE uses a right-handed coordinate system by default(GDK uses left), you can see if that's the case by inverting the vertex positions on the Z axis.

Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 04:04
Link
Well, I just found out that ODE has no specific handedness of its coordinate system. You can just change what is up how you like, I was already just doing it like DarkGDK (Y is up) without even knowing this.

But I think you brought me on the right track: I searched and found something about the winding order of ODE meshes.

Quote: "The winding order for ODE's trimeshes is the opposite to DirectX"


Quote: "triangles that are defined in CounterClockWise order are the
front facing ones in ODE"


But these are no official statements, just found that in another forum. Don't know...

Then the author in the thread says
Quote: "just write a simple method to rewind the indices in the index buffer"


How would I do that? What does it exactly mean?

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 30th Jan 2010 04:24
Link
Index data is just a series of triangle definitions in sets of 3, to reverse the order is to flip the order, so just write index 0 as 2 and 2 as 0. Currently you loop through all of them and just copy them over, instead loop in steps of 3 and do the above.

Back to top
Profile PM Email
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 30th Jan 2010 12:08
Link
Did you ever look at the repeat vertices issue, in other words, have you tried your function on something other than primitive objects?

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 13:48 Edited at: 30th Jan 2010 13:48
Link
@matty halewood

Yes, I tried it with simple .x-models, too. But it's the same.

@dark coder

Ok, I understand the index data like this:

{ 0, 1, 2, 0, 2, 3, ... }
^ ^ ^
each 3 values belong to one triangle

So does 'reverse' mean I have to flip the order of the values inside one set of 3 (e.g. like above the first index 0,1,2 becomes 2,1,0 but is still the first index) or flip the order of the whole array?

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 30th Jan 2010 14:42
Link
I think reversing the whole array would have no affect as all the triangles would be the same but constructed in a different order.

So, instead, as you said (0,1,2) becomes (2,1,0) and the order of each triangle does not matter, I think.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 15:06 Edited at: 30th Jan 2010 15:07
Link
Ok, so I just tried to reverse the index data like this:



Unfortunatly the result is still the same, it doesn't work...
Am I doing it wrong there?

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 30th Jan 2010 15:33 Edited at: 30th Jan 2010 15:36
Link
That looks right to me, i'm out of ideas although I will keep thinking.

Edit: if it makes you feel better, the tri-mesh functions were the hardest functions I had to implement in my plug-in so far.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 15:57
Link
Well, the whole issue doesn't seem to be as trivial as I thought...

But the good news is, I just tried it while keeping the model static (don't ask me why I didn't do that earlier ) and it works like ~95% of the time!
(That's even without reversing anything in the data.)

I attached an EXE with a simple model.
(Sometimes you get a runtime error, but I guess that happens when objects fly away into infinity.)

I still have to test it with a terrain model though...

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.

Attachments

Login to view attachments
Back to top
Profile PM Email Website
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 16:59 Edited at: 30th Jan 2010 17:04
Link
Just tested this with a static terrain mesh.

The dynamic objects bounce off ok, but they just fall trough the terrain, when they should come to rest!
So I still think this has to do with the normals/winding of the collision mesh!

I found this:

Quote: "You could re-calculate the winding based on the lighting normals. For each triangle, calculate the triangle normal based on winding, then calculate the average of the vertex normals of the vertices of the triangle. If the dot product of the two is negative, flip the winding of that triangle. "


Would that make sense for converting a DGDK/DX mesh?


EDIT:
How do I calculate the 'triangle normal based on winding'?
I know that I can get the vertex normals from DarkGDK commands (and thus the average of them).

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 30th Jan 2010 17:21
Link
Quote: "How do I calculate the 'triangle normal based on winding'?"


Cross product the positional vectors between vert0, vert1 and vert0, vert2, this will give you the normal of the triangle. But this shouldn't be necessary, because if your mesh is correct then you only need to find out which way ODE expects the triangles to be wound, you say you've now tried both directions and if it still doesn't work correctly then it's probably not this. You can verify this by creating an index buffer of twice the required size and duplicating the indices but reverse their winding, thus your object will be double sided.

Back to top
Profile PM Email
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 30th Jan 2010 17:37
Link
If all the objects bounce of the terrain correctly 100% of the time then I would say your normals are correct.

Objects colliding and objects coming to rest on each other are probably two seperare processes and it sounds like the objects are not going into a 'rest' state properly. In other words they may still be colliding on a very small level when they should be asleep causing them to fall through each-other.

This is all guesswork though, I am no expert in physics/collision.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 17:40 Edited at: 30th Jan 2010 17:42
Link
@dark coder

Just tried what you said with a double-sized index array (half of it reversed) like this:



And that made no difference in the behaviour of the rigid bodies.
So it shouldn't be the winding right?

Before that I even tried to re-calculate the winding based on the dot product of the calculated face normal and the average face normal like this:



But that doesn't do it either...

Meanwhile I'm really freaking out about this!

But thanks for your help so far guys!

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 17:50
Link
Here is what it looks like with a terrain mesh.

You will notice that the objects will fall through the floor when they should rest on the bottom of the terrain (in this 'valley' kind of area).

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.

Attachments

Login to view attachments
Back to top
Profile PM Email Website
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 30th Jan 2010 17:58
Link
I think your tri-meshes are looking pretty good in that demo.

I would definately say it is a problem with the objects not going asleep. I would look up info on objects coming to rest and also maybe skin-depth.

In physX, if objects are allowed to penetrate each-other too deep then they fly off or fall through each other just like what yours are doing. When working they go asleep when their velocity slows to a certain value and you can change this and the skin-depth, there are probably similar commands in ODE.

fulcrum physics - free collision/physics plug-in for DarkGDK
Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 18:21
Link
Yes, in ODE that is called 'AutoDisable'. I set that up already. You can pass a certain linear and angular threshold, and an amount of steps to take before AutoDisable happens.
But I don't know about the 'penetration' right now.

Hmm, ok I'll try and tweak it a bit to see what happens...

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 30th Jan 2010 19:09 Edited at: 30th Jan 2010 19:10
Link
Tweaking the ODE setup didn't really improve anything.

I'm thinking about grabbing the vertex and index data directly from the DirectX mesh.

I can get the DX mesh of a DarkGDK object like this, right?



Since ppMeshList is an array, how do I know which mesh to access?
I've seen these in the sMesh class:

dwIndexCount
dwVertexCount
pVertexData
pIndices

These will be useful right? I don't really know how to access the data yet.

Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.
Back to top
Profile PM Email Website
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 31st Jan 2010 01:18
Link
You could define the cube by hand, that way you'll know you didn't mess up(I hope).

Back to top
Profile PM Email
_Pauli_
AGK Developer
14
Years of Service
User Offline
Joined: 13th Aug 2009
Location: Germany
Posted: 2nd Feb 2010 01:29 Edited at: 2nd Feb 2010 01:31
Link
Hey people,

I finally got this to work!
And it didn't have anything to do with the tri-mesh at all. My mesh was already correct like I did it in my first post here!
I feel so dumb for this!
The problem was that I used a very basic nearCallback function from a beginners tutorial (in ODE the nearCallback function is called when collisions happens). This couldn't handle the trimesh collisions. So I had to change a few things in it, that I got from the trimesh-demo that comes with ODE.

But anyways, I'm still very happy. I have a lot of ODE functionality running under DarkGDK right now.

I attached a small demo that shows ODE trimesh collision working.
Happy stacking

And thanks for your support dark coder and matty halewood!



Now the plot thickens, the fps decreases, and the awesomeness goes through the roof.

Attachments

Login to view attachments
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-05-17 22:22:29
Your offset time is: 2024-05-17 22:22:29