We have posted a PRT v1.1 specification for your review. http://forums.thinkboxsoftware.com/viewtopic.php?f=114&t=9670
aha “You are not authorised to read this forum.”
I suspect it impossible for me to understand developnese anyway 
Don’t worry. It’s generally a response to some of threads you’ve seen on here before like…
viewtopic.php?f=62&t=6171&p=24653
viewtopic.php?f=164&t=9424&p=40350
viewtopic.php?f=62&t=8757&p=38399
Maybe Darcy or Bobo can put a link to the pdf here? I can read the other forum, but can’t seem to post there anymore.
Couple other comments…
It might be nice to indicate a time step for channels like velocity or spin. Right now we don’t know if the velocity is specified as 1/60th of a second or per second. They’re easy to scale if we know what the reference time unit is.
How about a transform, so we could have a PRT with local coordinates for the channels?
Regarding the LengthUnits, are you expecting that to be used to scaling or just for display units? It seems the scaling would be more important and why I was thinking that a factor against a reference unit would make more sense, but if you were thinking of display units, then I’d have to rethink that, but I’d also not know what the use case entails, really.
Everything should always be per second. No need to have anything else. I suppose the specification could indicate that all time based values are in seconds.
As in “embedding the object to world transform” or having “a per-channel transformation”?
I think the object to world transform is a scene graph property, not a particle collection property so I don’t think it makes sense for the PRT file. You could add a custom metadata entry for the transform and use it if you wanted, but in Krakatoa I prefer to have the scene node manage the object to world transformation.
On the other hand, why would someone want to store some channels in a different space? Seems overly complicated to me. We are trying to only make “standard” metadata name/value pairs for data that we will actually do something with in the next version of Krakatoa so the collection will be conservative at first.
The actual usage will be to convert PRT file data into the application space you are using it, but we also intend to display the file metadata in a dialog so its nice to have “inches” instead of “0.0254”. Do you often work in units outside of the mm <-> mile grouping? Why is this important?
So Velocity will be LengthUnits/Second no matter what the rate the Position changes per PRT file?
For the transform, it’s an issue where we, say in 3ds max, load a PRT file, offset it with the PRT Loader, then want to save it out to a PRT file and bring that back in. Does the new PRT file get offset with the same transform as the PRT Loader? There would be a double-transform then if the second PRT file was written out in world space (as it does now).
Still think the units don’t matter. If the standard LengthUnits was inches (as it sorta is based on legacy 3ds max?) then a LengthScale of 0.0254 would work for conversion to meters without having to specify it as such. So a Maya user who has a scene in yards or a Blender user who has a scene in cubits wouldn’t be left out, they’d just have to convert from inches to the their internal units. There’s no precision issue for the common units you’d have in the enum anyway, and however someone defines cubits would be up to them to determine the conversion from inches. And for application that wanted display units, they could see LengthScale = 36 and display either “36” or “yards”. I guess I’m just arguing for float32 scalar, not an int32 enum, as I don’t see the point except for display units but it adds a lot of complications for applications using units outside of the enum.