7.8 C
New York
Friday, November 25, 2022

How to know what to render? – Graphics and GPU Programming – GameDev.net

Please contact us if you have any trouble resetting your password.
Hello,
I have a simple question: How do I know, which objects I have to render, when I have a frustum set up?
Background to my understanding:
So far I have a matrix and a vector class. I want to write a simple renderer with C and SDL2. I know how to project points from within the frustum onto its near plane (screen coordinates). At this point I’m wondering about the above question. I could just manage a list of all meshes/objects and check, whether they’re within the frustum or outside, but that can’t be the right way can it? Since the list might grow very very huge.
Any hints?
What I’ve seen done in another engine, I believe, is to keep a tree of objects, and to have for each node in the tree a set of bounds that encompasses the bounds of all nodes below it.
This allows one to start one’s culling at the base of the tree and work one’s way through it, only moving down a branch if the bounds of the current node are found to overlap the frustum. (After all, if the bounds of a given node, which encompass the bounds of the nodes below it, doesn’t overlap the frustum, then the bounds of those lower nodes presumably won’t overlap either.)
This potentially allows one to exclude large portions of the scene early in the process, thus potentially significantly reducing the number of elements to be considered.
MWAHAHAHAHAHAHA!!!
My Twitter Account: @EbornIan
While a tree-based solution as suggested above is more optimal than checking every object in an asymptotic sense, O(logN) instead of O(N), the tree will have a high constant overhead due to the management overhead associated with maintaining the tree. In fact maintaining the tree may be O(N) anyway, because you need to check if every object has moved.
I would bet that brute-force culling will win over a tree until the number of objects gets in the 10,000+ range. Culling is just point-vs-plane distance tests, which are just a few instructions per plane using SIMD. Unless you already have a tree structure for some other reason, I’d advise to stick to brute force culling for its simplicity and speed for typical numbers of objects.
hypersleep said:
I know how to project points from within the frustum onto its near plane (screen coordinates).
But this is not how you (usually) do frustum culling. It’s more common to have a bounding volume per object (oriented bounding box, axis aligned bounding box, or bounding sphere), and testing this to be inside or intersecting the frustum pyramid. There are some variants of such test easy to find, e.g. this: https://iquilezles.org/articles/frustumcorrect/
Aressera said:
While a tree-based solution as suggested above is more optimal than checking every object in an asymptotic sense, O(logN) instead of O(N), the tree will have a high constant overhead due to the management overhead associated with maintaining the tree. In fact maintaining the tree may be O(N) anyway
Because of that, you may use a tree (likely a BVH) only for the static world, so no need to update it, and brute forcing the dynamic objects.
Or you have other uses for the tree es well so the cost is worth it, e.g. collision detection, range queries for AI, etc.
If your object count is really huge, you might want to do it on GPU anyway, see ‘GPU driven rendering’.

source

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles