Locking Vertex Buffers - bad?

Yes, keep a system memory copy.

For collisions, often a lower polygon, simplified, version of a mesh is used. All the detail that a character might have, such as eyes, nose, ears, lips, hair, fingers, etc. These things are overkill for collisions. Sure it''d be nice to include all the detail, but CPUs still aren''t fast enough, and you can use that extra CPU time to do something somebody might notice, like better AI, physics, etc.

In your case the locking is not the problem. But on modern video cards the vertex buffer is on the card. Reading back is very, very slow (the AGP is only fast for writing to the card, not the other way around). And as Namethatnobodyelsetook mentioned, you can organize your data in a way that may be better suited for collision detection.

Locking the buffer has a big cost, so do it as little as possible.

quote:

---

I could keep a simple array of vertices in system memory.

---

That would probably be ideal, and is usually necessary for most applications.

quote:

---

Would that be a big performace issue, or is there little cost to locking the buffer?

---

There is some cost, but it''s not going to kill you to lock the buffer once per frame. Ideally, if your data in the buffer is constantly changing, create the buffer dynamically and use the NOOVERWRITE flag when updating.

There''s another post on this forum about this somewhere, but I can''t find the link right now.

http://www.gamedev.net/community/forums/topic.asp?topic_id=224241

Here you go (2 posts down...)



[edited by - Etnu on May 10, 2004 11:26:56 AM]

I had this same question before when growing up with DirectX. Clarify your question with some more details though if you can.

The issue is that if you need to read the data back from the buffer, I personally think it is best to have a system memory copy and read it there instead...then change the system version to reflect the change. Then of course call a single memcpy to transfer the data to the locked VB. After all, there's plenty of system memory usually.

If you're simply just needing to read from the buffer without changing anything (as in your example), definitely go with system memory. Although, I think the D3DVertexBuffer9 interface has a nice, fast intersect function...I think. It may be optimized good enough and prevent you from having to spend time writing more code, that you decide 130 fps to 132 fps increase isn't worth it.

If you have no intention of reading from the buffer, you'd be wasting memory to have a system version of the buffer. If you are only writing to the buffer, then you must be re-calculating certain parameters anyway, so just stick them in the locked buffer instead of...putting them in system memory, then copying them to the locked buffer. You probably know this though.

Also, remember to use the appropriate flags in your buffer creation and locking. You can get a nice performance increase that way.

You probably want your collision detection to have a sphere or box for most meshes (not all of course), calculated at load-time for the meshes. This would of course have to be stored in system memory, but that's not a big deal.

Chris

[edited by - Supernat02 on May 10, 2004 12:39:05 PM]

Thanks for all of the suggestions.

I''ve got my physics engine complete, except for collisions. And I''ve never done anything like what I need to do. So any more suggestions or advice could not be further from wasted.

As for what I''m trying to do with the vertices, that is uncertain. I was thinking about using sphere-to-mesh collisions. Is that how it''s usually done? I''ve looked around for articles, but can''t seem to find anything that explains the basics.

What I planned to do was have all of my movable objects use spheres, and check collision against my static world meshes. I know sphere-to-sphere (object-to-object) is a very simple process, but I''m having trouble getting the sphere-to-mesh correct.

Here is what I thought I could do:
1. Get the vector of the sphere (origin)
2. Get the vector of the sphere''s moving direction
3. Do a line intersect with those coordinates against mesh

But it won''t work. After I did more thinking, I realized it would be very easy for the sphere to collide with mesh faces even if it wasn''t moving towards them. For example, a sphere that is moving exactly towards X, and whose Y is barely above a building. The origin and direction would be exactly horizontal, but the bottom of the sphere would cut right through the top of the building. Even if the sphere had a radii the size of the planet.

Errr, like I said, I''m really new at this. Most programmers probably wouldn''t have even considered such an approach.

Can anyone help me out with this? Point me in a certain direction? Thanks again.

quote:

---

As for what I''m trying to do with the vertices, that is uncertain. I was thinking about using sphere-to-mesh collisions. Is that how it''s usually done? I''ve looked around for articles, but can''t seem to find anything that explains the basics.

---

Most collision testing is done either with bounding boxes or bounding spheres. Both approaches have their benefits and their drawbacks, so you''ll kind of have to decide what''s right for your particular scenerio.

quote:

---

Here is what I thought I could do:
1. Get the vector of the sphere (origin)
2. Get the vector of the sphere''s moving direction
3. Do a line intersect with those coordinates against mesh

---

For large meshes, try testing for the sphere intersecting the individual polygons. For small meshes, just generate a bounding sphere and do a standard sphere/sphere test. You don''t really have to be 100% accurate for most things involving collisions of individual objects, but if it''s a world/level that you''re testing for collision against, the sphere/polygon test should suit your needs.

What do you use for the direction vector of the line? Is it the triangle''s normal?? So I use the sphere''s position as the line''s origin, and the triangles normal as the line''s direction?

Not to sound like a complete moron, but how do I rule out triangles who''s normal are not facing the sphere?

This stuff may be over my head a little. I guess I just need to keep messing with it. Thanks for the help so far!

The triangle''s normal will suffice.

The sphere should never collide with a back-facing triangle. If you''re using 2-sided triangles, you''ll have to do something a little more specialized; either duplicate the vertices so you have one triangle pointed one direction and the other the opposite (easiest), or write a special test that checks the backside of a triangle (inverse normal) as well as the front.

I know I''m totally vearing off from the subject, but I don''t see how it would work using the normals. I''ve drawn a crappy representation of a situation where I don''t think it would work: Here

The sphere is moving towards the right only. The normals on the rectangular mesh would not work to intersect a line. Would they?

Am I missing something? I''ve done a lot of research on collision detection, and perhaps I just need to get back to school Some of the math terms I''ve not heard before.

I just want to know this: How can I do a line intersection with a sphere against a mesh? Should I even do that at all? Is there some incredibly simple way to check collision between a mesh and sphere that I''m missing?

A lot of thanks for any help