How can I bake normals to a PRT sequence so I can use it for environment reflections?
I have an object that is slowly being distorted by a noise modifier. So, I tried saving out particles from PFlow using the Krakatoa Geom Lookup set to export normals (using the TM option). But I must be missing something, the render shows that something is wrong with the mapping… And when I add a Krakatoa Update I can see only position,ID,velocity and color.
Sounds like you are trying to get Normals round-trip from PFlow through PRT back to PFlow.
PFlow does not have a Normals channel per se. We assume the X axis of the Transformation Matrix as the Normal. Thus, if you don’t intend to render the PRT sequence directly in Krakatoa but for some reason have to read it back into PFlow, you should save the Orientation channel to PRT (it is a float16[4] value containing a Quaternion value), and then load the Orientation back into PFlow via the Krakatoa Update operator. If you render the resulting PFlow in Krakatoa, the Orientation channel will set the rotation part of the ParticleTM and Krakatoa will grab the X axis of it as the Normal automatically.
In the future, we might let Krakatoa use the Orientation channel instead of the Normals channel to calculate Environment reflections and specular highlights, for now the Normals channel will be needed to render a PRT in a PRT Loader, and the Orientation to bring back and render the PRT in PFlow.
Yes, I did save the normals - but have realized that it is probably the distortion of the particles that are causing the messed up reflections…
I can imagine that it might give a better result if I choose the camera mapping path, to “bake” the hdr reflections into the particles - and then deform them after that…
Reflections are view-dependent and cannot be “baked” into a PRT sequence. They are applied as additional camera space pass in the rendering process.
Deforming PRTs will deform the normals too, so the reflections would be deformed, too.
But the Orientation channel would not be deformed (as far as I know), so using the Oriantation to pass the normals around would be a good workaround.
In the next update of Krakatoa, you will also have Quaternion operators in MagmaFlow so you could extract the X axis of the TM defined by the Orientation channel on top of the deformation modifier and render directly the PRT Loader with undeformed normals. If you are loading the deformed particles back into PFlow before rendering, the Orientation channel will also provide undeformed normals to the renderer…
Another alternative right now if you want to render the PRT Loader itself with deformation but undeformed normals would be to put a KCM at the bottom of the stack that copies the Normals to some Mapping channel, then add the deformation modifier (as long as it is not a World Space or Space Warp one since we don’t have a World Space KCM yet) and then in another KCM on top of the deformation copy back the normals from the Mapping channel to the Normals channel.
Yes, this is of course what I meant by baking… So, I plan to render out an image sequence first, and then map that sequence onto the particles using the method decribed in the camera mapping tutorial.
I look forward to trying out the options in the next update - sounds great!
I would not do the camera projection for env. reflections (unless I really had to).
As I explained already, you can easily use the existing saved normals by caching them into an intermediate channel before deformations and then putting them back into the Normals channel post-deformations. Is there a reason this wouldn’t work with your current setup?