OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Performing parent/child occlusion culling


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
Dusten Sobotta
Guest





PostPosted: Fri Nov 28, 2008 9:13 pm    Post subject:
Performing parent/child occlusion culling
Reply with quote

Hello,

How might I enable parent/child culling, such that the world geometry of a primary (parent) object determines which small objects (children) are culled out of the scene? For example, there may be hundereds or thousands of small objects in my scene, that wouldn't occlude much of anything. Only the world geometry with large, static walls should be used during the culling process to reduce computation time. From what I understand about OSG's implementation of occlusion culling however, this can't be accomplished with a single, large model used for the static world geometry--as the camera is always within the bounding box.

Might anyone have some recommendations?


Thanks in advance,

Dusten

------------------
Post generated by Mail2Forum
Back to top
Skylark (Jean-Sébastien Guay)
Professional


Joined: 05 Jan 2009
Posts: 2249

PostPosted: Fri Nov 28, 2008 9:33 pm    Post subject:
Performing parent/child occlusion culling
Reply with quote

Hello Dusten,

Quote:
From what I
understand about OSG's implementation of occlusion culling however, this
can't be accomplished with a single, large model used for the static
world geometry--as the camera is always within the bounding box.

OSG's culling is hierarchical, so if you organize your scene correctly
this will be done automatically. A very flat graph of large numbers of
objects is really bad, but a really deep graph is bad too, so you need
to experiment.

Say you're making a building, you could build a room, then parent all
rooms to form a floor, then parent all floors to form the building, then
add the outside walls.

