Hehe... I love unixtime and use it for all kinds of stuff. The way I see it, if my code is still around in 2038, I did DAMN good :D
I feel ya Jo. I'd love to abstract all this but my Python skills are weak at best. I'm an Obj-C guy and can't stand python to be honest. Please feel free to tweak it and shoot me a pull request if you feel strong enough about it. On Thu, Jul 11, 2013 at 11:15 PM, Alan Fregtman <alan.fregt...@gmail.com>wrote: > *Oh my...* > > So what's the ideal short-form datetime storage? A long string? > > > > On Fri, Jul 12, 2013 at 2:00 AM, jo benayoun <jobenay...@gmail.com> wrote: > >> 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 <alan.fregt...@gmail.com> >> >>> 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 < >>> emailgeneonthel...@gmail.com> 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 < >>>> emailgeneonthel...@gmail.com> 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 < >>>>> micheberl...@gmail.com> 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 < >>>>>> 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! >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> -Gene >>>>> www.genecrucean.com >>>>> >>>> >>>> >>>> >>>> -- >>>> -Gene >>>> www.genecrucean.com >>>> >>> >>> >> > -- -Gene www.genecrucean.com
