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!)
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?
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 (?)
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 (?)
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.
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:
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 tweetsAwesome XNA Videos – Lighting, Rendering, and game videos