A bit off-topic already :) but I just found pyalembic in Gohlkes invaluable Windows binaries list: http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyalembic
But I also agree that something as simple and readable as JSON would be cool to have for (plotted?) world-space camera exchange. And _all_ parameters should be animatable. Michael On Thu, Jul 11, 2013 at 6:17 AM, Raffaele Fragapane < raffsxsil...@googlemail.com> wrote: > 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! >
