The unit needs only be an arbitrary value in the header. Autodesk can say whatever it wants, but the truth is that if you change maya from imperial to metric at the beginning of a project (and you might have that on client's side) there will be repercussions, and if your cameras were intended as 1cm but get imported as 1 inch things will be out of whack. Majorly.
Several parameters, especially so if this will get a further level of abstraction later on, are actually world scale dependent. The flm back can change with a unit change (in some apps it does, in some it doesn't), several rendering and grooming parameters change and so on. As for scale, I've had plenty instances when the camera was scaled for various reasons, frequently enough to be relevant entire chunks of a pipe would rely on a stupid-renderman-trick style scaled camera. On Thu, Jul 11, 2013 at 2:10 PM, Gene Crucean <emailgeneonthel...@gmail.com>wrote: > Thanks for the input guys! I'm ingesting all of it :) > > I'm quite against adding units into the main camera section of the file... > but what about adding them to the metadata section? I really don't > understand why anyone would want this in the file though. Units should only > be conceptual imo. Autodesk says that 1 SI unit = 1 decimeter, but it has > no concept of units... at all. Our current project is in meters, so > conceptually we just know that 1 SI unit = 1 meter. Did we change anything? > Nope. Same thing in Maya... 1 unit = 1 meter. Didn't change a thing on the > Maya side either. I would love for someone to give me an example of why > this should be different. > > Either way, I'll have an update tomorrow at some point, along with i/o for > Houdini and updated Soft scripts. Maya is next and then hopefully I can > talk one of our Nuke dev's into banging out an importer. Unless someone on > here knows it's API and want's to donate some skills (once the 1.0 spec is > finished). Same with any other apps :) > > Cheers > > > On Wed, Jul 10, 2013 at 6:59 PM, Matt Lind <ml...@carbinestudios.com>wrote: > >> 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> >> 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> 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!**** >> >> ** ** >> >> -- **** >> >> ** ** >> > > > > -- > -Gene > www.genecrucean.com > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
