I've noticed that in a lot of newer game engines (Doom3, UT2k4, etc) they allow you to import a model directly from a modeling program like Maya or 3DSMax and use it as part of a map with full collision detection and everything. For example: I watched a video tutorial that showed a modeler create a cave scene in Max which he exported to Doom3 and dropped directly into his map without any extra tweking/brush definition. He then complied the map and demonstrated that he could walk around his new cave and the charecter/enemies/bullets would respond correctly to the rocky walls and floors as they walked over them. So here's my question: How is this type of thing handeled in newer engines? I have a couple of theories... 1) A series of planes are derived from the poly soup by the exporter and planes that fall within a certain margin of error of eachother are combined into one. Those planes then are partitioned into convex brushes to collide against, but it's only an approximate collision model. 2) Same as above but without the margin of error. Every face has a unique plane which is grouped into convex brushes. This would be accurate down to the pixel, but could potentially use a lot of memory/cpu time. Have engines gotten so fast that they can simply do this now? The newer batch seems to suggest it. 3) I'm in the dark ages, brushes are a thing of the past, and they're using some new method I don't know about. Just curious as to how all those polies are being handled. [Edited by - Blue*Omega on February 9, 2005 9:40:20 AM]

Some engines use kd trees or aabb trees for collision, so there are no brushes to worry about. Instead of colliding with convex bsp regions, you collide with a triangle soup.

Others have the idea of indoor static geometry which is stored as brushes, and other detail objects that are separate instanced triangle meshes.

okay, that makes sense, to use a different structure for data partitoning than the old BSP, but (if I understand them correctly) you can't actually collide against a kd/aabb tree. They simply show you a much smaller set of data that COULD be collided against. So would you use the tree to find a small subset of poly's and do a per-poly collision against them? That would make sense, though I seem to rember hearing that per-poly collision was still pretty slow.

Quote:Original post by Blue*Omega
I seem to rember hearing that per-poly collision was still pretty slow.

It is, for the most part, which is why you'd use a tree to cut down the potential collidable set as much as possible. The hardware's also gotten faster, of course.