Jump to content
  • Advertisement

Archived

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

GHoST

Frustum Culling

This topic is 6330 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

Ok, I have a relatively basic problem. For some reason my math seems to have failed me on this, so.... I have a very typical frustum defined by 6 planes, each plane being defined by a normal and a distance. I simply want to transform the frustum so I can test points against it in their local space, so I can save myself the trouble of transforming all of the points to test them against the untransformed frustum. I must be missing something obvious because I can''t get it to work correctly. If someone could give a clear explanation/example I would appreciate it, and hopefully it will help me find whatever stupid mistake I am making. Thanks

Share this post


Link to post
Share on other sites
Advertisement
well i could show off and state all the math , but i''ll just point you to http://www.flipcode.com/portal/issue11.shtml for the very simple math and examples that go with them!
if you need to make the plane definitions in its standards fast check http://www.flipcode.com/portal/issue06.shtml for more info!

Share this post


Link to post
Share on other sites
Interesting articles, and thanks for pointing them out, but they don''t really address my problem. I could change the way I am doing things to just completely redefine the frustum, but I would prefer to just transform the existing plane normals and update the distances. Or is this not a good idea? I am not concerned with building the frustum, calculating the planes, testing polygons, etc... I don''t have any difficulty there. To break this down to the simplest form of my question: what do I transform the normals by, and how can I update the distances correctly. I am assuming that I am just using the wrong matrix to transform the normals.

Share this post


Link to post
Share on other sites
ooookay. i''m having a bit of a problem understanding your question,because as i see it now you want to rotate/translate(=transform) the planes of the frustrum to a place in your 3 world so you don''t need to transform your world.

well i''m not a wizard in rotating planes. but if you have the polygons from which the frustrum planes are build you could just rotate translate those and then create the frustrum at the correct place you want and then check at your leisure. and i don''t knwo why you want to transform the normals of the planes if you just use the frustrum for checks. can you be more specific on that ?!

Share this post


Link to post
Share on other sites
Heya,

What you do is inverse transform your frustumplanes into objectspace.

For example the normal way of transformation:
Object1 is defined in objectspace
you then do the following (I assume):
make rotatex matrix
make rotatey matrix
make rotatez matrix
make translation matrix
Then in exact order you multiply:
identity matrix with rotatex matrix
then with rotatey
then with rotatez
then with translate matrix
(rotatex,y,z may be shuffled in your case)

Now for the planes the inverse matrix is needed to rotate the planes into objectspace.
This is exac the opposite of the normal transform
thus,

make -rotatex matrix
make -rotatey matrix
make -rotatez matrix
make -translation matrix
Then in exact order you multiply:
!identity matrix with translate matrix
!then with rotatez
!then with rotatey
!then with x
Now rotate your 6 planes with the new inverse matrix.

That''s it!
Only thing i''m not quite sure of is, if you need the normal rotatex,y,z,translate instead of the negative versions -rotatex, -rotatey...

I guess the problem was you took the negative angles and negative transform, but build your combined matrix in normal order instead of opposite order.

PS Please mind my english It''s late over here

Gr,
BoRReL

Share this post


Link to post
Share on other sites
It doesn''t make much sense to transform your frustum to each individual object space though - at some point your objects will
be transformed into view space as part of the rendering process so why not check them there?

Share this post


Link to post
Share on other sites
Use Bounding boxes or sphere or blob or whatever and transform them into world coords in order to clip, won''t take much power or time to do so.

Fast and easy way.

For BackFace Culling, transform view vector in object space, depending on how and when you do shadowing and lighting.

-* So many things to do, so little time to spend. *-

Share this post


Link to post
Share on other sites
Heya,

Depends on the size of the object (in polygons).
If for example you have a simple mesh in a world, use a boundingboxe. But if you want to clip your terrain with the frustum then you really should inverse transform it!
Also you can do the backface culling in objectspace like this.

Gr,
BoRReL

Share this post


Link to post
Share on other sites
Thanks, everyone. BoRReL, I am pretty sure that I was doing exactly what you said (in your first response) but maybe you are right about my ordering being wrong. I will double check. I actually redid it from scratch yesterday, transforming the polygons that define the planes and rebuilding the frustum that way instead of transforming the normals themselves, but something still went wrong there. To answer some of the other comments: I won''t be transforming the frustum for each object, it will only be transformed once into the world, so I can test the bounding objects at each node in my scene graph. Every object will contain some coordinates that represent an absolute position in the world and a definition of a low res version or bounding volume for visibility testing.
I was initially transforming bounding boxes to do the testing, but this is much more expensive. I prefer to leave such transformations in hardware where they belong.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!