Minor pet peeve with how you're storing date and time as a string... you're missing seconds! but I think it might be more efficient to store the unix timestamp (seconds since epoch) instead of a fully formatted long string. Let the reader module handle the datetime formatting.
On Thu, Jul 11, 2013 at 9:41 PM, Gene Crucean <[email protected]>wrote: > Update: https://bitbucket.org/crewshin/json-cam > > Output file: > https://bitbucket.org/crewshin/json-cam/src/bae3c009d10002aa6d033036079064eda9d4d8d0/FromSoftimage.cam?at=master > > ScreenGrabs: > > https://bitbucket.org/crewshin/json-cam/src/bae3c009d10002aa6d033036079064eda9d4d8d0/Export.png?at=master > > https://bitbucket.org/crewshin/json-cam/src/bae3c009d10002aa6d033036079064eda9d4d8d0/Import.png?at=master > > Spec: > https://bitbucket.org/crewshin/json-cam/src/bae3c009d10002aa6d033036079064eda9d4d8d0/SPEC_1.0.txt?at=master > > > Thoughts so far? I should have Maya in the next day or so. Btw, feel free > to send pull requests for tweaks if interested. > > > @Jordi: Wanna give that Houdini .otl a test? > > > > On Thu, Jul 11, 2013 at 8:56 AM, Gene Crucean < > [email protected]> wrote: > >> 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 >> > > > > -- > -Gene > www.genecrucean.com >
