Ive hacked together the skinned mesh and mouse samples from the sdK, and inserted my own animated meshes. Ive now got a character running around in 3D space. Now I need a level. If I load in a level mesh using D3DXLoadMeshFromX, how do I find the vertices of the individual polygons for collision detection? Or should I be doing something else?

I want to know the same answer.

To get the verts you just need to get the vertex buffer...Then I would copy them to your own structure...unless it''s a very simple level...drawing using the mesh is a bad idea. Now you should look into BSP''s, octrees, portals etc...

quote:Original post by Anonymous Poster
To get the verts you just need to get the vertex buffer...Then I would copy them to your own structure...unless it''s a very simple level...drawing using the mesh is a bad idea. Now you should look into BSP''s, octrees, portals etc...

When I have de vertex buffer, how do i separate each vertex, so i can chech each poligyn separatly?

You wouldn''t.

You would take the entire chunk of vertex data (better known as polygon soup), and use one of the many space partitioning algorithms to create a more desriable rendering and collision detection structure.

Look for info on BSP trees, Octrees, Quadtrees and AABB trees.

A quick run down on BSP trees and Octrees: (Don''t quote me on anything to do with BSP though, I am only just starting on that)
The basic idea is the same. It begins with one node which has children who also have children and so forth. A BSP node has 2 children, a quadtree 4, and an octree 8. They all try to hold an even amount of geometry. BSP does it with dividing planes while oct/quad hold a number of polygons.
Octrees:
Visuallise a Massive box containing the whole level. The camera fustrum will be checked against this box and if it intersects then every thing in the box is drawn. Currently, as this box holds everything and is the size of the level, everything will always be drawn. So that means if the number of polygons in the box is above a certain value, the box will be subdivided in to 8 (or for quadtrees 4) equal boxes and so on until either the chain becomes too long or there is sufficiently little polygons in the box. Now if the fustrum intersects with a box, it will be tested against all the baby boxes inside it and so forth. In the end, a lot less polygons will be sent to the card for rendering.

BSP trees have a similar principle but do it using planes and in a way that is rather hard to visuallise. They are fast for indoor type levels but rubbish out doors. With BSP, you can also take some short cuts when it comes collision detection and other things. They really have survived through time for I believe they were first used (in games anyway) in Quake 1. It is more complicated to implant than Quad/octrees though.

quote:Original post by Drath
BSP trees have a similar principle but do it using planes and in a way that is rather hard to visuallise. They are fast for indoor type levels but rubbish out doors. With BSP, you can also take some short cuts when it comes collision detection and other things. They really have survived through time for I believe they were first used (in games anyway) in Quake 1. It is more complicated to implant than Quad/octrees though.

BSP''s were first used in DOOM yes, earlier than Quake. Quake 1/2/3 uses a mixed BSP/portal system. Your comment that bsp''s suck outdoor is because of the portal system. But if properly designed, when you cut the open terrain into invisible squares, you can still use it to cull the back and insides of buildings.

They are particulary interesting if you add some thing to them. The Quake series etc. defines a bounding box in each node, upper ones and leafs. These are used to cull nodes against the viewing frustrum, together with PVS.

Back then the games like Quake 1 and Doom only had software processing. The BSP was used to obtain a depth-sorted list of polygons from any viewpoint. Nowadays it''s not useful to sort them yourselves, so now each node holds a convex space with polygons on its side. Quake etc. still use a BSP, but don''t really use it to render the scene. Instead it defines portals between leaf nodes (a portal is an open polygon between two nodes that connects them), then determines which portals can see others. Then a visibility list is built.

The great thing about BSP''s is that they give you other things for free. For instance collision detection, you can quickly determine the polygons of your node and test only against them. Also with multiplayer you can send the player only player positions of players that are in nodes visible from the player, improving performance and countering cheating with wallhacks.