@Alan, indeed, I usually tend to stay simple...
>>> datetime.datetime.now().strftime("%Y%m%d%H%M%S")
'20130711232548'
is imho acceptable as the number of bytes is constant and the format is
easy and fast to parse for the datetime implementation.
you still might find crazy stuff to pack a timestamp, though, I don't see
any direct benefits.
@Gene, I know. I am going to have more free time this summer, I might give
a hand.
2013/7/11 Gene Crucean <emailgeneonthel...@gmail.com>
> 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
>
