Scene managment and graphic rendering
Posted 09 June 2010 - 07:36 PM
I'm wondering if someone can help me to reorganize my idea about graphic rendering.
In fact i was thinking on how i can efficiently build up a good architecture for static and dynamic objects rendering.
For now, i have the idea to split the problem in two part.
1) For static object, i manage to create an octree.
Every node hold a list of triangle. With this , i can on pre-rendering build an octree that take every triangle in the scene and fill every node with the corresponding triangle. The question is how and where i can hold the informations about the vertex ...
-> If the node hold triangle = 3 vertex position information, that is suffisant for computing the location in the octree.
The first idea i had, is to keep in a triangle a pointer to the material and shaders informations. But i can't be more accurate than a triangle. In this way i can't compute a color/material/shaders for one vertex in the triangle. So i can keep in vertex a pointer to color/shaders/ material ? It's seem to be very hudge for large scene.
Moreover, i would to sort by shaders all triangle for rendering but if for exemple a bomb explose near a wall (wall triangle are already uploaded in graphic card) the shaders affect to the wall must be replaced by the bomb information for light computing. I need to change the shaders so reorganize the sorting i made before...
I'm really confused and i need your help...
basically i want someone give me an architecture (or a start ) to manage static object and dynamic. I want to be able to change when i want the material/ color/ shader of a vertexat any time if i need the fastest way i can. Or basically someone explain me how ogre or irrlicht do this job because i read a lot of code and it is hard to keep the things i'm looking for.
Thansk for any help
Posted 09 June 2010 - 08:06 PM
Posted 09 June 2010 - 08:23 PM
As for supporting things like a bomb exploding and leaving a mark on a wall, that sort of thing is commonly done with "decals", which are additional polys constructed and added by the engine in real time. You can make an alpha blended blast mark texture and render it transparently over the wall, with the polys placed against the wall so it looks like a mark on the wall. Google can tell you more.
Posted 09 June 2010 - 08:40 PM
"You probably shouldn't have a material pointer in each triangle or each vertex; instead have a list of materials in each octree node and a vertex buffer that goes with each material."
Sorry but i don't understand very well what you are saying. Need i have a pointer on a material for each vertex or not?
I understand when i have a loader or something like this that transpose vertex information in engine informaration. But imagine this case :
affect Cube in Octree
affect Sphere in octree
Actually the create and affect or outside the rendering loop, it is the construction phase. So the octree is build "dynamically". So what kind of structure need i have to build what i want --> do i have a vertex structure that hold position / material / shaders / normal etc ... Or triangle structure that hold position ( for 3 vertex ) material (for all vertex ) etc .. or an object that hold a list of triangle. Because if the octree split one triangle how can handle that ?
Can you give me a simple example of structure to adopt ?
Posted 09 June 2010 - 10:14 PM
Posted 09 June 2010 - 10:15 PM
octree node: list of materials: material 1: vertices: vertex1, vertex2, ... triangles: triangle1, triangle2, ... material 2: vertices: vertex1, vertex2, ... triangles: triangle1, triangle2, ... ...
But if you're creating things dynamically and letting the user move them around it's probably better to use an object-based loose octree like JarkkoL said. The octree with triangles in it is more appropriate when you have a lot of geometry that you're building ahead of time.
True, if you have lots of instancing as in a city or forest that's a very valid point. I guess I was thinking more along the lines of a terrain or something.
Posted 09 June 2010 - 10:48 PM
Most likely different objects also use different materials so if you think that there would be some kind of performance improvement when materials are shared between objects and you could kick them to the HW with single DIP call, but in practice that's unlikely. More likely is the case that same object is visible several times in the same frame and you can kick those all instances to the HW with single DIP using instancing.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users