• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
rabbit77

Scaling physics simulations

4 posts in this topic

Hi, i'm having trouble using an integrated version of ODE, basically i'm modelling a golfball. If I use the correct dimensions, mass, friction, etc the collision detection fails unless I raise the iteration step very high, however this is intended for the Android market so that's a no no.

 

I'm attempting to scale everything manually.

 

If I remember correctly if scaling by 2 the volume is multiplied by 8, but in this case should I multiply the mass by 8 or by 2?

 

That beside, in tests the angular velocity seems totally off. I initially (before scaling) apply an angluar impulse of 500 radians per second, after scaling this looks very slow, so I doubled it, and then multiplied it by 8, but still it appears wrong. Should I be ammending the friction, dampening, bounce, etc?

 

 

Thanks for any help...

 

 

 

(I've not prefixed this with ODE since I believe it applicable to all really?)

Edited by rabbit77
0

Share this post


Link to post
Share on other sites

Well, for the second question, yes, doubling the dimensions increases volume by 2^3 = 8 (since you're doubling in every dimension) and since density = mass / volume, we have mass = density * volume, since density is supposed to be constant, if you are multiplying the volume by X you must multiply the the mass by X to keep the density constant.

0

Share this post


Link to post
Share on other sites

I don't have a specific answer, only a thought, or possible approach.  Your problem made me think of astrodynamics work I've done (computation of the orbits of satellites, spacecraft, debris, asteroids, etc).  That field has a similar problem.  If you try to compute orbits the "obvious way", namely just sum the gravitational forces of relevant objects (usually sun and planets), to get any sort of precision you must reduce the time step to absurdly tiny increments, and the computations take forever (far longer than is practical).

 

In effect, at each time step you compute the position and velocity, compute the next position, then repeat.  Which means, the computation assumes the object moves in a straight line between computations.  While that may seem reasonable given the huge distances involved, the difference between the computed and actual path is fatal to medium and long term precision.

 

The usual solution is to go ahead and compute the forces of massive objects at each timestep, and adjust the direction and velocity accordingly.  But then what you do is take that linear position and velocity, and compute the conic (ellipse, parabola, hyperbola) orbit that position and velocity corresponds with relative to each massive body (sun, planet, moon), and sum the changes in position and velocity those influences generate (to the conic orbits).  Therefore, the changes between time steps are not linear, but correspond to conic orbital paths, which are correct to vastly greater precision.

 

This is, of course, annoying, since at every step we must convert from linear position, velocity, acceleration to [multiple] conic orbits, then perform computations, then convert back to linear again.  However, that's what it takes to assure the spacecraft or asteroid passes near earth (or moon, etc) rather than impacts into it, or vice versa, or gets lost over time, etc.

 

You likely need to find something similar... some way to represent and compute motion through fluids over longer time frames, then convert back to linear form again at each conveniently long time step.  I don't know what those longer-term path equations are, but you probably need to find out.  This approach will help (if you can find the appropriate equations), but your "longer time step" still can't be too long.  I'm guessing maybe 0.100 to 1.000 seconds may be practical.

 

That's my best guess off the top of my head.

Edited by maxgpgpu
0

Share this post


Link to post
Share on other sites
You can get the scaling working, but it won't help you at all - all you're doing is changing units. If you make all your lengths bigger by a factor of 10, your masses need to increase by 1000. However, if you don't want everything to look like it's in slow motion, gravity will also need to increase by 10, as will your velocities, so you'll end up with exactly the same penetration problems.

If you've only got one object to simulate then you probably can afford to have a pretty high simulation rate (I use about 300Hz in my flight sim, PicaSim), but I suspect it's not going to be good enough. The max golf ball speed is 200mph, so 90m/s. For a diameter of 4.5cm that means it travels its own length in 0.045/90 seconds, which means you need a physics update rate of at least 2000 per second, if you don't want the ball to penetrate the ground significantly.

If ODE supports continuous collision detection (CCD), that should help, and you can run at more sensible timesteps. Bullet (which you can use on Android & iOS) does. PhysX - free on Android does (it's available on iOS, but I'm not sure if it's free).

However - CCD will prevent penetration but you might end up with weird angular velocities when the ball lands. This will likely be really difficult to tune and adjust - which will be important to you.

My recommendation would be to ditch the physics engine and roll your own. It's not that difficult since a sphere will only ever have one point of contact, and that with a static object. Physics engines are only complicated because they have to handle multiple contacts between dynamic objects etc. This way you have complete control over the ball movement and can easily tune it to provide the results you want.
0

Share this post


Link to post
Share on other sites

What is the golf ball colliding with?  A heightmap?  Anything else?

 

I ask because the problem of detecting collisions between a sphere and a heightmap is a lot simpler than the general collision detection problem.  There is a lot of structure to the problem that a general-purpose physics engine won't exploit.  Specifically, you always know whether the ball is below or above ground by comparing its altitude to the terrain altitude -- regardless of whether you have "noticed" an intersection between the sphere and the terrain's infinitely-thin surface.

 

If you were to approximate the ball by a point, then this would be trivial:

[source]

if(ball.z > terrain_height(ball.x, ball.y))

{

  // Above ground

}

else

{

  // Below ground

}

[/source]

 

Since your ball has a nonzero radius, this gets very slightly trickier, but not by much.  Formally, the thing you'd want is the Minkowski sum of a sphere with your heightmap.  I'm assuming you actually have a very special case -- that your sphere's radius is smaller than 1/2 the vertex spacing in your heightmap -- which will make things simpler.  I haven't worked out the details myself, but I assume other people have and you can find them with some googling.  It's going to boil down to a few cases: When you're near a concave vertex, your dilated heightmap will return the z-coordinate of a sphere of radius 'r' centered at that vertex, and when you're away from a vertex, it will return the height of the corresponding plane pushed out by a distance 'r' along its normal (where 'r' is the radius of the golf ball).  I've illustrated this in 1d below: The original heightmap is in blue, and the "dilated" heightmap is in red.

 

[attachment=13653:heightmap-sphere-minkowski-sum.png]

 

[EDIT: In fact, other people have had similar problems with ODE and heightmaps.)

Edited by Emergent
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0