Model and geometry information hierarchy
Author
I am trying to determine what is the best hierarchy for storing my geometry and material information, but I feel like I keep going round and round on this.
Here is some background. I have a model with a collection of meshes. Each mesh represents one material and has a set of indices. So in theory, draw calls will take place per mesh if the mesh is not culled at all.
Culling, on the other hand, takes place at the bone level. So for instance, each bone will have a set of indices that belongs to it. Each bone will have a bounding mesh and those bones will be culled based on that. There will be subbones as well if there is too many vertices associated to one bone. So it is possible that only part of a bone is culled.
My problem is that I am not sure how to relate the bone indices to the mesh indices.
Lets take an example. Lets say that we have a man with a short sleeve shirt on. The sleeve goes halfway down the upper arm bone. So for one bone, there is 2 meshes. The sleeve/shirt mesh for the first half of the upper arm and a skin mesh for the second half of the upper arm. Lets say that part of the arm gets culled. So some indices of the bone gets removed. What is the best way to relate the indices of the bone back to the indices of the meshes?
I am not sure if I am making a lot of sense. It could be that I am overly complicating my problem. Maybe bones should not cross the mesh boundary. Meaning there is at max only one mesh per bone or maybe when I subdivide the bone, I should first divide on the mesh boundaries.
Please help!!! Thanks.
Quote:Culling, on the other hand, takes place at the bone level.Yikes. Why would that be a good idea?
Author
Quote:Yikes. Why would that be a good idea?
OK, so, maybe I should be asking a different question. Lets say you have a model that is animated. In certain animations, the bounding box would be smaller (say if it is a human and he has his arms by his side) and sometimes it would be larger (say if he had his arms fully stretched out). What bounding box do you use? Do you have a bounding box for each frame? That is a lot of data to keep. Do you always use the largest? That is highly inaccurate especially on large animations such as super unfolding tentacles. Or do you calculate the bounding box on the fly? That can be very computationally intensive.
What is the better solution to this problem?
To expand on what Sneftel said, culling is usually done on the object level, or at the lowest, on the level of each set of polygons rendered with the same state.
Since the arm and its culled part are part of one set of polygons with the same renderstate, it would be inefficient to recompute the indices, with or without bone index and weighting information. It would be more efficient simply to render the entire arm.
Also consider that culling part of the arm would require more narrow-phase occlusion detection, something which would slow down the CPU more than it would speed up the GPU.
Regarding bounding boxes, I usually keep an "collision skin" consisting of collision shapes (not meshes but boxes, capsule, cylinders, and convex hulls) which are attached completely to each bone. I then compute the bounding box of the transformed collision primitives, which is easier than computing the bounding box of the entire deformed triangle mesh. Thus, each bone has its own bounding box generated from its own collision skin components. This solution is especially attractive if you wish to integrate physics and ragdoll animation.
Since the arm and its culled part are part of one set of polygons with the same renderstate, it would be inefficient to recompute the indices, with or without bone index and weighting information. It would be more efficient simply to render the entire arm.
Also consider that culling part of the arm would require more narrow-phase occlusion detection, something which would slow down the CPU more than it would speed up the GPU.
Regarding bounding boxes, I usually keep an "collision skin" consisting of collision shapes (not meshes but boxes, capsule, cylinders, and convex hulls) which are attached completely to each bone. I then compute the bounding box of the transformed collision primitives, which is easier than computing the bounding box of the entire deformed triangle mesh. Thus, each bone has its own bounding box generated from its own collision skin components. This solution is especially attractive if you wish to integrate physics and ragdoll animation.
Author
so you do compute the transformed bounding box at the bone level, but you do not use it for culling, only for physics? Did I understand that correctly?
If so, do you use the bone bounding boxes to compute the objects bounding box on the fly for culling purposes? Or do you possibly cull at the bone level using the bounding box of the bone (which is what i was asking about but maybe didn't explain very well. The only difference is that I was not limiting it to a box. The bounding mesh would be a simplified mesh compared to original, but would have a variable amount of vertices depending on accuracy versus computation needs.)
If so, do you use the bone bounding boxes to compute the objects bounding box on the fly for culling purposes? Or do you possibly cull at the bone level using the bounding box of the bone (which is what i was asking about but maybe didn't explain very well. The only difference is that I was not limiting it to a box. The bounding mesh would be a simplified mesh compared to original, but would have a variable amount of vertices depending on accuracy versus computation needs.)
I'm reusing the collision information for both physics and per-object culling.
It appears that you have difficulty communicating what you visualize (it happens a lot when explaining this in real life), so I'll illustrate the pipeline:
Artist creates model and submeshes-->Artist attaches collision primitives to bones (only one bone per collision primitive)-->Model displayed in game-->animation engine computes bone poses-->for each bone, transform attached collision primitives-->for each bone, construct bounding box from transformed attached collision primitives-->optional: for each submesh, construct bounding box from bounding box of all bones to which it is weighted-->final: for each object, construct bounding box from bounding box of all bones.
If you implemented the optional step, you can cull per submesh(continuous set of polygons with one material). If you did the traditional way, you can cull per object with the bounding box for broadphase culling and collision. NEVER cull "per bone" only per submesh or per object.
Your simplified bounding mesh fulfills the same role as my collision primitives, but you can only have one bone for each collision primitive. A simplified bounding mesh (AKA low LOD mesh) can come in handy, but only if you implement dynamic occlusion culling through rasterization. For schemes such as portal culling and frustum culling, skinning a simplified bounding mesh is too much trouble.
I reiterate what Sneftel said: NEVER cull per bone. Only per submesh or per object.
[Edited by - JDS0 on October 15, 2009 10:31:00 AM]
It appears that you have difficulty communicating what you visualize (it happens a lot when explaining this in real life), so I'll illustrate the pipeline:
Artist creates model and submeshes-->Artist attaches collision primitives to bones (only one bone per collision primitive)-->Model displayed in game-->animation engine computes bone poses-->for each bone, transform attached collision primitives-->for each bone, construct bounding box from transformed attached collision primitives-->optional: for each submesh, construct bounding box from bounding box of all bones to which it is weighted-->final: for each object, construct bounding box from bounding box of all bones.
If you implemented the optional step, you can cull per submesh(continuous set of polygons with one material). If you did the traditional way, you can cull per object with the bounding box for broadphase culling and collision. NEVER cull "per bone" only per submesh or per object.
Your simplified bounding mesh fulfills the same role as my collision primitives, but you can only have one bone for each collision primitive. A simplified bounding mesh (AKA low LOD mesh) can come in handy, but only if you implement dynamic occlusion culling through rasterization. For schemes such as portal culling and frustum culling, skinning a simplified bounding mesh is too much trouble.
I reiterate what Sneftel said: NEVER cull per bone. Only per submesh or per object.
[Edited by - JDS0 on October 15, 2009 10:31:00 AM]
Quote:Original post by landagenThe maximal bounding box.Quote:Yikes. Why would that be a good idea?
OK, so, maybe I should be asking a different question. Lets say you have a model that is animated. In certain animations, the bounding box would be smaller (say if it is a human and he has his arms by his side) and sometimes it would be larger (say if he had his arms fully stretched out). What bounding box do you use?
Quote:That is highly inaccurate especially on large animations such as super unfolding tentacles.If your game is intrinsically based around a large number of high-polycount squids hiding just around a corner from the player, this may be an issue to consider. Is that your situation?
As JDS0 said, collision is a completely separate concern from culling, and from rendering. The skeleton for the model used in culling is the same as the skeleton used for rendering, but the geometry is made up of solid primitives rather than triangles.
Author
Thanks for clarifying this for me. In the end, it seems I was trying to be too aggressive with my culling even though I don't even know for sure that I will need it. One follow up question though.
I now understand why you do not want to draw a part of a submesh. It is best to draw the whole thing or none of it because working out the indices can be time consuming for the cpu and complicated for the programmer. I was thinking of having a list of associated submeshes per bone. For instance, bone #1 might have part of mesh #1 and mesh #2. If all bones that have mesh #1 associated with it are not visible, then mesh #1 would not be visible and would not be drawn. This would save you from having to calculate the transformed mesh and would still not cause me to have to recalculate indices for the meshes. Is the reason for not culling on bones because there are too many bones in 1 object and thus too much to cull or is it because of the worry of having to recalculate indices because submesh boundaries do not necessarily follow bone boundaries. Or, would it be faster to just calculate the transform of the mesh based on bone bounding boxes. I should note that I plan on doing the actual bone vertex transformation on the GPU.
Also, I am thinking of limiting the bones to cull on based on major bones (such as arm and leg) and eliminating minor bones (facial bones for instance).
I now understand why you do not want to draw a part of a submesh. It is best to draw the whole thing or none of it because working out the indices can be time consuming for the cpu and complicated for the programmer. I was thinking of having a list of associated submeshes per bone. For instance, bone #1 might have part of mesh #1 and mesh #2. If all bones that have mesh #1 associated with it are not visible, then mesh #1 would not be visible and would not be drawn. This would save you from having to calculate the transformed mesh and would still not cause me to have to recalculate indices for the meshes. Is the reason for not culling on bones because there are too many bones in 1 object and thus too much to cull or is it because of the worry of having to recalculate indices because submesh boundaries do not necessarily follow bone boundaries. Or, would it be faster to just calculate the transform of the mesh based on bone bounding boxes. I should note that I plan on doing the actual bone vertex transformation on the GPU.
Also, I am thinking of limiting the bones to cull on based on major bones (such as arm and leg) and eliminating minor bones (facial bones for instance).
Quote:Is the reason for not culling on bones because there are too many bones in 1 object and thus too much to cull or is it because of the worry of having to recalculate indices because submesh boundaries do not necessarily follow bone boundaries. Or, would it be faster to just calculate the transform of the mesh based on bone bounding boxes.Culling is about the general case. The reason not to even try to just cull a guy's left thumb is because usually if the guy's left thumb is hidden, the rest of him is hidden too. There may be rare circumstances where the rest of the guy is visible but the thumb is invisible, but the time you spend in the general case checking for this condition will far outweigh the time you save in the few frames where you are able to successfully cull his thumb.
Is your master plan for hitting your framerate target really based around all the animated characters having some of their limbs hidden behind obstacles?
Author
Quote:Is your master plan for hitting your framerate target really based around all the animated characters having some of their limbs hidden behind obstacles?
I am just trying to maximize efficiency. This definitely gives me some direction. Thank you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
