When loading/saving PRT’s, are the files converted from/to Z-up? I’m not using KMY, but we’d like to support KMY produced PRT’s in our SR based products, and we were assuming that all PRT’s were Z-up, but we want to be sure.
PRTs make no assumption of what direction “Up” might be.
So, if you’re exporting a PRT from application A, and importing into application B. If A and B have different suggestions as to what the “up” axis is, then the user would have to transform the PRT data.
seems to me that we should be smarter than that?
Yeah, we’ve had that conversation before (regarding PRT 2.0). But in the interim, since NO transform matrix or other coordinate system identifier is specified, it should be fixed (at least for anything Thinkbox makes and for anyone who wants their stuff to be interoperable with Thinkbox stuff). And since most PRT tools are based on PRT’s from 3ds max, they’re built around a Z-up, right hand, no?
My concern with KMY is that it is Y-up, so unless you convert from Z-up to Y-up in your KMY PRT Loader, and from Y-up to Z-up in your PRT Saver/Renderer, things will be unpredictable.
It’s not just Position, you need to convert Velocity, Normal, Tangent, etc., right?
If the transform is applied at PRT Loader level, it transforms everything.
Between Max and Maya, you “only” need one rotation at -90/90 degrees about the X axis.
For BIN files, we perform the conversion internally because BIN files are Y up, left handed. The KMX and KMY PRT Loaders load the BIN files to match the appropriate coordinate system of the 3D application.
But RealFlow saves PRT files as Y up, left handed too, so they would come in quite messed up in both Max and Maya.
Even if the file itself does not tell anything about the source, it would be nice to have a drop-down list in the PRT Loaders that says "Source is: 3ds Max | Maya | RealFlow | Houdini | etc. and applies the correct transforms. Also like in XMesh Loader, it would be nice to be able to adjust the scale, e.g. RealFlow and Naiad PRTs could be scaled from Meters to whatever system units the user wants. Right now, for a Naiad PRT sequence, I have to enter 3937.01 % in Object Scale to when running in Inches…
That seems nutty, though.
If you just say “PRT’s are Z-up, Right hand, centimeters” then the onus is on whoever is writing the PRT to conform to that when they write.
Sure, Thinkbox can have a dropdown saying “Came from KMX”, but you don’t control where all the PRT’s come from now, so if someone was trying to get interoperability between Cinema4D and 3ds max and XSI, they might themselves determine that they should make PRT’s that are similar to the “reference” ones that come from KMX. But the more people use the PRT format and SR, your dropdown will have to get longer and longer, and for those of us making PRT utilities or SR implementations, we’ll ALSO have to make those dropdowns.
From a usability standpoint, a PRT that is Y-up, Left hand is about as useful as a PRT that has an “id” channel or a spheremap encoded “Normal” channel. 
EDIT: Oddly enough, I actually DO think that allowing float16 for Position is at times useful, and while that’s allowed by the PRT file format, it’s disallowed by convention. 
If anything, would it not be easier to just give the user up-per-axis controls, and whether left or right? Flipping through that until it is correct is much faster/more intuitive than saying this originally came from max, was then re-saved in houdini, and currently loaded in maya.
The only general solution is to use a new PRT format with meta data (PRT 2.0). The PRT files would have meta data which tells the loader which vectors represent “Up/Down”, “Left/Right”, and “Towards/Away”.
The partial reason we decided that PRT needed to be “Up” agnostic was to avoid endless user-error in Krakatoa SR. Krakatoa SR does not have a concept of “Up”. As long as the camera and the particles agree, it will render correctly. In Krakatoa SR land, the cameras, particles, and meshes live in a gravityless void.
But you could at least make sure that KMX and KMY were consistent, no? They should be able to transfer PRT files back and forth without user intervention.
This could happen if all the PRTs that KMX and KMY wrote used the same coordinate system.
And with that as the precedent, we’d be able to make KSR implementations that could reasonably assume that PRT’s were going to be of a certain format.
EDIT: Another option is to do an interim PRT spec. Call it 1.1, and just add the transform, units, and bounding box metadata. Everything else can wait for 2.0.
IMHO this is the ideal for all cases. It should be completely transparent to the user.
I like it…Conrad, bobo,ian , Darcy?
Cb
Which? The conforming of KMY to KMX or the interim PRT spec?
Adding some form of meta data to the PRT spec would likely be the best solution for defining coordinate systems and units. We would also be sure not to break the PRT 1.0 loaders.
We’re currently discussing a general meta-data system, and have a few “known” meta data values, which will solve the “how to transform the PRTs from one application to another” question.
There’s already a thread on here for that. viewtopic.php?f=62&t=6171&p=24653. Could we move discussion there or move that thread content to the SR forum? Don’t want to muddy up the Maya forum anymore with this.