Jump to content
  • Advertisement
Sign in to follow this  
L. Spiro

Render Queue Woes

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

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!