• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Color information being changed by the sim?
#1
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)
  Reply
#2
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
  Reply
#3
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,
  Reply
#4
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
  Reply
#5
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.
  Reply
#6
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]
  Reply
#7
Changing the opacity in the tex3d has no affect on the particles in my tests, but it still wouldn't solve my problem if it did. The problem is this multiplication that is happening from the smoke transparency. Simply increasing the opacity isn't a viable solution because I need parts of the sim to be softer than others as i am also transferring density info to the particles. Anywhere that is semi transparent will have this issue. (as seen in your screenshot)

I need to get the raw color values before this opacity multiplication happens, is there any way to have the shader ignore smoke density and only use color? At first i was hoping to use an effector but i don't think it will work in this situation.

If there is no way to fix this issue then perhaps we could get this feature added in? A simple flag in the tex3d which un-multiplies the smoke color would do the trick. A new color channel display in the voxel data display which only displays the raw color values without taking any smoke opacity into account would also be really nice. Smile

Thanks.
  Reply
#8
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
  Reply
#9
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,
  Reply
#10
Hello,

Here is the installer.
http://www.afterworks.com/betafiles/FumeFX507R2020.exe

From the tex3d map, select color from the dropdown menu.
This will cause tex3d map top return the exact color that is inside the voxel grid - it's not multiplied with anything.
With min. threshold option you can ignore colors that are below it and in that case the area below threshold will be transparent.

Other parameters are not used.

Please let me know how this works for you.

Regards,
Kresimir Tkalcec
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)