We are developing a PRT v1.1 specification that introduces metadata, and arbitrary data storage into PRT files while maintaining backwards compatibility. In order to achieve backwards compatibility we were unable to add structural changes to the way data is stored in the file (like storing it in hierarchical fashion, etc.) which is why this will be v1.1 of the PRT specification instead of v2.
Please review the attached document and provide feedback.
In the near future we will provide versions of Krakatoa that support the new additions. PRT File Format v1_1.pdf (209 KB)
Interpretation looks cool, but I’d like to see more. Like how to convert between “standard” types. So if we have a uint8 channel named “Density”, which Krakatoa (or our own PRT editing tools) will convert to float32, how do we want that to happen, as [0.0,255.0] or [0.0. 1.0]? We could specify that.
Sort vector? So if the particles are sorted you could store that point?
The LengthUnit table seems arbitrary. You have an int32, but only define 7 actual units. Not sure how many Maya users use yards, but who knows what other hosts for SR use. But I’m wondering if there shouldn’t just be a float32 “Scale” that is used against a standard unit. Like if the Scale is 0.0, then you consider it unitless, but otherwise the value is a multiplied by the base unit to get the new unit. So lets say we standardize on inches (just to be ornery), a Scale of 2.54 would indicate centimeters.
Keep in mind that your custom PRT reader/writer is able to add whatever metadata name/value pairs it wants in the ‘Meta’ chunks. You are also able to create your own chunks that store arbitrary data (ex. a subset of particle Position & Color for approximation). We don’t have immediate plans to integrate a sort direction vector into the particle pipeline, but you are free to add it for your internal projects.
I made the LengthUnit table match XMesh (which I suspect matches 3DS Max). The benefits of the table of values is that we have nice user-displayable names for each unit type, as well as an implementation defined precision for the conversion. If we stored a float32 or float64 conversion to a reference unit that limits the precision of the conversion.
I’m not convinced that any of those points are super important, but I’m also not convinced that arbitrary non-standard units are helpful either. I think the display names thing is probably the most relevant.