0
\$\begingroup\$

I was thinking how to do collision detection in my OpenGL application and came to conclusion that I should keep two copies of my geometry data.

1)First copy : Only for OpenGL rendering purposes.This can be saved as VBO,Vertex Indices.(saved in GPU?)

2)Second copy :I save in client side(in a class ,say 3DEntity) which I perform all tests including bounding-box collision test,ray casting,

So, after I load a mesh data (say from an OBJ file), first I prepare the "first copy" and then using "vertex indices" I prepare the "second copy". (For example: If my mesh is a simple cube ,my "first copy" will have 8 vertices,and use Vertex Indices to render it properly.But my "second copy" will have total 36 vertices.Because I have to do ray-casting on triangles)

I keep a transformation matrix inside the "3DEntity" to keep states like Position,Rotation..etc of my "3d Entity". So in psuedo code;

class 3DEntity {
 Vertex[] verticesForPhysics;
 Matrix tranformationMatrix;
}

I keep the "verticesForPhysics" values fixed.(Means, its always in model coordinate system).So When I want to move,rotate my entity I simply change "transformationMatrix".

When doing tests like collision detection , I make a temporary copy of vertices again,by multiplying "verticesForPhysics" by "transformationMatrix" giving the vertices in World coordinates.

Vertex[] verticesForPhysicsInWorld=transformationMatrix * verticesForPhysics;

Now I do my tests using these "verticesForPhysicsInWorld".

Is this the correct way of handling this ? How do other OpenGL game engines handle this ? I am worried about data redundancy by keeping two copies and making another temporary copy for collision detection tests

Improve this question
\$\endgroup\$
5
  • 3
    \$\begingroup\$ Your instinct is correct, always separate rendering data from physics. Many times physics gets a very cheap version of the real geometry, for example. Many content pipelines, if not all, have options to automatically produce a physics model in addition to the rendering data and often there are options to decimate the physics data to simple bounding hulls. Don't worry about data redundancy because the data is totally different and used by different engines. You wouldn't use your keyboard input library to play sound FX, I hope =) \$\endgroup\$
    – Patrick Hughes
    May 18, 2012 at 5:15
  • \$\begingroup\$ @PatrickHughes thank you for the tip.Do you know any techniques for this "decimation" you mentions? Any keywords for googling would be appreciated. \$\endgroup\$
    – Ashika Umanga Umagiliya
    May 18, 2012 at 5:24
  • 1
    \$\begingroup\$ I'm assuming we're not doing ragdoll stuff right now. You'll be doing physics in world space, indeed. However each individual mesh may have an aabb or a sphere, but that's more likely just for frustrum culling. You'll need a seperate aabb for physics that'll describe how a whole object behaves. You'll have a sword and that sword is going to be attached to the player's hand in the scene graph, but you won't be checking for collision with the sword and then hero individualy, you'll just check for collision with the player using the aabb that describes the whole object in physics space \$\endgroup\$
    – dreta
    May 18, 2012 at 5:29
  • 1
    \$\begingroup\$ Beside that it seems redundant to transform the whole mesh to do collision for most objects, you create a model, attach all the stuff to it like a flashlight or a hat in the scene graph and then create an aabb that best describes the whole object in it's own space. \$\endgroup\$
    – dreta
    May 18, 2012 at 5:31
  • 1
    \$\begingroup\$ Decimation is just a fancy word for making an extremely low polygon version of the model you use to render. Physics doesn't need high definition, just a blunt approximation. In many cases you cheat by just using a box or cylinder. \$\endgroup\$
    – Patrick Hughes
    May 18, 2012 at 7:29

1 Answer 1

Reset to default
2
\$\begingroup\$

I think of a game as some kind of simulation that needs a real time input from a number of interactors and returns a real time output. The main objective of this simulation is that the input<>output interaction is fun.

There is no collisions in openGL; only drawing, which is part of the output of the "simulation". (I'm saying this because of the title).

I'm not sure you have to worry on which parts of the hardware the data is being held on a first approach. I'm not even sure you need to save the matrix transformation; you can just save the position, velocity, rotation etc of the entity. Because that is what is part of the "simulation" (in case you use more complex itens than this must be re-thought).

The collision algorithm should never be used on all the vertices you've designed for your model. That is a kind of simulation that will not run on realtime. Try to search the concept of collision box. Basically is a cube, or other simpler form, which can be used to simulate collisions without calculating with all the vertices of your model.

About the copy, I think that what you really must focus is on how the code must be designed in order to be able to let the simulation and input/output be two distinct things. For instance, given a struct/class in c/c++, there should be a function like "draw" for every entity that you want to draw onscreen (which call openGL functions). And thats it. Let openGL handle the rest.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .