[ODE] BSP and ODE's collision system
Mohammad Bilal
prettyh8machine at mail.com
Mon Apr 21 11:33:02 2003
ah ok...more collidables for better use of hashspace...makes perfect sense. I dont know why I had the impression that if the geometry consists of several geometries, then ode will automatically checks collision hierarchically inside that geometry...which was a stupid assumption.
Ok, I definitely get the faces/leaves information having indices of vertices in the vertex array etc. and this is where I would call GL_TRIANGLE or something like that..but the problem is..where do I pass this to ode ? This triangle information I get while rendering..while I need to initialize ode at startup..this is why I suggested that while loading the bsp file, I would pass in the geometries of all the convex areas. Now the reason why i said convex areas and not the "rooms" is because once I've compiled the map, I cant see where the room starts or ends. This might be true in probably a sector based map format but in BSP you have convex areas (which could essentially be a "room" or some part of a "room").
Anyway, it doesnt matter since I understand what you emphasised..which is very important since making use of hashed collision space will definitely require more and more collidables for quicker collision detection.
Thanks for your help,
Bilal
P.S. Im gonna read that gamasutra article..i'll see what I can do.
----- Original Message -----
From: "Aras Pranckevicius" <nearaz@interamotion.com>
Date: Mon, 21 Apr 2003 17:54:42 +0200
To: <ODE@q12.org>
Subject: Re: [ODE] BSP and ODE's collision system
> > Ok naturally I never meant to say that ode has anything to do the way Im
> rendering..but..since I load a .bsp file into the
> > memory, I have the geometry only binary space partitioned...but this is
> what Im gonna do and I want you to correct me
> > since I am not too sure if this is the right way:
>
> But you do have your "conventional" geometry somehow - eg. triangle meshes
> for final rendering! Either built from your BSP or just supplied "from
> elsewhere".
>
> > Im gonna create geometries for all the convex areas of the BSP geometry
> (in the same like while rendering you get to
> > the current convex area and find all the convex areas visible from that
> point) and add them to a single geometry and
> > then add that geometry to ode's collision space. Now if I add any other
> geometry (say, an entity) into this space, the
> > collision will be done perfectly well.
>
> Something like this... This way you'll have one big triangle mesh for the
> whole geometry. Probably it's better so split it into several meshes, see
> below.
>
> > I hope that this would do enough hierarchical geometry addition and would
> save ode from calculating collisions of one
> > entity to the whole geometry (bsp world). Please comment.
>
> If you have one big collidable, then you lose the advantages of the ODE's
> hashspace (and similarly you would lose the advantages of orctrees,
> quadtrees, regular grids, etc.) - the collidable is always occupying "the
> whole space"... It's better to split it into several smaller ones (eg. for
> each "room" of you level geometry create one ODE collidable).
>
>
> Aras Pranckevicius aka NeARAZ
> http://www.gim.ktu.lt/nesnausk/nearaz/
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup