6 replies to this topic

[space_cadet]

I am implementing a screensaver - a starfield made out of cubes that move towards the viewer in 3D space:



I place the camera away from the origin along the z-axis, generate the cube objects at the origin with random x and y values, and move the cubes towards the viewer along the z-axis.

Naturally, the more cubes I have, the more calculations I have to perform. Therefore I would like to reset any cube as soon as it is outside the screen boundaries, so I can reuse it and restart it at the origin.

I have read lighthouse3d's excellent tutorial about view frustrum culling, but I believe there must be a more efficient way for my special case. The best I came up with was taking the center point of each cube [0,0,0], multiply it with the model-view-projection matrix (which is cheap, because I have that matrix already), transform its x and y values into device coordinates (dividing them by w) and see if either one is smaller than -1.0 or greater than 1.0.

This is quite effective, but of course the cubes disappear as soon as their center is outside the screen boundaries, while I would like them to be completely outside before disappearing.

[Lightness1024]

just keep your point method, and multiply the result by 0.9 or something so that you effectiveley increase the virtual size of your screen and the cubes will pop away after they pass the border region.

[Lauris Kaplinski]

What's wrong with the following method?

1. Extract the frstum sides (4 planes) - one-time operation
2. Find the distance of cube center from all planes (4 x cheap operation)
3. If any distance is > diagonal/2 discard that cube

It may have few extra operations compared to your method and it slightly overestimates cube size but I doubt any of these are serious problems.

If you want the absolute least amount of tests and your cubes have linear trajectories then precalculate the time when they go offscreen (using either the above method or the exact method), store the value for each generated cube and discard these as soon as the system time will become greater than their lifetime.

[Seabolt]

Well if you're using only cubes, you can just check based on the center plus half the width of a face, making it a pseudo bounding sphere check.

[space_cadet]

just keep your point method, and multiply the result by 0.9 or something so that you effectiveley increase the virtual size of your screen and the cubes will pop away after they pass the border region.

No, I believe that would not work properly for all cases.

Well if you're using only cubes, you can just check based on the center plus half the width of a face, making it a pseudo bounding sphere check.

I think it would have to be diagonal / 2, but in principle, that is what I had in mind. But how much is diagonal / 2 in normalized device coordinates?

What's wrong with the following method?

Actually, I think you may be right. I thought the distance calculation was a bit expensive, but I had a closer look and it's just a few multiplications and additions.

[Trienco]

If you are really worried about a few operations more or less, you can also look at this: http://www.lighthouse3d.com/tutorials/view-frustum-culling/radar-approach-testing-points/ and use the sphere version. Though I have yet to see any performance difference worth mentioning.

[clb]

What I would do is I'd compute the out-of-screen check in 2D using bounding spheres instead of the cubes.

Offline: Compute the bounding sphere of the cube (the radius of the sphere that encloses the whole cube)

Online:
1. Transform the center point P of the cube to 2D screen coordinates P'.
2. Transform the radius R of the bounding sphere at the distance of the cube to 2D screen coordinates R'.
3. Compare if the 2D point P' is farther than R' outside of one of the four edges of the screen and if so, discard it.

This method should be considerably more lightweight than SAT of 3D AABB vs 3D frustum.

Another even simpler method would be to just check when the cube passes the camera near plane, and kill it there.