I am working on a graphics framwork which includes primitives like cylinders, bends, spheres etc. I want to implement level of detail feature for these primitives so that if in a model(suppose a piping model), if these primitives are near the screen, then they should be rendered with greater details(high number of sides and rings) otherwise they should be displayed with less details (less sides and rings). I tried searching the net but all I could find was LOD for terrain geneation.
I was thinking of such an algorithm
Project the 3D position of the primitive using gluProject and get the z position of the primitive
If it is near far clipping plane, decrease the details.
Is this an efficient way to do this??? if not what other options do I have. Can anyone point me in the right direction???
But I am using simple glRotatef/glTranslatef to move camera not gluLookAt… so do you mean I need to keep track of the cameracoordinates myself. Isn’t there a way to extract the current camera coordinates through OpenGL and use them???
Thanx for the link. I just read the whole article and it was very informative. My question now is… Is it faster to extract the frustum and then find the distance from the near and far planes or is it faster to simply GLUproject the point and then calculate the distance. The amount of calculations needed by extracting the frustum seems to be quite a lot while if gluProject calculates the results in hardware(i’m not sure about this either)… then it should be faster…shopuldn’t it be???
I should use the frustum method as
you realy need to cull objects as
well so you kill 2 birds with one stone,
and as it says it only needs calling once
per frame (or on camera movement).
I dont believe glu[Un]Project is HW accelerated
(could be wrong though),And you would need
to call this before rendering each object,
so on scenes with a large amount of objects
you could end up with more calculations than
the extract frustum method.
The amount of CPU time needed to extract the frustum planes as done in Mark’s paper is nothing compared to what is needed to keep a 3D engine going.
There is no reason for gluProject to use the hardware. It’s not much to do, just a few multiplications and additions, and the CPU can do it just as fast as a GPU. And I’m not even counting the time needed to transport the data to the hardware, waiting for the hardware to be ready, and retieve the resul from there. This would slow the operation down even more.