Bounding box for collision detection

Hi Forum

As you can see from the subject header, it relates to bounding boxes.

I would like to write a function that would allow me to pass a mesh object to a function that returns the max and min of x,y and z coords of that object.
The algorithm is pretty straight forward. But, what I am struggling with is to get the vertex data of an arbitrary mesh object in the first place, in order to read the data and find the min&max of xyz.

A concrete example:

Say I have a function glutSolidSphere() /this might be any other function that draws an object/
, and I would like to transform this object and then find its vertex data. So…

    find_maxmin_xyz_of_object(temp_x,temp_y,temp_z);//or something of this sort.

    glTranslatef(0.5, 2.5, 0.0);
    glScalef(1.0, 1.0, LETTER_DEPTH);

As you can see, with calling an arbitrary function that generates an object, it is required to find the vertex data of this object.

I had a look at pre-compiled objects, such as display lists, but I was still faced with the challenge of getting the vertex data of that display list object.

I think this could be especially useful in scene-graphs.

Thank you for your time.

You can not process vertex data without understanding it at least partially, so doing this for arbitrary objects is not possible. Someone might compress their vertex data and decompress it on the fly in the vertex shader - without knowing the (de)compression algorithm how could you hope to access the vertex positions?

Rendering systems usually store vertex data in their own data structures that either only store a very specific type of data or are descriptive enough that you can process all the different possibilities. With something like that in place you can compute an AABB over all geometry that is stored in such a data structure.

Now, glutSolidSphere() simply makes immediate mode calls to glVertex3f (and friends) to directly pass vertex data to OpenGL without storing it in memory. That means the vertex positions are never stored anywhere where your function could access them.

Thank you for the clarification.

It does seem a bit counter-intuitive, but as you have explained it, it is clear why.

The only alternative that I can think of is to create an interface class that holds descriptions of the mesh functions that are called through it. Less than sought after, but at least it will do what I want.

Thanks again for the quick reply, if I joined the forum earlier it would have saved me a great deal of effort searching for something that can not be done.