Collision Meshes / Aabb Generation

Started by
6 comments, last by Krohm 7 years, 9 months ago

Hello. I am using obj as static mesh format and I've got problem with decent collision. Generating aabb from min/max xyz fails, because i cant enter a house or go under a bridge. I am not a graphic designer myself, but I wonder if there is some way of exporting some simple collision data with the obj mesh? As far as i understand, the person creating meshes would have to create the collision boxes from several aabbs, right?

Greetz

Advertisement

You're really not providing enough information here for us to be helpful. But, why not just start by figuring out why your generated AABB are not working? You probably just have some error in your generation code, or error in the math that checks for collisions.

i am not sayin they are not working! I mean that if the house is one object and it is empty inside (so i want to walk inside) then generating aabb from min and max xyz make one box which covers entire mesh and in result i cant walk inside. I need some method for splitting the mesh into realistic set of aabbs, for example one for every wall, 1 for roof, so in the end i can move inside the house

As you said in your first post, you need someway to manually generate collision information, that information may or may be not be tied to the graphical mesh

I've always wondered about this myself.

Most level maker software will allow you to create collision boxes. Usually those are the more expensive Oriented Bounding Boxes (OBB's) rather than Axis Aligned Bound Boxes. So, that's obviously one way to go; create a program that lets you assign them by drawing them, then store that data with your model. For assigning bounding boxes, you almost have to use OBB's since AABB's prevent you from changing the orientation of your model. You "might" get away with a 90 degree rotation if it's a cube because it would then be axis aligned again. But if it's a box instead of a cube even a strict 90 degree rotation will mess it up.

I've dreamed of using Blender for collision geometry. Under ViewPort Shading there is a bounding box option. That makes me wonder if you can set bounding boxes for objects in Blender.

But that aside, you could create another mesh as a box, give it a specific name like, "Bounding Box", and then load it into your game. The way I am currently working, I'm writing my own custom Python exporter for the model data, and so I could easily tell it to just export this in the file as bounding box data rather than as a mesh. Then I'm using my own custom model importer in C++ where I can have it read that data from the file and if I had a bounding box member in my model class, I could have it assign the correct values. But this makes a lot of assumption about you having full control over the situation. If you are working in Unity by exporting an FBX file, you may have to come up with a different plan. This is one of the advantages of writing your own because you have complete control and can add in anything you want.

If you could find the two vertices that are the furthest from one another, I think you might be able to calculate a center point for the model. Then you could calculate a bounding sphere. I would probably do that first. I think bounding sphere collision combined with OBB's might function pretty well even if you have to check a large number of collisions. The sphere check is extremely efficient, even noticeably more than AABB's. Only when two objects intersect on their spherical collision do you even need to check the OBB's. So, even though that's a fairly expensive check, you likely only have to do it in cases where there is a very high probability of collision.

Im writing my own engine. I also got own c++ converter from obj to my format. The idea with having sphere first and then making detailed oob test is great. All i need right now is to somehow get those oobs for a model, but from what i understood its a mesh designer's task to do it.

AABBs are for broad phase detection. It sounds like you're trying to use them for narrow phase.

http://www.metanetsoftware.com/dev/tutorials

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

I would suggest against inferring your narrow-phase collision data from graphical assets. It is kinda unflexible; sometimes for artistic reasons you want the collision data to be smaller, bigger or different; I remember a game in which staircases were often simplified to ramps at collision level.

An automated process will most likely be unable to detect when to use a sphere primitive instead of a hull or perhaps an assembly of hulls instead of a trisoup.

Tying the physics to graphics involves quite some work for simplification and going by that mindset you'll probably open the door to the special collision flags collidable/bot-collidable/weaponclip etc... mighty be worth thinking in more generic terms.

Previously "Krohm"

This topic is closed to new replies.

Advertisement