Why Does Houdini Freeze..

[Jason]

Why does Houdini freeze when generating interactively rendering a frame with shadowmaps and only return control once the primary image is being generated, and NOT if you output an IFD and render it from the commandline?

This is all with the "Render In Background" turned on. Is it because it can't complete the feeding the IFD into mantra until ray_quit is called? There must a way around this, no?

Sometimes the shadowmap render a large portion of the render and so you're not really doing much "background" rendering at all. I suppose it's possible to replace the mantra command with a wrapper that'll allow control to be returned to Houdini earlier, but perhaps there is way SESI can do this?

[Mario Marengo]

Good question!

I'm just now coincidentally doing a job that uses shadow maps that take quite a while to generate, and waiting around to regain control gets pretty annoying. I have no idea why it does it though... if you dump the stream and compare it to a generated script (which returns control immediately when fed to mantra at the command line) they are identical.... so... dunno

A good RFE I think.

Cheers!

[crunch]

You might try the following wrapper script

#!/bin/csh -f

set rcode = 1

onintr cleanup
# Save the ifd in a temp location
cat > /tmp/$$.ifd

# Now run mantra on the ifd
mantra $* < /tmp/$$.ifd
set rcode = $status

cleanup:
# Remove the tmp IFD
rm -f /tmp/$$.ifd

exit $rcode

However, you'll find that the suspend feature in the output driver dialog doesn't work. I think that Houdini is suspending the shell script (which doesn't suspend the actual render). I'm also not sure what would happen if /tmp got filled up while you were running the wrapper.

[Jason]

Ah, thanks for the script, crunch - I'll try it out and Windows-ify it for our more masochistic people.

[edward]

That script should work on Windows with cygwin (as described on the wiki) as long as you have a /tmp directory on the drive that you're running it from.