I’m just wondering what channels, if not all of them, are able to be normalized for output and if below is the correct way to do so?
I’m trying to get more control over density/velocity/color gradients.
To be more clear:
If I wanted to normalize my density, I would inputChannel Density > Curve Operator > Output Density, and as far as I understand this would force my Density to have a value of 0 to 1, yes? In order for the highest and lowest values of my density to BE 0 and 1 however, I would need a Clamp Operator, right?
Would the workflow then be InputChannel Density > Curve Operator > Clamp > Output Density?
If so, can this also be applied to InputChannels like Velocity, Mapping Channels (with gradient ramps), Emission channels, etc?
Normalization is obviously the scaling of a value into the 0.0 to 1.0 range. I am not sure why you want to do that. Is this for CustomData Render Elements output?
That’s one place where it makes some sense.
You can scale down the Density using the global Density controls in the renderer, but Density is not expected to be in the 0.0 to 1.0 range since it represents the density contribution of the particle to the unit volume it lives in. This allows a volumetric renderer like Krakatoa to accumulate the density values and affect light and the final rendering correctly.
There is absolutely no reason to limit the density influence of a particle over its volume. For example, if you have 1 million particles with Density of 1.0 within a cubic foot of space and you reduce their count to 100,000, you can simply increase the Density value of each particle to 10.0 and if you look from far enough or rendering in Voxel mode, the resulting image will be fairly close to the 1MP one, since the total density will still be a million for the same volume.
Can you explain why you would like to normalize the Density?
Normally (pun intended), value normalization is performed by dividing the value by the Max. value, but this requires the knowledge of what the Max. value is. This is easy with Age and LifeSpan since LifeSpan is technically the Max. Value of the Age. But with Velocity, you have to somehow measure the fastest velocity to be able to normalize by it. You can just enter a value and test empirically, or use the Particle Data Viewer or the latest Debugger to see the actual Max. values. Then the correct procedure would be InputChannel > Divide (<Max.Value) > Clamp > Output. The Clamp is optional and will remove any residual values outside the 0.0 to 1.0 range if your Max. value was selected too low. Don’t see a reason to use a Curve, although it will work since it gives you a custom Min. and Max. value range to remap to 0.0 to 1.0. But I never use Curve for normalization. Probably a matter of personal preference…
You can do the same with Vectors by dividing them by the Max. Magnitude.
It was more of just a speculation of how to do something in my attempts to understand the workings of Krakatoa/Pflow a bit better, to be honest . I think I should have used Velocity as my example instead of density and it would have made more sense.
My reasoning behind the question was that I’ve been applying Color Gradient Ramps to PRT sequences, and even with KCM Global Overrides, and was having a bit of trouble controlling them with the Curve, so wanted to know if there was a more finite way to give me a value of 0 (low end gradient) and 1 (high end gradient).
I think by default it gives you these values and I’m just crazy… I’m probably just doing something wrong.
Dividing by the (expected) Max. Value is what I do in those cases.
If you have time, be sure to register for the Webinars tomorrow or on Wednesday, I will be covering some of the practical Magma stuff there! thinkboxsoftware.com/news/20 … -show.html
If you cannot, there will be videos posted later this week.
. I think I should have used Velocity as my example instead of density and it would have made more sense.