Hi everyone,i dont know why it doesnt work,be patient i am now krakatoa expert
Firstly,i made a simple Spherical pflow,and set the particle count to 2m particles and attached a hdri map to environment then tick the use environment reflections in krakatoa and got this image,which is fine.
But i have a realflow scene,which i used vorticity channel to render foam,in this case i have gradient map attached to prt sequence,i did the same thing and attached hdri map to environment channel and tick the use environment reflections but got this image which doesnt seem right…
The first one works most probably by accident because you are rendering along the X axis and that’s what we use as Normal vector.
Normally (pun intended) you HAVE to specify an explicit normal vector to produce correct environment reflection.
From a realflow simulation though, there is no normal channel stored in the BIN file itself and you will have to produce it yourself somehow.
How exactly is a big technical question and there is no standard solution for this in Krakatoa (yet).
For production purposes we have used a blobmesh of the particle could (obviously not using the Max BlobMesh which is very very slow) to produce a surface from which to steal the normals.
You can also do simpler things like generating normals relatively to a central point using a KCM or the PRT Loader’s normal acquisition approach.
You can watch this video to see how the KCM could be build to make a simple spherical orientation: area.autodesk.com/player/loader. … ntic01.flv
The Geometry Lookup operator we added to PFlow also lets you steal normals from arbitrary geometry.
Since you are using RealFlow, you could load the isosurface (Mesh BIN file) into Max using the RF object and try to steal its surface normals by loading the particles into PFlow and use the Geometry Lookup operator.
But this is in general relatively advanced topic and I hope you are ready for it
It may be feasible to sample a density gradient using say, Box#3 or TP. It will be slow-ish, but can be cached out, and you’re dealing with RF, so you aren’t expecting interactivity anyway.
If you have valid Normals, it should produce some visible reflections. Not sure if what you are getting is wrong or just unexpected. If the normals are even slightly random (instead of following a perfectly smooth gradient that picks the neighboring pixels of the map), the result can be very noisy and barely distinguishable as an image map. Looking at the screenshot of the normals preview, that might be the case…
Nice video of the Color By Vorticity render, good job!
Hi Bobo,thanks for quick replies…
I have valid normals,i dont know why it doesnt go right?
If you dont mind,i can upload my scene and one bin file to look at,also hdri map with it…
By the way,normals are not random,i checked the normals frame by frame and no problem with it.
By “random”, I meant that two particles close to each other do not necessarily point at ALMOST THE SAME pixels. If they are off by even half a degree, you will get VERY distant pixels because they are pointing at a virtual sphere around the scene and even the smallest difference in the direction can produce a VERY noisy result. The only case where the environment reflection looks right is when the normals are coming from a surface so that two neighboring particles have nearly the same normals.
As you can see, the blue and green are mixed in a noise pattern because the normals don’t follow a smooth curvature.
If I would steal the normals from a simple object like a Geosphere, I start seeing the checker pattern:
So in your case I suggest you also import the Mesh BIN file from RealFlow using the RealFlow objects and try to acquire the normals from the isosurface by picking that object as Culling Object in the PRT Loader, disabling the Culling, enabling the Normal Acquisition and entering a larger Culling Distance. This should give you a reflection according to the surface of the blobmesh created by RealFlow instead of whatever was saved in the BIN file.
