Practical size for objects?

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
Nostromo
Posts: 4
Joined: Fri Feb 26, 2010 3:45 pm

Practical size for objects?

Post by Nostromo »

Hello all!

I started playing around with Bepu last week. I am still learning a lot about C# in general, but already I have created a small base for a little game.
But I have a few questions.... (why else would I come to the forums :) )

What is a "practical" "size" for objects in the game world? Bepu uses te metric system right? And I use 3dStudio Max to create my models. When I set the unit type in 3d Studio Max to metric(centimeter) how does that translate to Xna & Bepu? is 1 cm 1.0f in XNA or Bepu?To clarify my problem: When I create a box entity, with a width of 10, does my model that I use to represent my box entity have to be 10 cm in 3DStudio max also? I tried it but it didnt seem to work like that.... How do all of you create a model that has a size equal to its entity's size?

An other question over size and units, not directly related to Bepu.....
What are the sizes you all work with? Do your game levels have sizes like in the thousands? or in de hundreds? or way bigger or smaller? My simple begining of a game uses sizes from -800 to +800 on the X and the same values on the Y axis. Does it all even matter what sizes are used?

sorry for my shitty english, and possibly silly question.

Keep the good work up! Bepu rocks! :)

Regards,
Nostromo
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Practical size for objects?

Post by Norbo »

Hi, and thanks for trying out the engine!

BEPUphysics is unitless in that 1.0f doesn't necessarily correspond to any certain measurement unit. You could choose it to be a meter, inch, or mile for the purposes of the game.

However, there are restrictions on the absolute size of entities in units. This is primarily because of the general case collision detection system's sensitivity to floating point errors. You might notice that small 1x1x1 box entities falling on massive, 10000x1x10000 box entities seems to work fine, but a box falling on a 10000x1x10000 triangle acts horribly. That's because the box-box has a special case which is much more resistant to floating point error, while the box-triangle is handled by the general case which is much more sensitive (small side note; there may be a box-triangle special case in v0.12.0).

There's no hard range for what's a 'good size' for a single entity, though keeping it within the 0.5f to 10 unit range is very safe. Usually, you can go a good bit outside of that range without running into floating point precision problems, but if you push it too far you will see some strange results (like what is most likely happening in your other post http://www.bepu-games.com/forums/viewto ... ?f=4&t=842).

Sometimes, adhering to this range will require a little bit of extra work to interact with graphics or gameplay logic of different scales, but it's worth the accuracy improvement. The "Applying Physics Engines" powerpoint presentation at http://www.bepu-games.com/BEPUphysics/documentation.htm goes into this topic a bit more, as well as a variety of other topics.

Getting a content pipeline set up can be a little tricky, because it usually involves some trial and error. Non-obvious scaling factors can sometimes get slipped into programs, file formats, exporters, importers, or processors. Basically, I can't tell you off the top of my head what specific path you should take from 3DS max to get the results you want. The advice I usually give is to fiddle around until you find a path that produces an acceptable end result, and stick with it.
Post Reply