Scaling factor between Newton and Gamebryo
Author
I am trying to use the renderer of Gamebryo with Newton Dynamics physics engine.
The renderer doesn't seem to render the physics parameters properly.
My question here is that, Is there a scaling factor involved while translating the Newton Dynamics values (distance, speed etc.) to the Gamebryo coordinates.
I am aware that the coordinate systems for both are oriented differently, and I have taken care of that in my program.
Gamebryo is completely unitless, e.g., your model can be in meters, inches, or miles. It does not matter. I expect Newton is the same.
You only need to make sure that you have consistency throughout your model. It is your responsibility to make sure your entire system has consistent units. No middleware package will fixup any problems you create.
BUT, you may not know about a problem you are inadvertently creating. Your content creation software may be the root cause of the problem, if you don't know some of the finer details about its settings. For example, if you are using 3ds max to build your 3d models, there is a thing called system units, and another called working units. Both are user configurable, but people tend to set the working units while ignoring the system units. Big, big mistake for game development. The system units are the units that get saved to a file, including exported files. Working units are what you see onscreen, in dialog boxes, etc. The idea is that if you are building your model in feet (working units), but your system units are set to meters, when you save the model out the vertices will all be in meters. Load it back, and since your working units are feet, 3ds max will convert so that your dialog boxes all show feet. The fact remains that the file stores everything in meters. And, it is then meters that get loaded into Gamebryo. Gamebryo doesn't care...it is only taking what you gave it, even if you are giving it something different from your intent.
I'm also a bit confused when you say the coordinate systems for both systems are oriented differently. I don't believe this to be the case. With Gamebryo, you model your system in a right-handed coordinate system. It is entirely up to you which direction is up, or front-facing. You have to orient your camera appropriately, for things to be displayed in a way that makes sense (up is visually displayed as up), but in terms of the engine it is 100% user-defined.
You only need to make sure that you have consistency throughout your model. It is your responsibility to make sure your entire system has consistent units. No middleware package will fixup any problems you create.
BUT, you may not know about a problem you are inadvertently creating. Your content creation software may be the root cause of the problem, if you don't know some of the finer details about its settings. For example, if you are using 3ds max to build your 3d models, there is a thing called system units, and another called working units. Both are user configurable, but people tend to set the working units while ignoring the system units. Big, big mistake for game development. The system units are the units that get saved to a file, including exported files. Working units are what you see onscreen, in dialog boxes, etc. The idea is that if you are building your model in feet (working units), but your system units are set to meters, when you save the model out the vertices will all be in meters. Load it back, and since your working units are feet, 3ds max will convert so that your dialog boxes all show feet. The fact remains that the file stores everything in meters. And, it is then meters that get loaded into Gamebryo. Gamebryo doesn't care...it is only taking what you gave it, even if you are giving it something different from your intent.
I'm also a bit confused when you say the coordinate systems for both systems are oriented differently. I don't believe this to be the case. With Gamebryo, you model your system in a right-handed coordinate system. It is entirely up to you which direction is up, or front-facing. You have to orient your camera appropriately, for things to be displayed in a way that makes sense (up is visually displayed as up), but in terms of the engine it is 100% user-defined.
Quote:Original post by grhodes_at_work
Gamebryo is completely unitless, e.g., your model can be in meters, inches, or miles. It does not matter. I expect Newton is the same.
I'd like to point out that for ODE, it's technically 'unitless' like you said, but some ranges of units work *a lot* better than others. When I switched from one unit is 64 pixels to one unit is one pixel, physics went bonkers. Things walking through things, etc. Now I've got my 'drawing units' at 1 pixel (it's 2D), and I just convert back and forth from physical units (which is something like 0.0004 units to one pixel). It adds some extra multiplications/divisions here and there, but it makes a big difference for the accuracy of the physics.
Of course, in a 3D game, your drawing units don't really matter, so you might as well make it whatever works for your physics too and save yourself the trouble.
Hello,
I actually work at Emergent Game Technologies as a Gamebryo support engineer. You should be able to use any arbitrary units and be OK. Just make sure that your camera up is the same as your art assets' up vector.
-Tim Kerchmar
I actually work at Emergent Game Technologies as a Gamebryo support engineer. You should be able to use any arbitrary units and be OK. Just make sure that your camera up is the same as your art assets' up vector.
-Tim Kerchmar
When using small floating point numbers (e.g., no values like 1e+27), you should not find that ODE goes bonkers when switching to different ranges. The issue is making sure that you scale everything to be consistent with different units. That means inertia tensors (if you specify these yourself rather than let ODE calc them). This means densities (if you change your length unit, then your units for density must change to be consistent). This means your gravitational setting, other forces you apply explicitly, and even tolerances and time steps.
Barring the use of floating point numbers with very large magnitude, it is perhaps the last item above----time step----that is the only legitimate reason to decide that you need to use one set of units vs. another. Since the stability of the sim can be affected by time step, but the maximum "stable" time step is a function of geometric dimensions, you might find that you have to pick one set of units just to enable running the sim with a particular time step. This isn't universally true, but when the system uses penalty methods for collision response, or has springs, the time step size does become a factor.
Barring the use of floating point numbers with very large magnitude, it is perhaps the last item above----time step----that is the only legitimate reason to decide that you need to use one set of units vs. another. Since the stability of the sim can be affected by time step, but the maximum "stable" time step is a function of geometric dimensions, you might find that you have to pick one set of units just to enable running the sim with a particular time step. This isn't universally true, but when the system uses penalty methods for collision response, or has springs, the time step size does become a factor.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
