How to implement a rendering system
Author
I was wondering how I could implement a simple rendering system for my engine. I hadn't actually given a lot of thought to it until I started coding it. I want to be able to support occlusion/frustum culling, particle effects, shadow volumes, etc. So, I was considering a simple system where a client wanting to render a mesh would call a function that adds a render request (mesh handle, position, orientation, etc.) to a queue, which is later processed for optimization and effects.
Any suggestion would be appreciated!
-- ProgrammerZ
I asked the same question some months ago, you can read some stuff up here
Since I want to do the same stuff as you, I can give you some advice.
I create a Renderer class that was responsible for rendering my scene. It works by using Rendernodes, that can be inserted by the game. The nodes contain information about what to render (pointer to the mesh (which consists of vertex- and indexbuffer), distance to the camera, material (textures), and various optional renderstates). The render class itself will then split the nodes up into different groups like opaque nodes, transparent nodes, and nodes that produce a glow, since they're all very different from another. When everything is done, the renderer sorts the list of nodes and then traverses every node in order to render it. I included a state-saving system in order to avoid API calls when rendering every node:
To make it easier to use different materials and combinations (like using a specular material that doesn't use a texture, but uses a bumpmap, etc..) I create an abstract base material with derrived classes for bumpmapping specularmapping etc...
The Renderer then needs to check which material has been attached to the node and then search the right shader/technique (I think you'll get the idea what to do, when you are there).
I know this is somewhat unordered :)
I can help you with the details, but the overall look of it should be clear.
Since I want to do the same stuff as you, I can give you some advice.
I create a Renderer class that was responsible for rendering my scene. It works by using Rendernodes, that can be inserted by the game. The nodes contain information about what to render (pointer to the mesh (which consists of vertex- and indexbuffer), distance to the camera, material (textures), and various optional renderstates). The render class itself will then split the nodes up into different groups like opaque nodes, transparent nodes, and nodes that produce a glow, since they're all very different from another. When everything is done, the renderer sorts the list of nodes and then traverses every node in order to render it. I included a state-saving system in order to avoid API calls when rendering every node:
typedef std::map<D3DRENDERSTATETYPE, DWORD> StateMap;StateMap m_RenderStates;HRESULT CRenderer::SetRenderState( D3DRENDERSTATETYPE type, DWORD state ){ // Look for this specific renderstate StateMap::iterator i = m_RenderStates.find( type ); // If it is not there, insert it into the map if( i == m_RenderStates.end() ) { m_RenderStates.insert( std::pair<D3DRENDERSTATETYPE, DWORD>( type, state ) ); return g_pd3dDevice->SetRenderState( type, state ); } // If this state is already set, return OK and do nothing DWORD _state = i->second; if( _state == state ) return D3D_OK; // This renderstate has been set, but with another flag // So we erase the old one, insert the new one and finally set the renderstate m_RenderStates.erase( i ); m_RenderStates.insert( std::pair<D3DRENDERSTATETYPE, DWORD>( type, state ) ); return g_pd3dDevice->SetRenderState( type, state );}To make it easier to use different materials and combinations (like using a specular material that doesn't use a texture, but uses a bumpmap, etc..) I create an abstract base material with derrived classes for bumpmapping specularmapping etc...
The Renderer then needs to check which material has been attached to the node and then search the right shader/technique (I think you'll get the idea what to do, when you are there).
I know this is somewhat unordered :)
I can help you with the details, but the overall look of it should be clear.
I also started with the idea of making a base material class, but really disliked having to code up an entirely new derived class any time I wanted to add an effect variable. There could potentially be 50+ in my full fledged game idea. So I went the route of trying to make a single class that can contain various types.
I basically insert and remove material attributes by name and value
I create an std::map for each type of effect variable I'll deal with.
Right now just a map of floats, d3dxvectors, d3dxmatrix, bools, and texture resources.
I did make concrete light classes and though since those attributes shoudn't change.
I give those materials to an effect class. The effect class has also compiled the effect and queried it for its variables, so the effect class also has a unique set of effect varibales in its maps which correspond to the value attributes in the material class. The names match as I have my effect class generate a meterial and then give it to the app to have its values set and given back. That way I have one material and one effect class that can handle any effect.
I put the non material stuff into an effect pool so it only has to be changed once per frame instead of every object. Thats where the lights and render matrices go in a concrete format.
I plan to make my meshes, which will be aggregates of a mesh hierarchy class, each contain the name if the effect it uses and its current material values.
The idea is to seperate what the app has access to (material attribute) and the DirectX portion (the effect). Most people say "look at the open source engine", well I did. It seems they mostly implement a set in stone effect and a set in stone material. I want my app to have the freedom of adding effects without having to go create more engine code.
[Edited by - brekehan on October 16, 2008 9:27:27 PM]
I basically insert and remove material attributes by name and value
I create an std::map for each type of effect variable I'll deal with.
Right now just a map of floats, d3dxvectors, d3dxmatrix, bools, and texture resources.
I did make concrete light classes and though since those attributes shoudn't change.
I give those materials to an effect class. The effect class has also compiled the effect and queried it for its variables, so the effect class also has a unique set of effect varibales in its maps which correspond to the value attributes in the material class. The names match as I have my effect class generate a meterial and then give it to the app to have its values set and given back. That way I have one material and one effect class that can handle any effect.
I put the non material stuff into an effect pool so it only has to be changed once per frame instead of every object. Thats where the lights and render matrices go in a concrete format.
I plan to make my meshes, which will be aggregates of a mesh hierarchy class, each contain the name if the effect it uses and its current material values.
The idea is to seperate what the app has access to (material attribute) and the DirectX portion (the effect). Most people say "look at the open source engine", well I did. It seems they mostly implement a set in stone effect and a set in stone material. I want my app to have the freedom of adding effects without having to go create more engine code.
[Edited by - brekehan on October 16, 2008 9:27:27 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
