Scene managment and graphic rendering

9137f0bd6d99129577098d910cfc8294
0
ftyou 101 Jun 09, 2010 at 19:36

Hi there !

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

9 Replies

Please log in or register to post a reply.

Fe8a5d0ee91f9db7f5b82b8fd4a4e1e6
0
JarkkoL 102 Jun 09, 2010 at 19:56

Usually you don’t organize geometry in triangle level but in object level. Then use loose octree or something like that for quick culling of dynamic & static objects.

9137f0bd6d99129577098d910cfc8294
0
ftyou 101 Jun 09, 2010 at 20:06

I don’t use loose octree for now. I try something more simple. But yes later i will implement loose octree. the problem in object level is for splitting object into two node (if the object can’t share the two node because of size) you can’t run a function that efficiently split the right triangle. And even if you can, you have two object with the same material shader colors to handle …

Fe8a5d0ee91f9db7f5b82b8fd4a4e1e6
0
JarkkoL 102 Jun 09, 2010 at 20:11

Loose octree is probably simplier to implement. You just put the object into node where the object centerpoint lies without splitting/duplication. Anyway, your call (:

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Jun 09, 2010 at 20:23

For static geometry it can be useful to merge it all together and put it one big octree with triangles in the nodes. Usually you would have your exporter or art compiler build the octree and save it out in a game-ready format. As for the organization of the data, I made a suggestion in your previous thread about how to store the vertices. 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.

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.

9137f0bd6d99129577098d910cfc8294
0
ftyou 101 Jun 09, 2010 at 20:40

Thank you for the reply.

“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 :

CreateCube()
affect Cube in Octree

CreateSphere()
affect Sphere in octree

render()

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 ?

Fe8a5d0ee91f9db7f5b82b8fd4a4e1e6
0
JarkkoL 102 Jun 09, 2010 at 22:14

@Reedbeta

For static geometry it can be useful to merge it all together and put it one big octree with triangles in the nodes.

Not really. Most of the time geometry is reused throughout the level. E.g. a tree object is used like in 100 places in the level thus you don’t want to store triangles (and duplicate geometry), but references to the objects into the octree.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 167 Jun 09, 2010 at 22:15

I was suggesting a structure like:

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.
@JarkkoL

Most of the time geometry is reused throughout the level. E.g. a tree object is used like in 100 places in the level thus you don’t want to store triangles (and duplicate geometry), but references to the objects into the octree.

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. ;)

Fe8a5d0ee91f9db7f5b82b8fd4a4e1e6
0
JarkkoL 102 Jun 09, 2010 at 22:48

You don’t even need lots of instancing. If your object is used even twice within the level, using objects instead of triangles already halves the memory budget for that object. For completely unique geometry, like in case of terrain you mentioned, it would have the same overhead, but even then why would you use special case for that case when you could just use the same object level approach like for everything else. Then everything goes through the same asset management, streaming, etc.

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.

9137f0bd6d99129577098d910cfc8294
0
ftyou 101 Jun 09, 2010 at 22:49

will working on it. Thanks