Hello,
the Krakatoa SR Build form Mar. 22, 2012 is able to create multi channel EXRs. How can I do this?
I tried to add the depth channel to my render_output.exr file (containing the rgba information):
ri.Display( "render_output.exr", "file", "rgba" )
ri.Display( "+render_output.exr", "file", "z" )
But inside the created EXR file the rgba channel is missing there is only a depth channel.
By the way, the depht channel data written to my EXRs looks broken. I expect to get camera distance values (e.g. value 100 if the particle is 100cm in front of my camera). My background pixel got a value of inf (that’s correct), but all pixel filled with particles got a value of -inf. Only at the edge between background and my particle volume object I got correct depth values.
To create a multi-channel exr, you need to specity all the channels as the thrid parameter. For example, to do an R,G,B,alpha,Z channels image, you would use this line:
ri.Display( "render_output.exr", "file", "rgba,z" )
I just tested the “Z” values on a scene using the latest build, and it works correctly on my setup. If the above does not fix the problem of the bad (-inf) Z values, can you send me a copy of your .py scene file and particle files? I could try to debug it further for you.
AH! I found a bug using the scene you provided. I’ll attempt to track it down. Thanks for pointing out the problem.
I found and fixed the problem with the Z-depth passes. Attached here is an updated KrakatoaSR.pyd (Windows). The fix will be included in the next full release.
KrakatoaSR-20120410.zip (3.32 MB)
The depth pass is fine now, thanks for the update!
Hi Conrad, I’m trying to export a velocity pass but it’s not working. Am I doing something wrong? In my .py files I have this line:
ri.Display("/tmp/outputimage.130.exr", "file", "rgba,z,Velocity")
…when I view the image in Nuke I see rgba channels and a depth channel, but nothing for velocity. I’m rendering with these settings:
ri.Option("render", "MotionBlurParticleSegments", 16)
ri.Option("render", "MotionBlurJitterParticles", 1)
I do see motion blur in the rendered image.
Thanks!
David
Whoa, that is a bug. Thank you for reporting it, and I will fix it! However, I would like your feedback on how to handle multi-channel EXRs before I proceed.
First question:
Krakatoa SR has six element types. Here is what I had in mind for EXR channel names, and data sizes. Should I change anything?:
-
“rbga” element: 16 bit floats.
[list][*]“R”: red
- “G”: green
- “B”: blue
- “A”: alpha
[/:m]
[]“occluded” element: 16 bit floats. Occluded layer currently does not work if image contains “rgba”. Occluded layer are particles behind occlusions.
- “occluded.R”: occluded red
- “occluded.G”: occluded green
- “occluded.B”: occluded blue
- “occluded.A”: occluded alpha
[/:m]
[]“N” element: 16 bit floats. NOTE: normal layer currently is named “N.000.x”, “N.001.y”, “N.002.z” and is 32 bit. I plan to change it.
- “normal.X”: normal x
- “normal.Y”: normal y
- “normal.Z”: normal z
[/:m]
[]“Velocity” element: 16 bit floats. Should I use “V.000.x”, “V.001.y”, “V.002.z” or something instead? Currently this DOES NOT WORK, and that’s the bug you found.
- “velocity.X”: velocity x
- “velocity.Y”: velocity y
- “velocity.Z”: velocity z
[/:m]
[]“z” element: Single 32 bit float.
- “Z”: z depth
[/*:m][/list:u]
Second question:
No special treatment is being done for EXR files that contain only velocity data (just using velocity as an example here). This means the EXR will have channels named “velocity.X”, “velocity.Y”, “velocity.Z”. It will not use channels named “R”,“G”,“B” for the velocity data. Also, the EXR will not contain an “A” alpha channel. Is this acceptable?
Third question:
Currently, when an EXR contains only occluded data, the EXR channels will be named “R”,“G”,“B”,“A”, instead of the usual “occluded.R”,“occluded.G”,“occluded.B”,“occluded.A”. Is this special case acceptable?
I thank you for your feedback in advance.
The bug is fixed! Get the latest build with the fix here: http://forums.thinkboxsoftware.com/viewforum.php?f=116
I have implemented all the channel naming like above. If you would like anything changed, please let me know.
Conrad, let me think on this one and I’ll get back to you.
Regarding your question for the naming of the channels, I think it’s reasonable constructed. Everything is fine in Nuke, but I think some other programms (e.g. imf_disp) will have slight problems because they can only show R G B an not X Y Z. If you view the normal pass in imf_disp, only the Y channel is displayed. Perhaps it’s more compatible to use RGB.
By the way, is it possible to generate a point world pass?
I discussed it with Bobo, and we came up with a solution for the programs that can only display RGBA channels.
By default, it will work as above, but the user can turn on a flag that only writes to RGBA channels. This would mean you’d have to have separate images for Color and Velocity, etc. However, it would be compatible with all viewing and compositing applications. I haven’t yet implemented this idea, but it’s on the list.
For your question: Point world pass. Are you referring to writing out all the particles as a PRT file in world-space? If so, you can do that with this call:
ri.Display( “+output_particles.prt”, “file”, “points”, “LightParticles”, True )
UPDATE: Bobo informs me that I don’t know what I’m talking about when you refer to “point world pass”. I’ve been told that it’s exactly like the “Z depth” pass, but instead it would use particle position. This could be achieved. It would have to use the nearest particle to the camera for each pixel (exactly like we use for the z pass). Currently it’s not implemented.