RE: animation [math correction]

On Fri, 2002-07-19 at 20:24, Greg Copeland wrote:
> > Theoretically right. How large will this file be then? 
> > For an animation lasting 60 seconds we need, considering 24 frames per
> > second 1440 points in time. 
> > Several hundred objects in the scene, all with animations, would make the
> > scene file quite big.
> 
> Well, let's put this into perspective.  What type of data will we be
> needing to store.  Mostly likely, tuples containing three
> ints/longs/doubles or some such type.  I think we can agree that even if
> we multiply the number of points by 10, we're still not talking about a
> lot of space.  That works out to be something like:  1440 (scenes) *10
> (number from pocket) *3 (number in set) * 4 (bytes in a double) =
> 172800b or 168.75Kb.  Not hardly anything to write home about.
> 
> Of course, I fully expect it to actually take a little more than that,
> nonetheless, I still don't think we're talking grossly extreme numbers.


I realized, after re-reading my posting, I made a mistake in the math. 
So, here's the correct stuff:  1440 (scenes) * 10 (number from pocket) *
3 (number in set) * 8 (bytes in a double) * 200 (objects in scene) =
65.9M.

Even with a *very* complex scene, that's still very reasonable.  I know
that if I were working on a very complex scene, 66M of cached data would
easily be worth it's weight rather than having to wait for 66M of data
to be constantly recalculated.

Keeping in mind, I also included a reasonable fudge factor (*10) in
these numbers too...so, depending on how the nature of the data actually
turns out, it's certainly reasonable to assume that this number can be
much smaller, even for a complex scene as mentioned above.

Also, worth noting, this example also assumes that EVERY object is in
motion.  If an object is stationary, there is no reason we would need to
track any data on it; other than it's initial position.  That is, we
would only need to cache delta scene data.  If you advance in time, you
know your implementing a delta...if your rewind/reverse in time, you
know you're undoing a previously applied delta.  The application of
deltas would surely be faster than recalculation.

My point being, there are any number of ways which this number can be
further reduced.  These tactics are not even attempting to use some form
of stream compression.  Needless to say, I would suspect this type of
data would compress rather well.

I invite you to rework some of the numbers on some much simpler
animations with a more conservative fudge factor and see if the numbers
don't get significantly better.  Which, in my mind, 66M is still very
reasonable for an animation that complex.   

Greg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9OZdE4lr1bpbcL6kRAqFVAJ40ZGSahIbDT2WpaaYGU0rOr0mKyQCeKDzo
78Dflwen35dIatYyVDOnO9A=
=pcuT
-----END PGP SIGNATURE-----