Thread: [Algorithms] Compressing recorded locations/rotations from massive rigid body simulations
Brought to you by:
vexxed72
From: Jesse J. \(2K Boston\) <Jes...@2k...> - 2008-10-28 21:55:09
|
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 |
From: Kain S. <kai...@gm...> - 2008-10-28 22:43:51
|
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 > |
From: Jon W. <jw...@gm...> - 2008-10-28 23:10:04
|
Jesse Johnson (2K Boston) wrote: > > 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 :) > > > We do this for all networked entities potentially for an entire world/cluster in our virtual worlds platform. We capture all the state for later re-play and analysis (VCR controls for users). However, we use the input-synchronous method, so playback involves infrequent state snapshots with actual physical simulation of the areas of interest inbetween. The files aren't terribly big -- a megabyte goes a long way for a lot of objects for a significant duration. We also store information other than position/orientation, because we record things such as avatar posture, clothes changes, vehicle controls, etc. Actually, the movement of your bodies can probably be treated as sampled keyframes for animation (as if you were exporting out of a modeling package), and you can use the same animation compression mechanisms (wavelets, spline fitting, etc) that we discussed last week on this list, to compress your data. Sincerely, jw |