*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 <[email protected]> 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 <[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 >>> >> >> >
