Automatically sizing a primitive?

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
needshelprendering
Posts: 25
Joined: Mon Sep 17, 2012 1:17 am

Automatically sizing a primitive?

Post by needshelprendering »

Hi Norbo,

I am in the middle of content creation for a prototype game and I was wondering if it was possible to do something along the lines of automatically sizing a primitive for entities like wheels?

Say I have a car model and I want to create primitives to match the wheel size which I will then serialize and save for later. Would this be practical or should I just try and create some sort of editor and wing it?

I also have a few other questions:
Say I needed to check if an area is sealed. Normally a single entity like a building. How would I check if there are any holes?
How would I simulate something like decompression? Would I just apply a force towards where I would like the hole to be sucking air out of the room, or gravity?
I saw you mention fracturing for Bepu. Is that going to be a feature some time soon? As of right now I am looking for methods of opening holes in walls, could you give me a rundown on basically how I'd go about that?

Thank you Norbo.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Automatically sizing a primitive?

Post by Norbo »

I am in the middle of content creation for a prototype game and I was wondering if it was possible to do something along the lines of automatically sizing a primitive for entities like wheels?

Say I have a car model and I want to create primitives to match the wheel size which I will then serialize and save for later. Would this be practical or should I just try and create some sort of editor and wing it?
If you're wondering if there's something in BEPUphysics which would explicitly help with this sort of thing, then no, there's nothing like that.

If you're wondering if it's possible to create metadata in, say, Blender to represent shapes which can then be imported, then yes, that's possible and is a pretty common approach. For specifics, you'd have to ask someone who knows more about the particular tools you're using.
Say I needed to check if an area is sealed. Normally a single entity like a building. How would I check if there are any holes?
Modeling tools usually have utilities that can be used to check if a mesh is closed, manifold, and so on. If available, I'd recommend just doing that. Otherwise...
How would I simulate something like decompression? Would I just apply a force towards where I would like the hole to be sucking air out of the room, or gravity?
A simple force would work decently in many cases. It just depends on the effect that you want.
I saw you mention fracturing for Bepu. Is that going to be a feature some time soon? As of right now I am looking for methods of opening holes in walls, could you give me a rundown on basically how I'd go about that?
That was part of a game prototype that didn't pan out (though it worked fine in a technical sense). The fracturing stuff was pretty tightly integrated with its specific use in the prototype, so it was too messy for a direct release. The current project doesn't make use of fracturing as a primary feature, so I wouldn't expect to get around to it any time soon.

As for how to do it: if your fracturable objects are small enough, you may be able to get away with binding a bunch of entities together with constraints. To break the object, just check each constraint's TotalImpulse property. If its magnitude is sufficiently high, remove the constraint.

The prototype implementation needed to have many thousands of pieces, so constraints were too slow. Instead, there was a single Entity with a CompoundShape. Whenever a fracture occurred, the original entity was separated into two using the CompoundHelper. Determining when and where fractures occurred was implemented with a low-fidelity stress simulation. Adjacent parts of the fracturable were connected in this stress simulation, like the separate entities would be in the fully constraint-based approach above. Collision impulses and other relevant forces were taken from the real physical simulation and applied (in approximate form) to the stress simulation. When the stress on a particular connection exceeded a threshold, the connection was removed.

Each sub-body could be considered a vertex in a graph, and each constraint was an edge in the graph. When an edge's removal caused a set of vertices to no longer have a path to another set of vertices, a fracture was triggered to split the corresponding sub-bodies into separate compounds. So, a spaceship ramming into the middle of another spaceship could split the victim into two separate chunks (and some smaller debris, too).

If you don't require any dynamic behavior from the involved objects, things get a lot easier. Simply removing a particular object on some event may be enough- no need for all of the above connectivity logic.

If you don't have any pre-separated parts and need to figure out how to split a shape dynamically, things get a lot harder and a lot more expensive.
Post Reply