We’re getting bad frames when rendering vrscene to vray standalone out of Houdini. Specific frames always produce the wrong result even when exported and rendered by different nodes on the farm.
See example_bad_frames/*.exr.
Frame 1001 is missing the flame glowing part, 1002 is blown out and 1003 is completely missing the volume.
The same scene renders fine locally when rendering to the VFB.
Houdini 17.5.425
Vray: vray_adv_43000_houdini17.5.293_a9792ff_5819
Hey, Grant,
managed to reproduce the problem here, and it’s something we’re already working to resolve. I’ll tag the thread with the ticket number.
A simple solution would be to re-save the bgeo files to VDB - resolves the problem on my end. Please use VDBs in general - the native volumes support is nice to have for lookdev but we always bake those to the VRScene. We’ll update the docs.
Hope that helps!
Awesome, thanks for the info and workaround Gosho.
Morning Gosho,
Even w/ VDBs we’re still getting a ton of load errors. One job took 16 tries to correctly load the VDB and render it. The VDB and resulting render are ultimately correct once VRay finally decides to load it.
This is the error we’re getting:
Error
=======================================================
OpenVDB IO Internal: fatal error loading from stream, message ‘RuntimeError: Expected to decompress 200 bytes, got -1 bytes’
at Deadline.Plugins.PluginWrapper.RenderTasks(String taskId, Int32 startFrame, Int32 endFrame, String& outMessage, AbortLevel& abortLevel)
When it doesn’t load it just renders black.
Hey, Grant,
first off, sorry for the delayed response - we had an all company event going on.
Juging by the error message, I can only assume you’re hitting a problem currently being resolved by one of our developers. Simply put, high resolution volumes cause issues when baked to the VRScene.
Regardless, ideally we should not bake them and we’re on this, too. You’re probably hitting a case we’re not handling (since you said you’re loading vdbs from disk) - if that would be easier for you, please send me a hip file with your setup and I’ll look for a workaround to skip baking. Alternatively, you can check the vrscene in a text editor - the PhxShaderSim plugins should be pointing to disk. If there is a raw_vdb_stream parameter there, it means the volume is being baked.
If it’s not terribly urgent for you guys, please give us some time to handle this.
Cheers!
We’re just rendering w/ hython straight in Houdini as opposed to exporting .vrscenes for now, that seems like it gets around the issue in the short term.
Anxious for a more permanent fix tho as that’s burning up a lot of hbatch licenses.
Thanks Gosho
Evening Gosho, any update on this? It seems the VDBs are not file-referenced in the .vrscene even if a switch node is placed below them, it has to be a file cache w/ the raw VDB path (no expressions in the name) or it gets inlined in the .vrscene.
Same workaround, rendering native Houdini, seems to be the only fix for now.
Hey, Grant,
just talked to the dev about this today - hopefully in a few days we’ll have a solution for you.
Cheers!
Hello,
we have a fix for the export.
The setup from your original post also seems to work for me now (after re-exporting to VDB instead of native volumes) both locally and with Deadline. I’m attaching my scene here: https://drive.google.com/file/d/1Wyn…ew?usp=sharing
Can you please check with the nightly builds from Jan 14th ?
// a few notes - merging multiple packed volumes in a single Geometry node will force a bake - we have to handle this soon. A single VDB being packed and instanced to points should work as expected though - the vdb file should be referenced from disk. Another example here: https://drive.google.com/file/d/1T-d…ew?usp=sharing
Cheers!