This is great to see! I have something similar in the wings that's only
partially implemented, but in XML instead. It stores most of the stuff
Jo was talking about. I wrote it as a way to export cameras and nulls to
Nuke and Fusion. My goal is to have a series of tools for various apps
all writing and reading a common XML file. Cameras and nulls can be
exported, then updated if something changes. With custom UI for setting
options. Anyway, I haven't finished writing all the different plugins,
but I've got a couple of apps covered already. I debated between JSON
and XML and finally just went with XML.
Glad to see this in the works, Gene! Can't wait to see more!
-Tim C
On 7/10/2013 7:10 PM, Raffaele Fragapane wrote:
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] <mailto:[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] <mailto:[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!
--
Signature
