When you'll have at most a few dozen curves, even on a thousand frame long sequence, I honestly don't think cheapening the data matters one iota. You can always introduce a zip compression stage to the I/O.
Optimizing early and ending data poor is always a mistake. Purging is easy, both on I/O and in dev terms, adding data you don't have is usually betwene painful and downright impossible. If footprint was a concern here, sure, it'd make sense, on something that on a bad day will have a hundred parameters at the most (and for a mono cam I'd struggle to think of a hundred parameters I'd want animated) saving 16 floats per frame instead of 64 makes little difference in practical terms. On Thu, Jul 11, 2013 at 10:01 AM, Alok Gandhi <[email protected]>wrote: > Hey Gene looking at your schema I do not see animated value for parameters > like focal length, near and far planes. Though near and far are not usually > keyed but you never know. I have worked on a stereoscopic project and we > did need to plot the clipping planes. Anyways, focal length does fairly get > animated at times. In the interest of generality and being generic I would > make room for values for nearly all animatable parameters. For the case of > optimization the writer plugin can use only one value in the list if the > parameter is not animated else it will take all the key frame values. Also > I would not care for the whole keyframe and tangent data in the list but > would simply read the values of all parameters at each frame and plot the > same when I am reading the values. But what you are doing with keyframes > value storage also works, in fact I think it reduces the file size > considerably in case you do not have much keyframes in the source scene. > > > On Wed, Jul 10, 2013 at 7:41 PM, Raffaele Fragapane < > [email protected]> wrote: > >> Units and scale, and how they correlate, are extremely important even in >> a light weight, portable format. Actually, probably more so in one than in >> a more complex scenario. >> >> You can't assume people will not care about those because their workflow >> will be independent of it like yours was for a few example productions, >> because very frequently they won't have the choice. >> >> As an interop format that deals with external contributions (rendering >> engines and so on being heavily dependent on it) you WILL bump into scale >> factors whether you like it or not, and the format will be rendered useless >> by not having control over those when it'll happen. >> >> There are things one omits or includes for the sake of forecfully >> encouraging good practices, those are practical-philosophical choices and >> are fine, and best made by a benevolent dictator for the project (any half >> decent programming language out there has craptons of those, and they are >> important to give languages and format identity and coherence). >> Scaling and units are not one of those, they are a fundamental >> requirement implicit to what you set off to describe with these files. >> > > > > -- > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
