Color study and request for color operator
Hi I made some tests about color in tyFlow.

You can find the File attached to this thread.

The base is a box with a solid type gradient ramp of 2 colors. I created 2 very simple particle systems. One tyFlow and one pFlow. Both grab mapping and colors from the boxes correctly and in geometry display mode both deliver almost the same results, as it shoud be.

But pFlow provides a color channel to the partilces itself while tyFlow doesn't seem to do that.

Krakatoa Test:
pFlow: I recorded the pFlow with Krakatoa and the Krakatoa PRT Loader reads back the particles with the right colors.

tyFlow: I exported the tyFlow with tyFlows export operator as PRT sequence. The Krakatoa PRT Loader is not able to read back any color. Also a color attribute or channel is not available in the PRT export options of tyFlow.

Alembic Test with VRayProxy in Point Mode and VRayPointParticleMaterial:
pFlow: I exported the pFlow via 3dsmax native alembic exporter and loaded it with a VRayProxy, set render mode to point and applied a VRayPointParticleMaterial
with "use particle color" turned on. But no color values could be read back. Maybe thats a problem of the 3dsmax alembic exporter which doesn't export color values for particles.
Even VRayParticleTex couldn't read any color value from that alembic cache.

tyFlow: I exported the tyFlow with tyFlows export operator as alembic point cloud and loaded it with VRayProxy, set render mode to point and applied a VRayPointParticleMaterial with "use particle color" turned on. But no color values could be read back. Maybe tyFlow doesn't export particle colors.
Even VRayParticleTex couldn't read any color value from that alembic cache.

Phoenix FD Particle Shader (PHX Foam) Test:
I feed both systems, the pFlow and the tyFlow as evaluating systems and even as PRT caches to Phoenix FD Particle Shaders in point mode with "color map" turned on. I created a PhoenixFDParticleTexture for each system and cache object to feed the color map slots of the particle shaders.
From none of the sources I coud pick a working color channel in the PhoenixFDParticleTexture. So there was no way to get particle colors working when rendering with PHX Foam Particle Shader.

In conclusion:
What I request is a color operator for tyFlow, which stores color values per particle in a color channel and that it's possible to export those color values per paticle via the allready supported export formats (*.tyCache, *.PRT, *.abc, etc.).
This color channel should be readable for the most render interfaces (VRay, Krakatoa, Alembic), cache readers and particle processing systems (Krakatoa, PHX, VRayProxies). F.e. in phoenix the color channel is named "RGB" i think and in alembic and krakatoa just "color".
Furthermore it would be great if some color related attributes like density (sometimes called "alpha" or "opacity") and emission (or called "self illumination" or "self illumination color") could be stored in their specific channels too.

Solution idea: Color operator (with multiple functions)
What works very nice in tyFlow is to transport mapped colors from objects to particles shapes. In the color operator I imagine, there should be some option like "get particles shape average color". So the partilces should become a color value which is very close to the visulal apperance of their geometry shapes.
Further it should be possioble to activate extra channels for "emission" and "density" with the option to transfer or set colors or values for these channels.
Some other color sources like a simple color picker should be available in the color operator too. Or read colors from textures in many known ways. There are a lot of possibilies.
Additionally a gradient like system would be nice where you can pick two or more colors and apply some time based transitions between them (I know this is actually possible with a gradient ramp texture - shown in your example scenes ... but in my opinion this method is accually very non intuitve, too complicated and not very comfortable).

Much text but I hope I could give you some inspiration Big Grin.

Thanks in advance!

.zip (Size: 2.11 MB / Downloads: 19)
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 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 Smile

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.
(04-21-2020, 10:34 PM)tyFlow Wrote: It's quite straightforward once you understand that colors can be stored as UVWs.

I understand. But how to do that?

For example here in that screenshot attached:
How to store the red, blue and green colors, displayed on the particles in the viewport, as point3 color values to map channel 0?

Well that's a little different. In that case you'd want to sample the actual texmap and apply the resulting color value to the Vertex Color (mapping) channel if your choice. So there's a conversion necessary, but lucky for you that functionality is already in the Vertex Color operator in the next build, going out in a couple hours.
Thanks man! You're genius.
Hi, just wanted to ask again ... would it be such a huge effort to implement the color export for alembic too? I would really appreciate it. Not that I need it urgently but then you get some features to run like VRayPointParticleMaterial (See: Quote from help: "use particle color – When enabled, the material will attempt to take the color from the native particle color channel in the Alembic file, if such a channel is present." ) and VRayParticleTex ( Quote from help: "When used as a map in a material assigned to VRayProxy when alembic particles are present in the specified mesh file it returns the color from the .color channel of the particles." ).

I just thought cause you implemented this special vray interface for tyFlow since the beginnig, the support for VRay would be a concern for you.

For the PhoenixFDParticleTex ( I requsted the support for color reading from PRT in their forums and they put It on their list (

Im really interested in a good interoperability for the FX tools in 3dsmax. For me its really annoying that the actual wide range of incompatibiltys are blocking workflows.
Yea, I can look into that.

Just for your interest:

I made a quick test with the new color options and detected an issue with VRay. But Im not shure If its a VRay problem or a tyFlow problem. So I first posted it to chaos groups forums here:
Okay its a bug with VRayPointParticleMtl, they allready got it on their list. So it seems tyFlow's alembic point cloud color implementation is stable and works as intended!

Forum Jump: