absolute basic collission detection techniques
Author
i have asked many questions on this forum about collision detection, and although i get many answere, people think i know a little on the subject already. i have a room, with walls that are curvy and anything but straight. i want my charachter to not walk through the walls for a start. people have advised creating a plain everywhere there is a curve in the wall, or use octet trees, but when i look into theese they go even deeper in to something i have no clue of. i can get view many generic algorithms on the web, but none of theese take vertex buffers and the like into account, and are written in psudo code, saying things like, "get the normal of this vertices," or "find the co-ordinates of that vertices". this is all well and good, but the thing is i have no clue how to get the co-ordinates of a vertices or any of that stuff. does anyone understand what i mean, or have been through this? its really fustrating as i have no idea where to start, and every where i look, seems to get way over my head.
Well, a good text-book or document on linear algebra is a start.
Try looking in GameDev's articles section, for math and physics.
(Boy, if I had a dime for everytime I said that =)
Here is one such document that covers some basics in vectors and matrices. It should be fairly simple to understand if you do the math yourself whilst reading it. http://www.gamedev.net/reference/articles/article1832.asp
Hope this helps.
Try looking in GameDev's articles section, for math and physics.
(Boy, if I had a dime for everytime I said that =)
Here is one such document that covers some basics in vectors and matrices. It should be fairly simple to understand if you do the math yourself whilst reading it. http://www.gamedev.net/reference/articles/article1832.asp
Hope this helps.
A plane (not plain!) divides some space into two spaces (negative/positive). It's described by a normal (orientation) and a distance (from the origin to the plane).
Let's say you have a flat wall. You can generate a plane for this wall (you only need 3 points for that) and use it to detect whether a point in space is at the correct (positive) side of the wall, on the wrong (negative) side of the wall, or exactly on the wall.
A plane is flat and endless, so one plane can not describe a curved wall.
If you want perfect collision, you need either:
- some mathematical shape which describes your curve and allows for fast intersection tests.
- take each triangle of the (collision) mesh and do a triangle vs point/ray/sphere test (whatever you're using to describe the body that you want to do collision-tests for).
Whatever you use: make sure that you do some simple tests first (i.e.: sphere/AABB) before you dig deeper. This'll greatly speed things up.
The octree you mentioned is purely for spatial subdivision. It can speed up your collsion tests and your rendering, because you can eliminate areas quickly. It's not a collision technique, however.
Let's say you have a flat wall. You can generate a plane for this wall (you only need 3 points for that) and use it to detect whether a point in space is at the correct (positive) side of the wall, on the wrong (negative) side of the wall, or exactly on the wall.
A plane is flat and endless, so one plane can not describe a curved wall.
If you want perfect collision, you need either:
- some mathematical shape which describes your curve and allows for fast intersection tests.
- take each triangle of the (collision) mesh and do a triangle vs point/ray/sphere test (whatever you're using to describe the body that you want to do collision-tests for).
Whatever you use: make sure that you do some simple tests first (i.e.: sphere/AABB) before you dig deeper. This'll greatly speed things up.
The octree you mentioned is purely for spatial subdivision. It can speed up your collsion tests and your rendering, because you can eliminate areas quickly. It's not a collision technique, however.
Getting data out of a vertex buffer is pretty easy [smile]. All you have to do is this:
That's it! Now, the 4th parameter of IDirect3DVertexBuffer9::Lock() is very important to the performance of our application. It is a flag parameter that specifies exactly how this lock is going to behave.
If you are going to be filling the VB with all new data, specify D3DLOCK_DISCARD. This tells your app to discard the current contents and give you a new memory location. You then have to copy all of your existing data over to that.
If you aren't going to overwriting any data in the buffer, specify D3DLOCK_NOOVERWRITE. This tells the driver that it's okay to keep using this buffer, even while you have it locked. Otherwise, it has to wait until you are finished with it (because the data might change).
If you are only going to be reading from the buffer, specify D3DLOCK_READONLY. This enables you to save time during the IDirect3DVertexBuffer9::Unlock() call.
All of the above also pertains to locking index buffers. To do that, just change your code to the following:
And that's it [wink].
// vb is our LPDIRECT3DVERTEXBUFFER9// CUSTOM_VERTEX is our vertex struct // (1) Lock the bufferCUSTOM_VERTEX* vertices;if( FAILED( vb->Lock( 0, 0, (void**)&vertices, D3DLOCK_READONLY ) ) ){ return E_FAIL;}// (2) Use our data (this is where you would probably loop through each vertex and do something with it)D3DXVECTOR3 position = vertices[0].pos;// (3) Unlock the buffervb->Unlock()That's it! Now, the 4th parameter of IDirect3DVertexBuffer9::Lock() is very important to the performance of our application. It is a flag parameter that specifies exactly how this lock is going to behave.
If you are going to be filling the VB with all new data, specify D3DLOCK_DISCARD. This tells your app to discard the current contents and give you a new memory location. You then have to copy all of your existing data over to that.
If you aren't going to overwriting any data in the buffer, specify D3DLOCK_NOOVERWRITE. This tells the driver that it's okay to keep using this buffer, even while you have it locked. Otherwise, it has to wait until you are finished with it (because the data might change).
If you are only going to be reading from the buffer, specify D3DLOCK_READONLY. This enables you to save time during the IDirect3DVertexBuffer9::Unlock() call.
All of the above also pertains to locking index buffers. To do that, just change your code to the following:
// ib is our LPDIRECT3DINDEXBUFFER9// We're using WORD's because this is a 16-bit index buffer// If you created it as a 32-bit index buffer, you would use ints or DWORDs// (1) Lock the index bufferWORD* indices;if( FAILED( ib->Lock( 0, 0, (void**)&indices, D3DLOCK_READONLY ) ) ){ return E_FAIL;}// (2) Perform all of our operations on the indicesWORD triangleVertexIndex = indices[0];// (3) Unlockib->Unlock()And that's it [wink].
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement