http://qs321.pair.com?node_id=920368


in reply to Re^2: 2d animation
in thread 2d animation

Hm. OKay, but still at somepoint, someone is going to watch these movies right?

Drawing, compressing, shipping and displaying 60 frames a second of video in order to display 60 individual numeric values per second is a laborious, time & space consuming way of allowing them to see it. Especially if there are going to be many such videos.

It would be far more cost effective to construct a simple application that reads the raw timestamp/value pairs from a file and draws the scrolling line trace on the users screen on demand. Then you give the user(s) the application once and send them the raw data files -- which will compress readily -- as they become available.

My estimate is that 10 minutes of raw data -- say 2 x 64-bit float values per reading -- 16 * 60 * 60 * 10 = 1/2 Mb uncompressed and reasonably, less than half that zipped.

The same information captured as 640x480 video will run to ~60MB. Even if you radically compress it with a lossy codec, you'll be very lucky to get much below 30-35MB. And the results would be hideously blurry, blocky and inaccurate. Effectively useless for anything other than "Ooh. Look at that!".

I also seriously doubt that you'll be able to render the movies in real-time, which means you'll first have to record the data, and then play it back -- via some application that renders the scroll line trace -- so you can record that as the movie.

So, you'll need a line tracer anyway to create the movies. Once you have that, why not just give a copy to the user(s) and let them see the actual trace rather than wait for you to produce and ship some huge, blotchy movie of it?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.