RenderManager questions

I found the best source of information for this kind of thing were this, this, and this. Take note of the posts by Hodgman they are really informative.

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.

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.

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

I've incrementally transitioned to an high level renderer (which I suppose it's your [font="Courier New"]RenderManager [/font]without the 'smart' management).

(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?

- When it comes to me (I'm not saying this is best or suggesting you to do the same) -

(1) 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.

(2) 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.

Thanks to all of you. You've provided me with something to think about the comming week.