I started a toolset a few years ago based on XML as well. It works and I can store robust data, but the downside is the file sizes are huge and slow to read/write. Memory becomes an issue at some point. If you only want to transfer cameras or simple stuff, it works fine, but large scenes with lots of animation data is not advised with XML as other formats may be better suited.
Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Crowson Sent: Wednesday, July 10, 2013 5:34 PM To: softimage@listproc.autodesk.com Subject: Re: Open source json camera I/O platform 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 <alok.gandhi2...@gmail.com<mailto:alok.gandhi2...@gmail.com>> 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 <raffsxsil...@googlemail.com<mailto:raffsxsil...@googlemail.com>> 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! --
