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
