RE animatable parameters: This spec currently allows for any param to be animatable by just adding it to the "anim" dictionary. All the importers/exporters would have to do is simply check if any param besides transforms exist and add keyframes. This would be left up to the individual app scripts to implement, but the spec itself would allow for anything to be animatable.
On Thu, Jul 11, 2013 at 1:41 AM, Michael Heberlein <[email protected]>wrote: > 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 < > [email protected]> 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 < >> [email protected]> 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 <[email protected]>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:* [email protected] [mailto: >>>> [email protected]] *On Behalf Of *Tim Crowson >>>> *Sent:* Wednesday, July 10, 2013 5:34 PM >>>> *To:* [email protected] >>>> *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 < >>>> [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!**** >>>> >>>> ** ** >>>> >>>> -- **** >>>> >>>> ** ** >>>> >>> >>> >>> >>> -- >>> -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! >> > > -- -Gene www.genecrucean.com
