🔒 Locked 🎮 Unity

Collision/Culling - Design Issue

Started by jeannekamikaze Jun 13, 2010 at 4:23 AM 3 replies 1.4k views

Original Post

Jun 13, 2010 at 4:23 AM

Hello. I've got a design issue that I just ran into and I'd like to discuss it here to see if anyone who has had a similar situation can help me out. I just noticed the description got kind of lengthy so please bear with me.

So far I've got this class called "Model" which holds model data - vertices, indices, and normals. Apart from that I have an "Entity" class, which amongst other things has a member variable which is a pointer to a Model instance; this way, all entities of the same kind share the same geometric data.

So, for example, to draw a bunch of trees in the scene, I'd have several instances of Entity and a single Model for the tree. Each tree Entity would apply its transformation matrix and then call the Model's draw method.

So far so good.

Now say I want to perform a collision test between two trees. First I'd build a bounding box around each one of them, test for box collision, and if the box test passes then I'd perform a more accurate per-triangle one.

However, I have a problem: the Model class holds the tree's data in local space - i.e. I don't have the vertex data for each tree in world space.

What I thought about the bounding box is the following:
Each tree Entity would have a box which is updated every time the tree entity is transformed; the box would first be calculated in local space and then I'd apply the Entity's particular transformation matrix over the box to transform it to world space. This way each tree would have its own bounding box in world space ready for collision.

However, what shall I do with vertices? I need each of the tree's vertices in world space to perform an accurate collision after the box one, and I don't have these.

Letting the Entity have an updated copy of its vertices in world space would kind of defeat the purpose of having a Model instance shared between all entities of the same kind.

Transforming each of the entity's vertices to world space before performing the collision test would bring a performance hit if several collision tests are carried since these would be recalculated for every test.

I'm not sure if I'm being clear enough so please ask for clarifications if you have the time/will to help me out.

Perhaps I should take a whole different approach. Your feedback is all welcome :)

mind in a box

Jun 13, 2010 at 4:54 AM

You can put the intersection ray into object space:

 bool WActor::OnTrace(D3DXVECTOR3 Start,D3DXVECTOR3 Dir,D3DXVECTOR3* Hit,float* Dist,WComponent** HitComp) {	 D3DXVECTOR3 vNear,vDir;	 D3DXMATRIX invMat;	 D3DXMatrixInverse(&invMat,NULL,&WorldMatrix);	 D3DXVec3Normalize(&vDir,&vDir);	 BOOST_FOREACH(WComponent * Out,Components)	 {		 Out->World=&WorldMatrix		 D3DXVec3TransformCoord(&vNear,&Start,&invMat);		 D3DXVec3TransformNormal(&vDir,&Dir,&invMat);		 Out->DoTrace(vNear,vDir,Hit,Dist); //Your model goes here,with the right rays		 D3DXVec3TransformCoord(&vNear,&vNear,&WorldMatrix);		 D3DXVec3TransformNormal(&vDir,&vDir,&WorldMatrix);		 //Hit location (In world space) is vNear+(vDir*(*Dist));

I hope this is what you need..

jeannekamikaze

Jun 13, 2010 at 10:24 AM

Well this isn't about ray tracing but you gave me an idea which I'll discuss in case anyone is interested.

The problem arises when colliding two objects A and B which share mesh data.

Instead of doing a per-triangle collision, I'll collide A's triangles with B's bounding box, which is already precise enough and faster than a triangle-to-triangle collsiion.

To do so I'll calculate the inverse of A's world matrix and bring B's bounding box to A's local space as you suggested, where the box-triangle collision will take place.

I think that should do it :), thanks for your idea.

earl

Jun 13, 2010 at 5:21 PM

Just one thing. There are many other threads discussing such things, but you don't typically want to be colliding mesh data directly with other mesh data. Almost all games will use a higher level of abstraction, such as orientated bounding boxes, spheres, capsules, tree structures, etc. This also goes beyond just performance issues, and has implications for physics simulation, gameplay and fairness issues.

If you're aware of all these things, and still wish to proceed, then ignore everything I just said!

jeannekamikaze

Jun 14, 2010 at 2:15 PM

I've got the point now, and avoiding colliding mesh data with other mesh data solves my design issue.

In any case, I guess you'd want to collide bounding volumes with mesh data. Like say if you have a car and a stop light, a box-box test wouldn't let you drive the car under the stoplight, however a box-mesh test would, so I guess the proper thing would be to go for a box-box test first to eliminate false positives and then go for a box-mesh test if the first test passes, which isn't as expensive as a mesh-mesh collision since that would imply considering every pair of triangles.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.