well job Gene, I would now spent a bit of time on the code itself to make it more flexible. It would be great to have clear separation between plugins, core lib and ui code imho.
@Alan, don't do that please... http://en.wikipedia.org/wiki/Year_2038_problem 2013/7/11 Alan Fregtman <[email protected]> > 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 >> > >
