Oops!

You''re right there is no need to convert to radians. I just didn''t think.

- WitchLord

All the normals generated in this way take into consideration the fov values and aspect ratio, however I''m wondering if there are any special considerations to be taken with the forward normal, I''ve been using 0,0,1 will this work with any fov and any aspect ratio? Seems to work just fine with my testing settings of 90 fov and 1 aspect ratio.

Thanks for all your help! Using this method, it should be trivial to check spheres and axis aligned bounding boxes! For a bounding box I can just check the maxx against the left plane if it''s out then the whole box is out, do the same for the minx with the right plane, etc.

Rick

Bounding spheres are easy, you just check if the distance from any of the frustum planes to the sphere’s center is more than the spheres radius. if it is the sphere is outside the frustum.
Beware of the sign. The normal vectors point outwards, so a point is in the frustum if the point’s distances are all negative.
An AABB is harder. All of the AABB points can be outside the frustum, but the box itself might still be visible. Besides you usually store the box’s center (as a point), length, width and depth not points. I store the box’s points, but I’ll change that, because that takes up to much memory. You also have to recalculate all the points each frame.
An OOBB is even harder. I don’t have any idea (yet, but I’m working on it ) how I could check an OOBB against the frustum, knowing the box’s center an the direction vectors.

Pascalix.

Yeah I run into this problem before, it would happen when I got really close to a large box, the vertices themselves would be not visible but the face still was, I think the trick is to check the min and max values of the box instead, for example you could check the box''s maxz vs the forward normal, don''t know if this would work haven''t tried it, still working on the spheres =)

Spheres should serve me fine for most cases, exept that I also want to use this code on my quadtree terrain stuff and a box would closer represent the nodes.

Rick

Argh, something wrong with the aspect ratio, I can use any fov no problem but if I set the aspect ratio to anything but 1.0 it doesn''t give an accurate value, here is the code for the left normal:

float fov = 110.0f;
float ar = 1.0f; // if I change this it wont work

float fovy = D3DXToRadian( fov / 2.0f );
float fovx = (float)atan(ar*(float)tan(fovy));
D3DXVECTOR3 normal;
normal.x = (float)cos(fovx);
normal.y = 0.0f;
normal.z = (float)sin(fovx);

Thanks,
Rick

quote: Original post by Pascalix

Beware of the sign. The normal vectors point outwards, so a point is in the frustum if the point’s distances are all negative.

Actually the normals point inwards, so a negative sign
would mean that the point is outside the visible frustum.

--

md2ge:

Your code should work just fine, but I hope you are aware that you would get a FOV of 124 degrees on the width. (if ar = 1.33)

No I''m not aware =) Now I''m a bit confused, are you saying I can''t have an fov of 110 and an aspect ratio of 1.33 at the same time? When I say fov 110 I mean the value I setup my projection matrix with, same for the aspect ratio.

If this can''t be done then I''ll just leave the aspect ratio alone and use 1.0, at least this way I can use any FOV I want.

Not sure how you arrived at 124 I thought I was setting fovy and fovx for 110 degrees, I guess I have to compensate fovx somehow, no idea.

Thanks,
Rick

quote: Original post by md2ge

No I''m not aware =) Now I''m a bit confused, are you saying I can''t have an fov of 110 and an aspect ratio of 1.33 at the same time? When I say fov 110 I mean the value I setup my projection matrix with, same for the aspect ratio.

If this can''t be done then I''ll just leave the aspect ratio alone and use 1.0, at least this way I can use any FOV I want.

Not sure how you arrived at 124 I thought I was setting fovy and fovx for 110 degrees, I guess I have to compensate fovx somehow, no idea.

Thanks,
Rick

No that wasn''t what I was saying. You can have FovY at 110 and aspect ratio to 4/3, it''s just that it is a rather large FOV and it might not look very good.

How I came up with 124?

float fov = 110.0f;
float ar = 1.33f;

float fovy = D3DXToRadian( fov / 2.0f );
float fovx = (float)atan(ar*(float)tan(fovy));

Your fovx will be 62.3 degrees (1.09 radians), that means that you have a FOV of 124 degrees on the breadth. Which is just what it should be. If the viewport isn''t square then the FOV on the breadth and height shouldn''t be the same, or your renderings will appear flattened.





- WitchLord

Heh this is kind of funny =) I don''t know why I''m having such mental block with this!

Basically if I use this formula:

float fov = 110.0f;
float ar = 1.33f;
float fovy = D3DXToRadian( fov / 2.0f );
float fovx = (float)atan(ar*(float)tan(fovy));

And use fovy and fovx to calculate the normals I dont get accurate results, the point I''m checking escapes the side planes and is not detected inmediately (due to the fov being 124 I suppose), so how do I modify the above so that I can use any fov with any aspect and get an accurate result? The above works fine, only if I use an aspect ratio of 1.0

Maybe I could set the projection to fov 124 but "pretend" it''s 110 and use 110 as the basis for fovy and fovx calculations? But that will probably mess up the fovy? Gonna go try.

If you don''t see what I''m doing wrong don''t worry about it, I really appreciate all your help =) If I can''t get it fixed I''ll just limit the thing to an aspect ratio of 1.0, no biggie.

Rick

Well, I really can''t see where you could go wrong. The formula you''re using is correct, unless I have made and continue to make a big mistake.

My guess is that your problem is somewhere else.

- WitchLord