To start the story, I use quick radiance image rendering to check my model, particularly I will change all glass to opaque and make sure a render from the room looking out is showing totally dark, as a way to check “water-tightness”.
The check Scene component is the perfect component for this task with one view. However, I would need to do this in multiple views, and hopefully leave it run all at once. Currently if we give multiple views to the component it will run multiple times and overwrite the results. I wish we can have the following flexibility to the component:
Being able to accept multiple views and run on the same model
Being able to assign folder and file name for each views
Also, I’m trying to create the workflow with PIT view base recipe as it seems to have all the flexibility needed. However, I found the same model will fail with PIT view base recipe with a out of memory issue.
Wonder what are the difference between the two components. My guess is PIT is trying to create hbjson files first while check scene skip this step. If that is the case, can we have a component to write hbjson file once and have the recipe to reload the file? Not sure if the reload option in recipe setting is doing this exactly.
Your instinct is correct, @Bing . If you need more than one view to be rendered, you should be using the PIT View-Based recipe instead of the “Check Scene” component.
It seems that your model is so large that it is maxing out the memory of your local machine. I recommend writing your Model to a compressed file using the HB Dump Compressed Objects component. Then, you can plug the resulting .hbpkl file into the recipe and that should help mitigate the potential of running out of memory.
Thanks Chris for pointing out the compressed object. I try this route and queenbee seems working at the beginning but very soon getting into a waiting queue as below. Any thought? Or it is still thinking?
Just following up this issue, the waiting queue seems to be normal message and just because the model is taking longer to run.
However, I got two questions and wonder @chris if you have some insights:
As I mentioned in this application I turn all surface into opaque, which will results totally black images as expected. This seems causing a failure of HB as it check if the HDR is too bright or too dark at one point. Can we overwrite this check?
I did another test with some glazing surface then the simulation can run with all the views (have all views in the initial_results folder) but it only generate one HDR images at the result folder.
You are correct that you’re just seeing the simulation log there. It comes from the luigi library that we use to execute tasks in parallel so that’s why a lot of the messages can seem generic.
Where is the failure? Is is in your recipe or postprocessing of the HDR?
If you gave your View objects the same name, then one of them can overwrite the other. So make sure that these inputs are different:
Thank you @chris for looking into this. Yes I had different name for different view so that should not be the issue.
I got the error message from output saying the job failed at MergeResults. And looking a few lines up it is showing the message below:
2021-12-06 23:14:43 INFO: raise RuntimeError(‘None zero return code: %d’ % rc)
2021-12-06 23:14:43 INFO: RuntimeError: None zero return code: 1
2021-12-06 23:14:43 INFO: pfilt: picture too dark or too bright
2021-12-06 23:14:43 INFO: Bad header!
I believe this is the reason of failure. In this case I was rendering a view from a dark room to check any light exist so the image will be dark but seems like there is a check here stopping the job.
FYI the same objs and view works fine in check scene and also the PIT workflow work as expected if the model have some windows to allow light coming in.
I had a hard time recreating the issue since it seems that even watertight models within Rhino model tolerance can get really small specs of light coming though the tolerance gaps. Still, I was able to recreate it and I implemented a fix here so that the recipe won’t fail when you have a completely dark scene.
You should be able to get the fix on your end with the LB Versioner in a hour or so.
