6 replies to this topic

[__SKYe]

So, imagine the following situation:

I have an OpenGL program that uses frustum culling, and i have a model that is half inside the frustum and half outside the frustum and the triangles (of the model), and all the vertices of the model are stored in some model struct, and to see if a face is in view, that face's vertices are compared with the planes of the frustum.
Until here everything works as it should. But if i rotate the model (let's say 90º) using glRotatef, the model will obviously appear rotated on screen, however the vertices stored are the same as if the model is not rotated, so OpenGL will cull the faces that wouldn't be visible if the model wasn't rotated.

How would i fix this?

Should i create my own rotate function, to be able to know the current position of a vertex by using the angle and the initial position?

Hope you can understand the question, and thanks in advance.

[Brother Bob]

I don't understand your question. Are you saying that OpenGL culls your object incorrectly when you rotate it? OpenGL uses post-transformed vertices for culling, so you pass untransformed vertices, OpenGL transform them, and uses the result. Thus, any rotation you do is correctly taken into account.

[mhagain]

Are you frustum culling on a per-triangle or per-object basis? Sounds like the former to me, and if so, then you need to go to the latter. Frustum culling per-triangle will give you no benefit at all - you might as well just drop it and let the GPU do it for you. It will also very likely be much slower than if you were not frustum culling at all.

The idea is that your software frustum culling should be at a fairly coarse level - per object, or group of surfaces, or similar. This gets you fast rejection of larger things, and ensures that the CPU/GPU balance is the way you want it to be. Then you let the GPU cull the finer stuff for you.

[dpadam450]

Well as you said you are always using the stored vertices. So if you stand still and you move an object around, you have to use the new position. Instead of writing your own glRotatef, for now you can call glGetDoublev() right before you draw the object to get the final matrix. Take that matrix and multiply by your x,y,z position of a vector and you now have its new world position after your rotation. That is the position you want to test if you can see now.

[__SKYe]

Sorry for the unclear question.

I know that testing each triangle against the frustum is not a good thing performance-wise, i just didn't mention it because my main question was if a rotated object would be culled correctly.

I think dpadam450's answer is what i was looking for, altough i could use some help on this next question too.

Imagine i now have a model, and i build a octree (BSP/Quadtree) for it. Each node of the octree as some triangles attached to it (the values stored are the original position of that triangle).
If i move the model around using glTranslatef, i can keep the values of the octree up-to-date by adding or subtracting the amount moved to the original triangle position.
(And now please correct me if i'm wrong) The octree is the model, therefore, if a move the model 100 pixels to the right, i also move the octree, right?
But if i rotate the model using glRotatef, what should i do with the octree?
Should it be rotated as well, so when i want to test it against the frustum, i do what dpadam450 said and get the position of the octree itself, and, if a node is in view, i draw the rotated vertices?

Again sorry if it doesn't make much sense, but the main point is, how should i handle rotations with an octree?

Thanks for all your answers

[dpadam450]

When you Frustum Cull, you are culling objects. Nobody culls triangles. You only use a triangle type basis if you are doing raytracing. So you take the model (a collection of vertices/triangles) and make bounds for them, you can start simple with a sphere that bounds the objects or a tight fit box around the model. For the sphere, you just need to run the center of the sphere through the modelviewmatrix, and using that you have the new 3d Position of the sphere (plus a stored radius somewhere for how big the sphere is). For a box, you would take the 4 points of the box, run them through the modelviewmatrix, get those 4 points and test those if any of them are visible.

As for an octree, you have a static tree, find the new position of the model (which you should know without going through the modelviewmatrix, because you should be storing its position), and figure out which octree it is in. If it octree is static to the world, then the change is from moving the camera, so you need the cameras position/frustum in world space each frame.

[__SKYe]

OK, thanks for all your replies.