Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


What does OGL clip?

This topic is 6335 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If the objects I draw are outside the viewing frustrum, does OGL clip them? does that give me a performance increase? If so, how much faster would it be if I dint draw the outlying objects? If not, is this why we have portals and octrees n stuff? Thanks.

Share this post

Link to post
Share on other sites
Opengl does clip geometry beyond the sight of view. Although it may have a small increase in speed (extremely small increase in speed), it doesnt actually prevent your drawing routine from executing, as opengl clips only AFTER youve drawn. Pretty hopeless if you ask me.

eg. DrawTriangle:


It is the above code which is taking up all the rendering time. And yes, this is why we use custom-made frustum culling code, as we can specify each of those three points to determine if the object is actually in the viewing volume. This method is extremely better than drawing the damn thing, and then clipping it.


Share this post

Link to post
Share on other sites
youre confusing clipping and culling.
1/ let opengl do ALL clipping for u
2/ u should do all the culling for opengl


Share this post

Link to post
Share on other sites
thanx for clearing up stuff. and i was wondering why my framerate dint go up even though ALL my objects were clipped.now i know gotta read up on clipping n culling!

Share this post

Link to post
Share on other sites
The use of portals/octrees is always useful since it dramatically reduces the number of polygons to be rendered with few calculations.

As for backface culling, you could let the board make it for you, since it''s a simple operation which can be performed both in 3d and in 2d space. Backface culling is implemented since the first voodoo board, so let the board make it for you.
When talking about clipping, you should distinguish between software implementation, hw transform implementation and hw transform and clipping implementation.
Software implementations will simply slow down your app, as in general tasks like software clipping present in drivers are meant to be stable, not fast. Some old boards provided clipping by simply removing single pixels outside the screen. Of course this was damn slow and unstable (some polys could be so far away that the board wouldn''t remove them).
As for hw trsform boards things are a bit different. Radeon provides 6-planes 3d clipping, and clipping should be performed in 3d eye-space. With a Radeon, go for GL clipping. Geforce provides only hw transform, with clipping performed via guardband method. I remeber guardband is a 2d clipping performed on a BIG boundary (2048x2048?). Vertices are transofrmed and projected by the hw, so we can reuse them. Then a 2d clipping is performed by testing the view area against the guardband area (view area is in the center of guardband area).
Anyway, if one of your vertices lays outside guardband area, an error could be generated. Dont'' take it for sure... I hope my memory isn''t joking me.

As for me the point is:
- always use portals/bsps/octress/what you want in order to reduce the number of polys to passed to the board.
- let the board do backface culling for you, since it''s a quite cheap operation and is supported since the first voodoo.
- unless you have a T+C capable board, always make clipping.
- At least trivial clipping (all vertices outside view volume) should be always performed on non T+C boards. Someone states it''s possible to make trivial tests and let the board do 2d/guardband clipping, because you don''t have to add polys to your vertex lists. Someone else sates it''s better to make it software because some old boards could make the game unplayable.

Whatever way you choose, remember driver developers aren''t about to write a new, lightning fast 3d engine. Often OpenGL drivers has few operations (the most used) really optimized, leaving the other parts of the driver simply stable.

Sorry for the long post, hope you''ll find it useful.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!