Tweet
Hey all - we are building out our USD pipeline and have been running into file sizes that 4x larger than rendering in OBJ/ROP (Was 80MB a frame now ballooning to ~400MB). Same exact AOV's just using Render Vars in Solaris instead of the traditional AOV's in the V-Ray ROP. We are using standard Back to Beauty passes with all regular utility passes (UV, normal, world, depth, etc). Has anyone else noticed this / have a potential fix? I noticed all of the render vars in the vraystandardrendervars node are set to Color4f but changing that didn't seem to make a difference. Zip1 compression are being used for both. Thanks!
-
-
V-Ray is not writing any files, files are written by Houdini Solaris itself.
Afair, there were some improvements in 20.5 regarding channel compression, which Houdini version are you using?
-
We are using 20.5 but tested in both 20 and 20.5. Are you seeing identical file sizes between a render with the same AOV’s in Solaris and OBJ?Comment
-
> Are you seeing identical file sizes between a render with the same AOV’s in Solaris and OBJ?
As I already wrote - V-Ray is not writing any files for Solaris. Solaris/Hydra is writing files by itself.
As for OBJ (I guess you mean non-Solaris V-Ray ROP, right?) - in this case V-Ray itself is writing the files.
If there is a different compression used then not sure how files could be indentical.Comment
-
We have hade the same problem, but changing color4f to color4h did the trick for us. When we do this the exr's are saved as 16 bit.Richard Blank
www.haymakerfx.comComment
-
You're a lifesaver Richard thanks for responding.
bdancer - my recommendation would be updating the AOV's that are traditionally half precision (everything except crypto, depth etc) in the V-Ray Standard AOV's node or including it in the documentation so users know why their file sizes are ballooning when dropping this node.Comment
-
> my recommendation would be updating the AOV's that are traditionally half precision
Sure, that's doable.Comment
Comment