Re: [Algorithms] Compressing recorded locations/rotations from massive rigid body simulations

[Kain S. <kai...@gm...>]

Instead of storing snapshots of position/rotation, you can potentially store
the second order representation of position and orientation.  These stored
numbers would essentially be values to plug into consistent parametric
representations of position/orientation over time?
Details would still need to be fleshed out, but I would imagine this to be
an algorithm analogous to the simplest possible graphics compression routine
(where repeating RGB values are replaced with count + single RGB value).  So
in the case of physics compressions:

   - Entire sequences of position/rotation states can be sectioned off in
   relation to time between interactions that result in acceleration changes
   (i.e. Force applied).  With acceleration as a constant, we can
   mathematically model the physical state of the simmed object
   - In each of these sections where acceleration can be considered
   constant, you can use initial position/orientation and final
   position/orientation as well as the constant acceleration values for
   position/rotation to be able to simulate the first order state of those
   objects at any value of time relative to that section of the partitioned
   life of that object.

You'd still have to deal with management, calculation, and floating point
precision issues.  The floating point issues will probably prevent you from
ever achieving 100% deterministic accuracy.  If you absolutely need 100%
deterministic accuracy, then I suppose there is no way to get around just
brute forcing this and storing position/orientation values for every frame
while turning off physics sim reactions and faking your own gameplay-related
reactions (i.e. selectively apply artificial impulse) to detected collisions
during playback mode.

This also assumes that your physics sim will be consistent with whatever
parametric equation you derive/find.

And then you have subtle floating point precision issues revolving around
the time of the physics step combined with inconsistent framerates.

So ... yeah, if you don't have to worry about deterministic simulations of
those objects in your varied simtime (i.e. those objects will be
gameplay-inert and are purely for visuals) then this will work.  Otherwise,
I suppose your typical choices of bit compression algorithms to minimize I/O
would work for the brute force method.

-kain


On Tue, Oct 28, 2008 at 10:55 PM, Jesse Johnson (2K Boston) <
Jes...@2k...> wrote:

>  Hey all,
>
>
>
> I'm working on a system to record the positional and rotational data of
> rigid bodies in large scale physics simulations. The hope is that I'd be
> able to take these recordings and play them back in game to avoid having to
> do the simulations at runtime. I'm anticipating ending up with quite a bit
> of data as a result of this (ie, high frequency keyframes). Ideally, I'd
> like a way to compress this data down without sacrificing too much quality
> wise to save on memory, though some amount of quality loss will be fine. Has
> anyone had to do anything similar before? Can anyone recommend a solid
> approach to this? I'm not quite sure where the best place to start with this
> is, so any suggestions would be very helpful :)
>
>
>
> Thanks,
>
> Jesse
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>