would it make sense to integrate a yz flip button when exporting, so max particles can line up with maya and naiad coordinate system?
allowing to save pflow to .prt directly with axis flip
or maybe im missing it?
Why would you want to?
The issue is that the scene you imported from Maya or Naiad was rotated, right? And if that’s fine, and the PRT itself needs to be flipped, that’s a problem for Maya or Naiad. They’re not following the spec if they don’t do the transform for you.
The current version of the PRT format itself is built around 3ds max anyway. I don’t think there’s anything in the header saying what the coordinate system is, so you’d have to guess each time you opened a file. This could be disastrous since you’d have to visually check all the files on import (or risk wacky renders).
no just to get particles into naiad (or maya)
so this is for partic les to be used outside of 3ds max,
the naiad exporter plugin for 3ds max geo has a checkbox for flipping axis when exporting (just like the normal export menu)
for flipping the axis,
would be cool to have this option when saving out .prts if they are used outside of max,
So they need the PRT importer in Naiad to flip the coordinate system, too.
It would be the same as if you had some software that read the byte order backwards in an image file that doesn’t specify byte order in the header. You’d get an upside-down image, but it’s not the exporter’s fault that it’ s following the byte order in the spec.
You’d need to wait for PRT 2.0 (with a TM in the header describing the change from the current transform in the header) or report a bug to Autodesk.
its no ones fault, its not about judging, one is good or bad etc.
just nice to be able to export in 3ds max from krakatoa, and be ready in maya-naiad coordinate system
this feature is offered by autodesk geometry exporter in 3ds max, and also naiad geometry export feature, so its a common thing and not too complex i imagine
since krakakatoa is the only particle exporter (except realflow .bin exporter) for 3dsmax, i humbly thought it would make sense, thats all
it would have been cool to have this option
Well, except that it is. All .PRT files have the same coordinate system, just as all .PRT files have an uncompressed header and little-endian byte order. If you change the coordinate system in the file you make particles that are actually more likely to hang up a pipeline than if you messed up the header, since it would be just as much an error, but would be silent.
The onus for converting to the host coordinate system lies entirely with the .PRT reader and it must assume that it is written the same as all other .PRT’s, and the .PRT writers must all write out their files the same way. It’s the only way we can get something useful for an interchange format.
Of course, this could all change for version 2 of the PRT spec, but for now the spec needs to be followed.
Except that nobody is following the Z up coordinate system rule outside of Max, not even us. 
Krakatoa Maya writes PRT files as Y up. Naiad writes out files as Y up. Have not looked at what RealFlow does, but I suspect their PRT files aren’t Z-up either…
You are right that we need a solution, and it should be a hint in the metadata, so the loader knows what to do with the incoming positions.
When loading BIN files, the PRT Loaders in Max and Maya flip the left-handed coordinate system to right-handed, Z or Y up, because we know what the BIN file specification requires.
So you write out PRT’s from Maya that don’t read into Max correctly? That’s kinda nutty, considering they’re your own products and own file format.
So you write out PRT’s from Maya that don’t read into Max correctly? That’s kinda nutty, considering they’re your own products and own file format.