Hey Gene,
that's a very good idea and if well developed could de facto become useful
to many studio outta here (most comes with their own because of this lack
of standard that would answer any needs).
Some rough notes though if I may:
- unit: as soon as you store transforms in a file, you want to keep track
of what units have been used (houdini, maya, etc are not using the same
scene units as units are usually set per show)
- camera rigs: cameras can be quite complex hierarchies, would be great to
have a way to describe what our camera rig is and it to be correctly
exported.
- scale: required (even if 1 is always assumed)
- double precision: do we really need to store so high precision doubles
for transforms? (having an option would be nice)
- file format: your backend should not be that tied to the exporting code
(use abstraction)... for many studios, json is not suitable and they might
prefer for legacy reasons to use others or use binary formats for
compression.
- spec version: backward compatibility reasons
- channels: allow the export of channels/extra attributes (would be
parameters in softimage)
- frame ranges: use frame ranges. if your range is from 0 to 99, you dont
want to write an array of numbers, considering that:
10 + (90 * 2 characters) + 99 commas + ']' + '[' = 291 bytes (with no
counting whitespaces + newlines chars)
while
'0-99x1' = 6 bytes...
- namespaces: believe me this will very quickly become a nightmare!
- ids: you always want ids... (for very quick comparison, and integrity
checks)... we can't rely on names.
- metadatas: what department produced it? for what role? has it been
published as an asset? how many cameras? etc. You usually cant guess right
what they would be, so allow your users to have a storage place where they
can store them (available in your API as a dict or whatever datastructure
for clients to manipulate them).
- ...
hope this contributes!
:)
--jonathan
2013/7/10 Jordi Bares <jordiba...@gmail.com>
> I really love the idea, if we can help surely that would good… Houdini
> import/export
>
>
> Jordi Bares
> jordiba...@gmail.com
>
> On 10 Jul 2013, at 14:54, Michael Heberlein <micheberl...@gmail.com>
> wrote:
>
> Sounds like a good idea. There are a few things I would like to add:
>
> I'd prefer one common class/module for file IO and all the necessary
> conversions like millimeters <--> inches, focal length <--> horizontal view
> angle, picture ratio <--> film aperture, etc. so each application module
> can derive from this and stay as lightweight as possible.
>
> Another module could handle the dialogs but if they're optional, it's
> easier to integrate the importer/exporter into a scripted pipeline or
> toolbars. Plugins could just use the correct application module but be
> separate files again so people don't have to use them.
>
> Also, to make it not just another almost-useful tool, don't forget less
> common properties like optical center shift etc. required by stereo setups,
> for example. As you already wrote in SPEC.txt, all expected units have to
> be defined.
>
> Michael
>
>
>
> On Wed, Jul 10, 2013 at 8:53 AM, Sandy Sutherland <
> sandy.mailli...@gmail.com> wrote:
>
>> Gene - this would be of huge interest I think - every studio I have
>> been at we have needed to do this, and have always fudged it - never had
>> the time to even start looking at creating a tool!
>>
>> So - a big yes from me!
>>
>> S.
>>
>>
>> On 2013/07/10 5:09 AM, Gene Crucean wrote:
>>
>> Hey folks,
>>
>> Who's in the mood for some open-source camera I/O code? I'm kind of
>> getting bummed out on having to write the same camera tools at every studio
>> just to get a simple, lightweight and most importantly reliable camera
>> pushed around from app to app. FBX does *not* cut it, not to mention it's
>> not available for all apps that could make use of it. So I thought I would
>> whip up a spec based on json and offer it up open source so anyone willing
>> to donate some time, could create some simple tools to import/export for
>> their favorite app. The spec is VERY lightweight and doesn't include some
>> things that I'm sure someone will want... but please let me know your
>> thoughts.
>>
>> I already have a Softimage plugin working (consider it alpha). At this
>> point it only has minor sanity checking and logic tests and I'm sure there
>> are a zillion ways to improve it. But it's a start. The goal is to at least
>> have plugins that all read and write the same spec from Houdini, Softimage,
>> Maya, Max, Blender, Nuke... and more. I've built the Soft one using PyQt
>> and it would be nice to maintain some consistency between apps, so I'm
>> hopeful that the other versions could be based off of the same .ui file.
>>
>> What do you guys think? Any interest in this? I know it's a simple
>> thing but I'm sure a lot of you also write these tools at studios quite a
>> bit too and could possibly be into something like this.
>>
>> Check out the spec and source, and if you have time, play with the Soft
>> plugin here: https://bitbucket.org/crewshin/json-cam
>>
>>
>> If you have completely zero interest in this... no worries. Thanks for
>> looking.
>>
>>
>> --
>> -Gene
>> www.genecrucean.com
>>
>>
>>
>
>
