Hey Jo,
Quick thoughts...
> - 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)
This (imo) should always be the software's default unit, and changed
conceptually for each project. For eg. We use Houdini, Softimage and Maya
(among others). Our current project is using meters because of scene scale.
We didn't change a single unit type in any of the apps and just assume that
1 unit = 1 meter. Super easy and the way it should be done imo. So I guess
to answer your question... I feel it's a bad idea to store units in the
file itself.
> - 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.
This goes along with why we are even creating these tools in the first
place. A nice baked down, simple, lightweight and reliable camera transfer
format. I don't want to pass around a full rig. I just want a flat baked
cam in global space.
> - scale: required (even if 1 is always assumed)
Always assume it's 1 and handle accordingly in each apps plugins. No need
to include this in the file.
> - double precision: do we really need to store so high precision doubles
for transforms? (having an option would be nice)
What is the downside? A tiny bit bigger file size?
> - 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.
No tool will ever work for *all* studios. JSON is a huuuuuge standard and
> - spec version: backward compatibility reasons
This is v1.0.
> - channels: allow the export of channels/extra attributes (would be
parameters in softimage)
Which channels are you referring to?
> - 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...
Again is this more about file size? Because huge frame ranges still produce
tiny files. I left it so that each channel posx, posy, posz, rotx, roty,
rotz all have independent frame ranges just in case we ever had a need to
support offset ranges on each axis. I understand that I'm contradicting
myself in my own exporter, but I thought it might be nice to at least leave
the spec open to things in the future. As it is now, just use len(posx) to
get the frame count and loop accordingly.
> - namespaces: believe me this will very quickly become a nightmare!
Arnold doesn't use namespaces. I'm just saying. Nice, but not necessary.
Having said that, I'm completely open... what is your main argument for
them?
> - ids: you always want ids... (for very quick comparison, and integrity
checks)... we can't rely on names.
Hmm... ??
> - 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).
{"Camera1":{"meta":{"software":"Softimage 2014",
"anythingYouWant":"data"}}} coming right up.
Do you think it's important to define exactly what key:values are expected
and limit it to just those? Or just leave the metadata dictionary
completely open?
Please don't take my email as a bashing. I really appreciate your comments
and I hope more come from it. I just want people to understand the point of
this tool. It's not an all encompassing format like FBX. That's
*exactly*what I don't want. I envision this as a VERY simple tool that
only has what
is needed to define a camera and it's transforms in a format that 99.9% of
all apps will be able to support and read. JSON is a verrrrry supported
format and there are libraries to work with it for all languages used in
this industry. Python has native support. For eg...
import json
jsonData = open("/Path/To/camera.cam")data = json.load(jsonData)jsonData.close()
Boom... "data" is a dictionary. Use as needed.
On Wed, Jul 10, 2013 at 11:22 AM, jo benayoun <[email protected]> wrote:
> 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
>
>
>
--
-Gene
www.genecrucean.com
