Edited by - Jesper T on January 14, 2002 11:40:14 AM
Some questjuns
Author
1) If I draw a triangle outside of the view in OGL, how much resources/time does it take compared to drawing it inside the view ? Well I guess it depends on videocard etc.. Basically what I was wondering about was how much resources should I spend on checking wether its inside or outside the view before drawing it ?
2) Is there a OGL rotation function that uses radians instead of degrees ? (my own rotating functions I use radians cuz it makes more sense when comparing it to a distance)
thanks for any helpk
Edited by - Jesper T on January 14, 2002 11:40:14 AM
Edited by - Jesper T on January 14, 2002 11:40:14 AM
1) You shouldn''t worry about clipping at the triangle level. Instead, try to quickly decide whether whole objects are visible or not. Using hierachical bounding boxes for example. i.e. if a box (containing objects/other boxes) is visible, draw the objects it contains and check whether the subboxes are visible, and so on.
2) No, add a macro/inline function to do the conversion.
2) No, add a macro/inline function to do the conversion.
not worth to process small count of geometry,
you should dismiss / accept large blocks of geometry
at a time, which is efficient
for example if you''ve 50 k polygons in scene,
you don''t want to check each of them per frame, terrible
(tick tick), brr
do tests with large leafs (sectors or whatever)
with bsp for example you can dismiss very quickly
the geometry been processed by *only checking in which
side of current node''s split plane your camera translation
point is currently
something like:
root node ->
classify camera pos root->split plane
->camera is currently back of the split plane
->we know camera is in back of the root->split plane so
then
recurse->root->plane->back
continue testing and always dismissing half of polygons...
we just dismissed the front size of geometry (root->plane->front)the 50% of all world polygons to be tested!!! by only testing one simple POINT_PLANE_CLASSIFY, (no need to say, it''s faster
than checking 50% all polygons to find result: no need to process them)
this ofcourse assumes you check each node''s split plane polygons for collision
you should dismiss / accept large blocks of geometry
at a time, which is efficient
for example if you''ve 50 k polygons in scene,
you don''t want to check each of them per frame, terrible
(tick tick), brr
do tests with large leafs (sectors or whatever)
with bsp for example you can dismiss very quickly
the geometry been processed by *only checking in which
side of current node''s split plane your camera translation
point is currently
something like:
root node ->
classify camera pos root->split plane
->camera is currently back of the split plane
->we know camera is in back of the root->split plane so
then
recurse->root->plane->back
continue testing and always dismissing half of polygons...
we just dismissed the front size of geometry (root->plane->front)the 50% of all world polygons to be tested!!! by only testing one simple POINT_PLANE_CLASSIFY, (no need to say, it''s faster
than checking 50% all polygons to find result: no need to process them)
this ofcourse assumes you check each node''s split plane polygons for collision
quote:Original post by rickpeek
this ofcourse assumes you check each node''s split plane polygons for collision
this ofcourse assumes you check each node''s split plane polygon for collision or etc...
quote:Original post by rickpeek
or etc...
No ellipsis (...) after etc. (Which means, litterally, "and stuff" ).
Some cards will do view frustum culling on triangles, but this still requires the points to be perspective transformed. If you''re talking about a lot of points, this will still slow your program a lot.
Look into quadtrees or octrees. A quadtree divides a scene into quarters, and each quarter into quarters, etc, down to a certain level.
Visibility culling on quadtrees is very efficient because you can view frustum cull each level of the quadtree recursively, and dismiss large sections of the scene at a time.
Octrees work on the same basis, but are made of cubes, each level dividing into 8 (2x2x2) nodes.
Quadtrees are generally better for largely flat scenes such as landscapes. For more general scenes, use octrees.
www.elf-stone.com
Look into quadtrees or octrees. A quadtree divides a scene into quarters, and each quarter into quarters, etc, down to a certain level.
Visibility culling on quadtrees is very efficient because you can view frustum cull each level of the quadtree recursively, and dismiss large sections of the scene at a time.
Octrees work on the same basis, but are made of cubes, each level dividing into 8 (2x2x2) nodes.
Quadtrees are generally better for largely flat scenes such as landscapes. For more general scenes, use octrees.
www.elf-stone.com
Author
Hmm yes I''ll figure it out, thanks again.
Suprising that you cant rotate by radians directly, im pretty sure its converted to radians anyway.. seems like a waste to make a function that converts it into degrees then calls the glRotated(blazh); which again converts it back to radians (if thats what it does that is)
Suprising that you cant rotate by radians directly, im pretty sure its converted to radians anyway.. seems like a waste to make a function that converts it into degrees then calls the glRotated(blazh); which again converts it back to radians (if thats what it does that is)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement