[ODE] Terrain: collision test culling
Hannes Norda
norda at customred.com
Sun Aug 8 10:43:28 MST 2004
Hi,
have a look at collide/category bits
http://www.ode.org/ode-latest-userguide.html#sec_10_5_1
They let you cull collisions early, just before the AABB-test I think.
Also you could try to put all your static geometry in one space and
dynamic (and static you still wanna check against 'static world') in
another space.
Now when you check for collisions you just collide the dynamic with the
static and then the dynamic with itself. Thus not checking for
collisions between static world at all.
http://www.ode.org/ode-latest-userguide.html#sec_10_5_2
pseudo:
dSpaceCollide2(dynamicspace, staticspace)
dSpaceCollide(dynamicspace)
If you use the second version it is a good idea to still use
collide/category bits and cull collisions that you don't want, maybe
between different dynamic objects, like camera vs enemyshots and so on.
I also built my staticspace with subspaces, based on the octree I use
for rendering.
Hope this helped, sunday morning and no coffee yet.
/Hannes
johnmcTemp at netscape.net wrote:
> Hi. My name is John and this is my first time posting. Ive been using ODE for
> about 2 weeks. Currently just working on getting better knowledge and
> testing performance with different terrain sizes to see what I can shoot for on my PC
> as far as a small 3d game.
>
> I am wondering HOW I call reduce the number of NearCollisionCallback() calls
> each simulation. Currently, all I am doing is inserting 'chunks' of terrain as trimesh
> geoms into a space. Depending on the space, the number of calls just in these static
> geoms 'colliding' with each other can quite litterly bring my application to a
> screaching halt (0 to 1 fps).
>
> So I have some data here, and if possible, would like to see what some of you out
> there that have had experience in terrain chunks, what I may do to improve
> upon my situation. My curiousity is in the number of callbacks every tick. I am really
> not sure why there are so many possible collisions between static geoms, and whether
> there is a simple solution.
>
> Thanks, and any comments or questions would be great.
>
> ///////////////////////////////////////////////////////////
> I much cleaner html version can be found here:
> http://home.earthlink.net/~gqjohnm/ODETerrainResults.htm
>
> ///////////////////////////////////////////////////////////
> Text version in case website is down (excuse the crappy formatting, see html version above):
>
> [ODE Space Type] [Num terrain trimesh geoms] [Num NearCollisionCallback() calls] [Num dCollide() collisions]
> Terrain Size = 65x65
> Simple with testing types 4 6 0
> Simple w/o testing types 4 6 6
> QuadTree with testing 4 2 0
> QuadTree w/o testing 4 2 2
>
> Terrain Size = 129x129
> Simple with testing types 16 42 0
> Simple w/o testing types 16 42 39
> QuadTree with testing 16 12 0
> QuadTree w/o testing 16 12 12
>
> Terrain Size = 256x256
> Simple with testing types 64 207 0
> Simple w/o testing types 64 207 186
> QuadTree with testing 64 56 0
> QuadTree w/o testing 64 56 56
>
> Terrain Size = 513x513
> Simple with testing types 256 918 0
> Simple w/o testing types 256 918 658
> QuadTree with testing 256 240 0
> QuadTree w/o testing 256 240 240
>
> TERRAIN DETAILS:
> Terrain is broken up into 33x33 chunks. Each chunk creates an ODE trimesh geom and adds it to the space/world.
> The reason for the odd numbers is so when terrain is broken into chunks, each will have even numbers, such as 0 to 32, or 32 to 64,..
> For quadtree spaces, the center is at 0, with extents being equal to terrain size.
> The number of levels deep should be such that at all the chunks fit perfectly at the bottom/deepest level. Here are some numbers:
> Terrain size = 65x65 chunks = 4 total, 2 across Quadtree size = 65x65 Quadtree depth = 2
> Terrain size = 129x129 chunks = 16 total, 4 across Quadtree size = 129x129 Quadtree depth = 3
> Terrain size = 257x257 chunks = 64 total, 8 across Quadtree size = 257x257 Quadtree depth = 4
> Terrain size = 513x513 chunks=256 total, 16 across Quadtree size = 512x512 Quadtree depth = 5
>
> NEARCOLLISIONCALLBACK DETAILS ("With/Without Testing"):
> I use the basic NearCollisionCallback() given in most of the simple examples from ODE.
> The only difference is that I set classification, in the geom paramater, so I can identify what the geom is, such as a 'terrain chunk'.
> So, during the NearCollisionCallback(), if neither of the geoms are spaces, then next I test if both are terrain chunks.
> If so, then early out! I don’t want terrain chunks colliding with each other!!
>
>
> __________________________________________________________________
> Switch to Netscape Internet Service.
> As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register
>
> Netscape. Just the Net You Need.
>
> New! Netscape Toolbar for Internet Explorer
> Search from anywhere on the Web and block those annoying pop-ups.
> Download now at http://channels.netscape.com/ns/search/install.jsp
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>
More information about the ODE
mailing list