When the viewer is in a room, for example, OSG will start at the top of
the graph, see that the bounds of the building as a whole are in view,
descend into the floors, cull away any floors whose bounds are not in
view, descend into the others, cull away any rooms whose bounds are not
in view, and render just the rooms whose bounds are in view (which
should hopefully be just the room you're in). It will also cull away
things that are behind the viewer or outside their field of view, so
walls and furniture behind you will be culled away.

Including your small objects into that hierarchy so that they're
parented to the right parent will lower draw times too. However, if you
have a very large number of small objects, you will want to cluster them
below a common Group parent, so that if the whole group's bounds are not
visible then it will be culled in one shot instead of testing each small
object's bounds individually. A symptom that indicates you should do
that is if your cull times are very high but your draw times are normal.
How many small objects to cluster together is a balancing act that you
should experiment with, as performance will depend on your hardware and
the current bottleneck in your pipeline.

There has been lots said in the past about how to properly balance a
scene graph, have a look through the archives. In general, it's called
"conditioning" a scene graph, and a scene graph that is badly balanced
is also called "badly conditioned", so you might want to search on those
terms.

Hope this helps,

J-S
--
______________________________________________________
Jean-Sebastien Guay
http://www.cm-labs.com/
http://whitestar02.webhop.org/


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Dusten Sobotta
Guest





PostPosted: Fri Nov 28, 2008 10:02 pm    Post subject:
Performing parent/child occlusion culling
Reply with quote

Hello,

I understand how this can be accomplished if a user is given a lot of control over the scene graph during map/level creation, but what I'm aiming for is the ability to load in a .3ds model (or otherwise) for level geometry and let the user place various prefabs such as crates, trees, cars, etc into the world; then, the composite level is exported to a .lua script so that it can be loaded again with all of the static and dynamic objects intact. The issue is of course, that I cannot possibly compete with blender or 3dsMax as a modeling program, and I shouldn't attempt to either. The users of this engine should be able to use existing, non-proprietary modeling software to create levels or items for their game. I believe it would be too complex to implement an automatic or user-friendly way to disassemble an existing set of level geometry, only to re-assemble with parenting.

A certain degree of the parent/child culling you mentioned is already implemented. For example, multiple 'levels' can be laid out on a grid for on-the-fly level streaming--each level being a parent to the static and dynamic objects contained within them. But it would be -very- tedious for a level designer to heavily subdivide his or her model for culling purposes. Is there some way to use a 'precise' bounding box on a single node, that takes the level geometry's lowest LOD for occlusion culling operations? At least this would allow detail objects to be culled away if the camera was 'in' the level, as it usually is.


Thanks for your time,

Dusten


On Fri, Nov 28, 2008 at 3:33 PM, Jean-Sébastien Guay < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hello Dusten,

Quote:
From what I understand about OSG's implementation of occlusion culling however, this can't be accomplished with a single, large model used for the static world geometry--as the camera is always within the bounding box.


OSG's culling is hierarchical, so if you organize your scene correctly this will be done automatically. A very flat graph of large numbers of objects is really bad, but a really deep graph is bad too, so you need to experiment.

Say you're making a building, you could build a room, then parent all rooms to form a floor, then parent all floors to form the building, then add the outside walls.

When the viewer is in a room, for example, OSG will start at the top of the graph, see that the bounds of the building as a whole are in view, descend into the floors, cull away any floors whose bounds are not in view, descend into the others, cull away any rooms whose bounds are not in view, and render just the rooms whose bounds are in view (which should hopefully be just the room you're in). It will also cull away things that are behind the viewer or outside their field of view, so walls and furniture behind you will be culled away.

Including your small objects into that hierarchy so that they're parented to the right parent will lower draw times too. However, if you have a very large number of small objects, you will want to cluster them below a common Group parent, so that if the whole group's bounds are not visible then it will be culled in one shot instead of testing each small object's bounds individually. A symptom that indicates you should do that is if your cull times are very high but your draw times are normal. How many small objects to cluster together is a balancing act that you should experiment with, as performance will depend on your hardware and the current bottleneck in your pipeline.

There has been lots said in the past about how to properly balance a scene graph, have a look through the archives. In general, it's called "conditioning" a scene graph, and a scene graph that is badly balanced is also called "badly conditioned", so you might want to search on those terms.

Hope this helps,

J-S
--
______________________________________________________
Jean-Sebastien Guay (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
Skylark (Jean-Sébastien Guay)
Professional


Joined: 05 Jan 2009
Posts: 2249

PostPosted: Mon Dec 01, 2008 2:13 pm    Post subject:
Performing parent/child occlusion culling
Reply with quote

Hello Dusten,

Quote:
I understand how this can be accomplished if a user is given a lot of
control over the scene graph during map/level creation, but what I'm
aiming for is the ability to load in a .3ds model (or otherwise) for
level geometry and let the user place various prefabs such as crates,
trees, cars, etc into the world; then, the composite level is exported
to a .lua script so that it can be loaded again with all of the static
and dynamic objects intact.

You just need to use a modeling tool and format which understand
hierarchy, and then use that. Many formats which normal modeling tools
export support this: COLLADA, OpenFlight, etc. Plus, there are plugins
for both 3DSMax and Blender (among others) to export to .osg directly.

If you need anything else, you need to code it yourself, which shouldn't
be that complicated. Here we have a system which loads and interprets
scripts as you describe, plus it includes physical properties (we
develop and sell a physics engine after all Smile ), viewer configuration,
input device configuration, etc.

Of course, once again the ability to do view frustum culling properly
still hinges on the grouping of close-by objects and a well-conditioned
scene graph, and at this point it's up to your loader to build the scene
graph in a way that will be close to optimal. You can give hints in your
scripting files for this (such as group names, where each object whose
group name is the same will be grouped together, or a radius + number of
objects scheme, where objects which are close by within a certain radius
will be grouped together up to a given number of objects).

Quote:
The issue is of course, that I cannot
possibly compete with blender or 3dsMax as a modeling program, and I
shouldn't attempt to either. The users of this engine should be able to
use existing, non-proprietary modeling software to create levels or
items for their game.

I totally agree with this. However, slight retraining for the realities
of real-time graphics is often necessary. Why do you think the 3D
artist/multimedia schools have different classes for game modeling and
fx/film modeling? Both have different tradeoffs and the modeler must
keep different things in mind while doing his job. (same goes for
texture artist, lighting artist, etc. when those positions are occupied
by different people)

Quote:
I believe it would be too complex to implement an
automatic or user-friendly way to disassemble an existing set of level
geometry, only to re-assemble with parenting.

Not only is it not too complex, you don't have any choice. It's up to
you to provide OSG with a well-formed scene graph. If you don't, you
probably won't get great performance. Modeling tools by default make
flat hierarchies, but in both 3DSMax and Blender IIRC (and Maya,
Softimage XSI, etc. too, and of course Creator) there is a view which
allows the modeler to rearrange the hierarchy. Using this, along with a
format which can export the hierarchy properly will save you a lot of
time trying to do the same programmatically.

Quote:
But it would be -very-
tedious for a level designer to heavily subdivide his or her model for
culling purposes.

It's not that tedious, and I didn't say you need to heavily subdivide.
Just keep the hierarchy in mind when building the levels, and do a rough
grouping. You will see large performance gains.

Quote:
Is there some way to use a 'precise' bounding box on
a single node, that takes the level geometry's lowest LOD for occlusion
culling operations? At least this would allow detail objects to be
culled away if the camera was 'in' the level, as it usually is.

I'm not aware of anything in OSG to automatically build occlusion
volumes (from anything, not just from the lowest LOD), but then again I
have never used occlusion culling in OSG myself, so others may be better
placed to inform you on this.

If you want my advice, start with making OSG's view frustum culling job
easier, that's the simplest to implement and will already get you
massive gains.

Hope this helps,

J-S
--
______________________________________________________
Jean-Sebastien Guay
http://www.cm-labs.com/
http://whitestar02.webhop.org/


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Dusten Sobotta
Guest





PostPosted: Mon Dec 01, 2008 5:20 pm    Post subject:
Performing parent/child occlusion culling
Reply with quote

This has been an incredibly helpful response. Thanks a ton Smile


On Mon, Dec 1, 2008 at 8:12 AM, Jean-Sébastien Guay < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hello Dusten,

Quote:
I understand how this can be accomplished if a user is given a lot of control over the scene graph during map/level creation, but what I'm aiming for is the ability to load in a .3ds model (or otherwise) for level geometry and let the user place various prefabs such as crates, trees, cars, etc into the world; then, the composite level is exported to a .lua script so that it can be loaded again with all of the static and dynamic objects intact.


You just need to use a modeling tool and format which understand hierarchy, and then use that. Many formats which normal modeling tools export support this: COLLADA, OpenFlight, etc. Plus, there are plugins for both 3DSMax and Blender (among others) to export to .osg directly.

If you need anything else, you need to code it yourself, which shouldn't be that complicated. Here we have a system which loads and interprets scripts as you describe, plus it includes physical properties (we develop and sell a physics engine after all Smile ), viewer configuration, input device configuration, etc.

Of course, once again the ability to do view frustum culling properly still hinges on the grouping of close-by objects and a well-conditioned scene graph, and at this point it's up to your loader to build the scene graph in a way that will be close to optimal. You can give hints in your scripting files for this (such as group names, where each object whose group name is the same will be grouped together, or a radius + number of objects scheme, where objects which are close by within a certain radius will be grouped together up to a given number of objects).

Quote:
The issue is of course, that I cannot possibly compete with blender or 3dsMax as a modeling program, and I shouldn't attempt to either. The users of this engine should be able to use existing, non-proprietary modeling software to create levels or items for their game.


I totally agree with this. However, slight retraining for the realities of real-time graphics is often necessary. Why do you think the 3D artist/multimedia schools have different classes for game modeling and fx/film modeling? Both have different tradeoffs and the modeler must keep different things in mind while doing his job. (same goes for texture artist, lighting artist, etc. when those positions are occupied by different people)

Quote:
I believe it would be too complex to implement an automatic or user-friendly way to disassemble an existing set of level geometry, only to re-assemble with parenting.


Not only is it not too complex, you don't have any choice. It's up to you to provide OSG with a well-formed scene graph. If you don't, you probably won't get great performance. Modeling tools by default make flat hierarchies, but in both 3DSMax and Blender IIRC (and Maya, Softimage XSI, etc. too, and of course Creator) there is a view which allows the modeler to rearrange the hierarchy. Using this, along with a format which can export the hierarchy properly will save you a lot of time trying to do the same programmatically.

Quote:
But it would be -very- tedious for a level designer to heavily subdivide his or her model for culling purposes.


It's not that tedious, and I didn't say you need to heavily subdivide. Just keep the hierarchy in mind when building the levels, and do a rough grouping. You will see large performance gains.

Quote:
Is there some way to use a 'precise' bounding box on a single node, that takes the level geometry's lowest LOD for occlusion culling operations? At least this would allow detail objects to be culled away if the camera was 'in' the level, as it usually is.


I'm not aware of anything in OSG to automatically build occlusion volumes (from anything, not just from the lowest LOD), but then again I have never used occlusion culling in OSG myself, so others may be better placed to inform you on this.

If you want my advice, start with making OSG's view frustum culling job easier, that's the simplest to implement and will already get you massive gains.


Hope this helps,

J-S
--
______________________________________________________
Jean-Sebastien Guay (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




------------------
Post generated by Mail2Forum
Back to top
Skylark (Jean-Sébastien Guay)
Professional


Joined: 05 Jan 2009
Posts: 2249

PostPosted: Mon Dec 01, 2008 5:30 pm    Post subject:
Performing parent/child occlusion culling
Reply with quote

Hello Dusten,

Quote:
This has been an incredibly helpful response. Thanks a ton Smile

Glad I could help. Smile

J-S
--
______________________________________________________
Jean-Sebastien Guay
http://www.cm-labs.com/
http://whitestar02.webhop.org/


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts culling / bounding calculation for sh... christoph General 3 Thu Mar 28, 2019 1:17 pm View latest post
No new posts Happy New Year to all OSG Users Chris Hanson General 0 Mon Jan 07, 2019 10:17 am View latest post
No new posts osg-users Digest, Vol 138, Issue 27 Zachary1234 General 0 Tue Jan 01, 2019 1:16 am View latest post
No new posts osg-users Digest, Vol 137, Issue 14 poweruserm@live.com.au General 0 Fri Nov 16, 2018 11:16 pm View latest post
No new posts Shadow frustum culling Gedalia Pasternak General 4 Mon Oct 29, 2018 6:44 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP