Scene Management

rated by 0 users
This post has 3 Replies | 2 Followers

Top 500 Contributor
Posts 7
SunBurn_Pro_Licensee
Tryz Posted: 03-02-2009 9:02 PM

I believe I've read through all the documents, so I don't think this is discussed elsewhere...

Can you describe how the RenderManager is managing the scene?  I'm curious about what SunBurn is doing vs. what I should be doing.

In the past, I've used a quad-tree to manage the objects and then tested visibility of objects in the local cell against the camera frustum.  Is the RenderManager doing this when I use 'SubmitRenderableObject' and ObjectLifeSpan.Scene?

My existing project is a forest with about 1,000 trees.  Most of them being billboards.  Should I let SunBurn manage these or should I do it?

Thanks

(PS.  I got a simple app up and running with lights and shadows in less that 10 minutes.  Great stuff!)

Top 10 Contributor
Posts 765
Employee
SunBurn_Studio_Licensee

Hi Tryz,

The render manager is doing similar scene objects management.  It uses a simplified oct-tree to organize scene objects as they are submitted, it then locates the best objects for the view during BeginFrameRendering.  The light manager offers the same management of scene lights.

 

How are your billboards handled - are they billboarded using the world transform for each image (or a cluster of them)?  How are the mesh LODs reduced and then billboarded - are they handled in the Draw calls by rendering different sections of the vertex buffer?

Top 500 Contributor
Posts 7
SunBurn_Pro_Licensee

Thanks for the response.  It sounds like I should let SunBurn handle the scene managment as much as possible.

 

I'm using hardware instancing on the billboards.  I've created a simple panel with 4 vertices.  I pass this as one stream and another stream containing instance data such as world position, uv coordinates, width, etc.  The shader than positions the panel in the world and faces it towards the camera. 

In a previous post I saw, it looked like the SunBurn shaders could handle this as long as the resulting vertex streams are merged to the right semantics.  For billboards, I end up with 2 positions.  1 for the vertex local to the billboard and one that represents the world position of the instance.   I'm guessing this is what will be an issue.

 

I've created my own "LODModel" class.  You can add "levels" to it.  The first level is typically the detailed tree model.  The next level is a less detailed model (totally different vertex buffer).  Then, a billboard that changes what image to display based on the angle you're viewing the tree.  Lastly, a simple static billboard of the tree.

Once my scene manager determines the instance should be drawn, the "LODModel" class determines which level to use based on the distance to the camera.  It either pushes an instance to the model stack or the billboard stack, depending on the level.  Each level is really treated like a totally seperate model.

Once all the visible objects have been accounted for, the model manager renders everything on the stack using hardware instancing if it can or simple draw calls.  The billboard stacks are always hardware instanced.

Hopefully this makes sense.

 

My guess is that the SunBurn shaders are looking for a specific set of semantics POSITION0, NORMAL0, etc.  The fact that I'm using HI is probably going to through off the standard shaders (?)

Top 10 Contributor
Posts 4,854
Employee
SunBurn_Studio_Licensee

Tryz:

For billboards, I end up with 2 positions.  1 for the vertex local to the billboard and one that represents the world position of the instance.   I'm guessing this is what will be an issue.

My guess is that the SunBurn shaders are looking for a specific set of semantics POSITION0, NORMAL0, etc.  The fact that I'm using HI is probably going to through off the standard shaders (?)

Hi Tryz,

That's correct, the built-in shaders take the vertex buffer coord, normal, uv, bone-index, and bone-weight channels and transform them by the world, view, projection, and bone-array transforms (the bone data is only used when the effect's Skinned property is true).  To be compatible with the built-in shaders, custom shaders need to perform the same vertex transforms.

There are some ways to do rendering similar to billboarding and instancing using the built-in shader processing.  A few we would probably try in our own projects are:

  • add close clusters of trees (which will lod together) to the same vb/ib using positions and normals that are in the same object space - we actually try to do this when modeling by collapsing close meshes that share the same materials to reduce the overhead of draw calls and transform changes (note this wouldn't allow easy billboarding as changes to the world transform to create billboarding wouldn't affect each billboard independently)
  • billboard individual objects using a world transform rotated towards the camera
  • combination of the other two - put several objects into the same vb/ib, but keep them in their own object space and include the bone index and weight vertex channels - with each object assigned its own bone in the bone transform array which contains its object transform (including any billboarding rotation).  This would allow a type of instancing and independent billboard transforms per object.

These are just a few ideas that might help out.

 

Whether or not to use the render manager is a complex question.  There are two things to keep in mind: the render manager often needs access to objects outside of view for shadow generation, and it has no concept of your lods so you'll need to add the object lod per-frame but there is an overhead when submitting objects to the render manager (as they're added to the internal oct-tree - even though you've already determined the objects are visible).

On the other hand your scene graph sound very robust and highly tailored to your project.  If the scene graph can provided lists of renderable objects based on arbitrary views, then it might be better to try and couple it with the custom renderer example - and have it retrieve renderable objects for the main rendering loop, and again for the shadow rendering.

Let me know if this makes sense or if I can clarify anything!

Follow me on Twitter – development and personal tweets
Awesome XNA Videos – Lighting, Rendering, and game videos

Page 1 of 1 (4 items) | RSS