Thanks for quick reply. No, you are talking about volume color ramp, where color is mapped from density or velocity or different data gathered from vdb at render-time. I can do that of course with Volume ramp and I use it frequently.
What I am talking about is to read vdb RGB channel which is baked into vdb during simulation (Phoenix FD or FumeFX). If you emit smoke from, say, plane with checker texture, you will see that smoke contains this initial colors from texture and these colors are advected, mixing later.
https://www.youtube.com/watch?v=bclZXkbWcYAhttps://www.youtube.com/watch?v=5Ea_AL8khEIThis is important for realism where various parts of exploding building can differ in emited smoke color. For example, Phoenix FD can write such channels into volume grid: Velocity, Smoke, Temperature, RGB, Speed and so on.
Of course it is not up to octane to advect and simulate the flow of color, but this RGB information is stored inside vdb, waiting there, so I believe octane volume object could access it the same way it accessed density, smoke or emission data from vdb. I believe that if you already made a great coding job with octane volume accessing Velocity, Smoke and Emission information, then accessing one more channel (RGB) is almost the same code. It does even need to touch material editor, since octane doesnt have to worry about any color coordinates - it's all already inscribed in vdb file. It's just to get the RGB data displayed on volume (as, say, emission already is).
If this is done, then Volume Rendering in Octane is concluded and perfect, nothing more remains to add. I love octane for 3dsmax.
best,
nl