Hello,
I am making an underwater ink scene where i have 2 smoke plumes colliding, one red and the other blue. I am trying to transfer colors from my simulation to particles that are following the smoke, the problem is it appears like the smoke color is being multiplied by the transparency or some other type of data. If you enable the voxel data display in the view port (2d slice) you can see there are a lot of very dark/black voxels around the colored voxels and the particles are inheriting this instead of the raw color. If i manually assign a color via an effector i dont get this issue, however i dont know if an effector would be able to help in this situation.
Is there some way to have fume output only the raw colors of the voxel? I have tried transfering the colors to the particles via vertex colors, i have also tried using the fumefx tex3d, but both of these methods also have this issue. Perhaps there is a way to use maxscript? (although im clueless with max script)
Hello,
You could transfer the color only on voxels where there is smoke maybe ?
When there is no smoke, the color does not exist (black).
Best,
Kresimir Tkalcec
The black areas you see in the picture on the voxel display are smoke voxels, but the color information in the voxels around the borders are still being affected by this darkening. This darkening is not visible with a gpu preview or in any renders, only in voxel view in the viewport. (where the data is sampled from). I need it so its more like a straight diffuse instead of having the color info being multiplied by the transparency. (or whatever it is affecting it, possibly velocity magnitude?) In this picture, i have manually replaced all the smoke color to red with an effector. You can see there are no dark voxels around the border, each voxel is 255,0,0 rgb. The particles inherit this color info like i expect and there is no darkening around the edges. It is also a solid color when i use the smoke gradient or a manually assigned color as the source in the smoke rendering settings. As soon as i set the color source to grid this problem appears.
Thanks,
Hello,
What is the method you use to access the color from the FumeFX grid and I'll be able to tell you how it's computed?
Kresimir Tkalcec
I have tried 2 methods, the first method was to use the fume tex3d material to color the particles using a world space mapping. The second method is to use an operator in the particles (im using tyflow) to save the various channels (smoke, color/uvw, velocity etc) as vectors which can be sampled by the particles. (used in the images above)
Both of these methods have this same issue. I suspect the particle operator is just sampling the same tex3d data as the first method so the results for both are exactly the same.
Did some quick test and it seems okay here.
Yes, colors are retrieved here from the shader, so they use smoke opacity, but if you bump smoke opacity to high value, it shouldn't affect it much.
[ATTACHMENT NOT FOUND]
Hello,
Thanks for the explanation - sure, this can be done for FFX Tex3D.
We will add "Color" option and it'll just return the pure grid color.
Please let me know what is your preferred 3ds max version so we can build a version for you to see if this works.
Regards,
Kresimir Tkalcec
A build for 3ds max 2020 would be perfect!
I just thought of a potential issue however. The way i'm sampling the colors is with tyflow, which has a node that saves the color channel as vectors. I believe it is sampling the tex3d shader from the grid I have assigned and gets its data from there. The data is then used to drive a krakatoa magma flow shader that replaces the UVW with specific colors.
My concern is that if this fix is a flag that needs to be manually enabled in a tex3d that the particles wouldn't inherit this since it is just inheriting the default output from the shader, which has the multiplication happening by default. Would it be possible to make the un-mulitplied version the default output to the shader instead of the multiplied version? Perhaps a flag inside the fumeFX UI window that will export the raw color to the shader might be better? The un-multiplied version is technically more accurate, as its displaying the actual data in the sim. The multiplied version appears to be mainly for viewport visualization purposes and is not present if i were to render the simulation as normal.
Thanks,