ftyou at June 9th, 2010 15:36 — #1
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
jarkkol at June 9th, 2010 15:56 — #2
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.
ftyou at June 9th, 2010 16:06 — #3
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 ...
jarkkol at June 9th, 2010 16:11 — #4
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 (:
reedbeta at June 9th, 2010 16:23 — #5
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.
ftyou at June 9th, 2010 16:40 — #6
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 :
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 ?
jarkkol at June 9th, 2010 18:14 — #7
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.
reedbeta at June 9th, 2010 18:15 — #8
I was suggesting a structure like:
list of materials:
vertices: vertex1, vertex2, ...
triangles: triangle1, triangle2, ...
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.
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.
jarkkol at June 9th, 2010 18:48 — #9
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.
ftyou at June 9th, 2010 18:49 — #10
will working on it. Thanks