tyFlow already has a Color operator (Vertex Color operator). It stores colors in particle map channel 0, which is 3ds Max's default vertex color map channel...or you can specify whatever channel you like.
Beyond that, color values themselves are just Point3s, and so are UVWs...so that's why they're interchanged within tyFlow, and the mapping workflow is used to blend between colors, etc. It's quite straightforward once you understand that colors can be stored as UVWs. I think any alternative to either storing colors directly in UVWs, or using UVWs to manipulate colors in something like a gradient ramp, would be more convoluted and less intuitive.
Let's say I want to blend between 5 colors over the course of a particle's lifetime, with the first 2 colors blending over the first 60% of the particle's life, and the last 3 colors blending over the last 40% of the particle's life. Currently all that's needed is a single interpolation value stored to a particle's UVW.x channel, and a gradient ramp. Done. How would that be done in some Color-operator-centric workflow? You'd have to continually send particles out to other events in order to change their color, independently wrangle interpolation values for each one...or you'd have to store a list of colors in each particle and then somehow wrangle their interpolation that way. It would be a mess. The UVW workflow is superior
The next build allows color export/import (to/from map channel 0) from PRTs. As for why XYZ renderer or plugin can't render colors from XYZ input...I think it's up to them to support Vertex Color colorization, rather than me to chase the tails of each plugin's own implementation. As for Alembic, in point cloud mode I don't export mapping values, just positions. I'd suggest a dedicated format for particles like PRT if you need the extra data.
Beyond that, color values themselves are just Point3s, and so are UVWs...so that's why they're interchanged within tyFlow, and the mapping workflow is used to blend between colors, etc. It's quite straightforward once you understand that colors can be stored as UVWs. I think any alternative to either storing colors directly in UVWs, or using UVWs to manipulate colors in something like a gradient ramp, would be more convoluted and less intuitive.
Let's say I want to blend between 5 colors over the course of a particle's lifetime, with the first 2 colors blending over the first 60% of the particle's life, and the last 3 colors blending over the last 40% of the particle's life. Currently all that's needed is a single interpolation value stored to a particle's UVW.x channel, and a gradient ramp. Done. How would that be done in some Color-operator-centric workflow? You'd have to continually send particles out to other events in order to change their color, independently wrangle interpolation values for each one...or you'd have to store a list of colors in each particle and then somehow wrangle their interpolation that way. It would be a mess. The UVW workflow is superior
The next build allows color export/import (to/from map channel 0) from PRTs. As for why XYZ renderer or plugin can't render colors from XYZ input...I think it's up to them to support Vertex Color colorization, rather than me to chase the tails of each plugin's own implementation. As for Alembic, in point cloud mode I don't export mapping values, just positions. I'd suggest a dedicated format for particles like PRT if you need the extra data.