Render Queue Woes
Author
Hello.
I have all of my plans for my render queue ready except for one detail. When should I cull the objects (consider that a single full-screen render may involve multiple cameras to allow effects such as shadow-maps and “video” textures)?
There are 2 options I can see:
#1: I cull before I submit them to be rendered. This allows me to take advantage of bounding-volume hierarchies so I can avoid testing objects if their parents already failed testing. But I need to know which camera will be used for the render before I submit.
#2: Submit everything that is visible and then cull each object one-by-one for each camera that will be used for that render. Objects will be linear in organization by the time they are culled, so culling a parent no longer automatically culls its children, and there is no efficient way to step down BVH’s. However the rendering engine can use this master list to automatically do all “special” renders needed to generate shadow-maps etc.
#3: A hybrid approach. Please explain.
Basically my goal is that the game should simply submit graphics to be rendered with as little effort as possible. If I take approach #2, this is achieved, but it will be much slower at culling objects from view.
If I take approach #1, I have to somehow install callbacks into the graphics engine so that it can get a new list of culled objects when it needs to make a render to a shadow texture or anything else aside from the camera I intend to use for the main render. This seems cumbersome and I think it will make the engine a pain to use.
What are your suggestions?
Regards,
L. Spiro
There's two steps for getting the geometry queued.
1.) Registration
2.) Enqueueing
Registration happens when a renderable is inserted into a scene. It's added to a spacial structure and any other system that wants to know about it.
Enqueuing happens when a pass is requested with a given set of parameters, one being the view and projection transforms.
It is during enqueuing that IMO the view culling should take place. Enqueueing is essentially walking your spacial structure looking for visible renderables, so the view culling can be performed at a higher level than model in most cases (tree structure).
After you've populated your queue, you sort it and start munching away.
Note the same renderable may be Registered with multiple scenes. Therefore it's likely to be engueued and view culled more than once per frame.
1.) Registration
2.) Enqueueing
Registration happens when a renderable is inserted into a scene. It's added to a spacial structure and any other system that wants to know about it.
Enqueuing happens when a pass is requested with a given set of parameters, one being the view and projection transforms.
It is during enqueuing that IMO the view culling should take place. Enqueueing is essentially walking your spacial structure looking for visible renderables, so the view culling can be performed at a higher level than model in most cases (tree structure).
After you've populated your queue, you sort it and start munching away.
Note the same renderable may be Registered with multiple scenes. Therefore it's likely to be engueued and view culled more than once per frame.
Author
Thank you. I have to make some modifications to suit some of the needs of my engine, but overall that is all the input I needed to decide how to proceed.
L. Spiro
L. Spiro
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
