I’m back on my krakatoa project and i’m facing a blocking problem.
I’m working on a particle system with unusual density fluctuations. Unlike in film production visual effects where density fluctuations are usually kept low (because of collision and bouncing) i have to render particle systems that come from scientific simulations on the birth of our universe. In the Universe, there are places of very low densities (void) and places of very high densities (superclusters of galaxies) due to graviational pulling that mass particules in random spots. Thus, my PRT files have places of very high density (saturated white on renders) and places of very low density (1000+ less, so black on renders). Classical Scientific visualization softwares (which i try to turn krakatoa in, though i know it’s not made for but could attract some new customers i’m convinced ) have a very common feature which is “Logarithmic scale” that allow to visualize very low and very high densities on a same scale / single render. An Intensity of 10 turns in a value of 1, 100 in a value of 2, 1000 in a value of 3 and so on, so you can visualize a large gap in densities, smoothing the whole scale. Bobo told me the next release of Krakatoa will include a Magmaflow Log operator, which i could try to apply on the Density channel of my particles, but i need to produce renders right now. As i’m not a visual effect experts, there could be a solution in Krakatoa, but also at another step of my workflow, in max or After effects, that’s why i try my luck. My workflow is as follows :
source scientific custom file > custom maxscript > PRT file > Krakatoa additive render > EXR output > After Effect.
While waiting for the Log node in MagmaFlow, I looked in Eyeon Fusion 5 and saw a CineonLog operator which can be used to convert linear color space into logarithmic and the other way round. This is because the Kodak Cineon format is encoded in logarithmic scale to allow for high dynamic ranges, so this kind of conversion is quite common in post.
Since Krakatoa saves EXRs as floating point numbers, you can let it write the linear color/density results to OpenEXR first, then pass the images through your compositing package and convert from linear to log space. At least I assume that would work.
I don’t have AE here to look for the respective function, but I would be surprised if there wasn’t one…
Those two methods are not the same though… Setting the particle density output to log(density input) is not the same as setting the render density output to log(density input) because the render will show the accumulation in a linear fashion, and we have no control over how Krakatoa accumulates samples. The ideal situation would be to accumulate the density to the render in a log fashion, no?
Or am I being an idiot? I need a second cup of coffee, so maybe I’m off here.
EDIT: I mean to say, do you want log(xy) or log(x+y)? Meh, coffee not working…
It seems to work great with Additive rendering though. Since he is producing galaxies and star fields, that might be good enough for now.
(I just added the Log and Ln nodes to the UI, Darcy will implement the nodes later today).
The way Krakatoa is made, there really isn’t any way to change the compositing mode as there was in 1.0 (though that was limited to 2 options). Is that just something that’s hardcoded and optimized in the compiler to the point where the user would never be able to access it? Would there be a horrific penalty if that was opened to the user? To be honest, there aren’t THAT many ideas I can think of where I’d want to change it, but just wondering.
Additive and volumetric, right? Weren’t they the two options, or were there more? The compositing is (from the user’s point of view, at least) Add vs Over, right?
As to what I would want it to do, Maximum would be my first idea. Another idea would be to use the color from the maximum alpha sample.
Some effects, like a depth weighting, could be handled by a KCM that just compared position to the camera. But something like Maximum or “Color from Maximum Alpha” would have to be done from the actual rendering.
Most of the other ideas would be pretty involved, like Importance Based Rendering or Opacity Peeling, which would require something like a KCM-type interface to control the actual rendering.
I see. I currently cheat those by doing a couple things. Additive mode is achieved by turning off lights, setting Color and Absorption to 0 and Emission to non-zero. I do data passes like z-depth or normals by turning off lights, setting the data to the Emission channel, Absorption to full white and density REALLY high. But I see your point, this could be easier and it certainly doesn’t allow crazy custom stuff.
Tahnks for the replies ! I’ve asked for a fusion evaluation license to try it but the software is quite expensive. We’ll probably won’t have the budget to purchase it for a single function but i can always try it in the meanwhile.
Chad’s comment is wise, there is a difference between log accumulation and log of the linear accumlation. The second option is ok though for what we have to do : most science codes are using linear physics then density maps are created using a log scale for visualization. So the Magmaflow log operator will do that : log of the total accumulated density ? That would be perfect.
I’ve asked in the meanwhile on CGtalk if someone heard of a log scale effect/plug-in for After Effects. Let’s see !
It’s a plugin for PFlow, lets you do custom particle logic inside of an operator. It’s a bit like how a KCM works, but it operates on particles, not points.
And unlike KCM’s, it can sample other particles, so you could sample density in a neighborhood, not just the individual point density. You can even sample the density in a ray to the camera or light, or in a cone to the camera or light. A long time ago, I did some tests with soft shadowing and specular highlights and custom diffuse functions that were “rendered” in Box#3, and rasterized in Krakatoa.
It’s slower, sure, but gives MUCH power. It’s faster than using particle scripting at least.