Sign in to follow this  
assainator

RenderManager questions

Recommended Posts

Hello everyone,

Lately, I've been running into several design issues with my 'RenderManager'. Therefore I would like to ask how you tackle certain things.

First let me explain something about my RenderManager:
- Mostly shader driven (Vertex and pixel shaders only)
- Objects stored in VBO's on the GPU
- Every object can only have a single texture.

First Question:
What information do you pass to your RenderManager? Just the VBO-ID, RenderPrimitive, texture, position and rotation of every object or do you send a lot of descripting data along? If so, what data would that be?

Second question:
If you have some asset data, say a mesh. Do you load the file into memory, transfer it to the GPU (VBO) and free the memory or do you have a different approach?

I thank you all in advance,
assainator

Share this post


Link to post
Share on other sites
I found the best source of information for this kind of thing were [url="http://www.gamedev.net/topic/604899-frostbite-rendering-architecture-question/"]this[/url], [url="http://www.gamedev.net/topic/602839-whats-the-point-of-having-a-single-render-device/"]this[/url], and [url="http://www.gamedev.net/topic/605065-renderqueue-design-theory-and-implementation/"]this[/url]. Take note of the posts by Hodgman they are really informative.

Share this post


Link to post
Share on other sites
As for the first question. The rendering mechanism I use (for now) is a part of my engine and I'm afraid it's just a single function with render list of objects to be rendered.

[QUOTE]
If you have some asset data, say a mesh. Do you load the file into memory, transfer it to the GPU (VBO) and free the memory or do you have a different approach?
[/QUOTE]

I built an "assetManager" object that loads all assets at initialization from files on the disk. The assets (depending on the ID) are then placed in model objects along with points and u,v coordinates and texture_id for each point.

I can then ask the "assetManager" object to create each of the objects I need (and are already loaded).
This way objects are loaded only once for each model and created as a copy of the template model.

i.e. I want 10 building objects. I ask "assetManager" for 10 new buildings, set their position on the scene, put them in the render list and viola I have 10 objects at the price of one.
That's the theory anyways.

Share this post


Link to post
Share on other sites
Second question: If the vertex/index buffer or texture is created as set-only, you have no reason to keep them in memory unless it is DirectX 9 and you stored them in the default pool (which you generally don’t do).
Free them after submitting the graphics API.


L. Spiro

Share this post


Link to post
Share on other sites
I've incrementally transitioned to an high level renderer (which I suppose it's your [font="Courier New"]RenderManager [/font]without the 'smart' management).
[quote name='assainator' timestamp='1318448017' post='4871959']
(1) What information do you pass to your RenderManager?
(2) If you have some asset data, say a mesh. Do you load the file into memory, transfer it to the GPU (VBO) and free the memory or do you have a different approach?[/quote]
[size="3"]- When it comes to me (I'm not saying this is best or suggesting you to do the same) -[/size]

[b][size="2"](1) [/size][/b]Material to use, material-instance information blob and input-assembly setup (but that's likely going away in some future iteration).
The material-instance blob is currently a list of [font="Courier New"]ParameterFetcher [/font]objects fetching the data (can pull out data from scripts, set uniforms and textures). Building those fetcher objects is pretty involved and managing them has proven more difficult than predicted.
When it comes to you, I'd like to stress the fact that I allow "opaque" per-material settings with basically no limitation in line of concept. Your notion of "having a single texture" seems short-sighted at best. Plan to iterate soon.

[size="2"][b](2) [/b][/size]Graphics data is fetched to GPU and typically disposed immediately. In some cases, this is kept in memory, if per-triangle accurate collisions are requested. Keep in mind a mesh is typically much more than just graphics data, an approximated collision mesh will often be provided as well and must be retained, instanced and transformed correctly.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this