We are running houdini Houdini 9.0.782 on linux.

When we run a command from a shell like:

hrender -f 1 1 -i 1 -d mantra1 h9tester.hip

we get:

Unknown command: ndif

This worked OK with version 8. We've tried multiple linux distros and multiple houdini 9 projects.

If we run: grep ndif `which hrender`

We get:
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif
endif

So I don't know where this error is coming from. Any help would be appreciated since our farm can no longer render houdini projects with this method.

Thanks

Try doing a diff with the older version of hrender that worked for you.

Hrender is a simple shell script. I'd start by using the same command line but substitute the full path to the hrender H8 version that worked, (I don't think it's changed). If it still doesn't work, it probably isn't the hrender script.

Also, with a local copy of hrender, just start removing lines of code that end in “endif” until it fails somewhere else… you should be able to track it down pretty quickly.

Sean

The diff is messy since the file was change around a bit. However the hrender shell script from houdini 8 gives the exact same error message when run with the houdini 9 binaries. So the error must be getting returned from the hbatch or mantra binaries.

I've submitted this as bug 29151.

This is Dave, from the systems office at Montgomery Hall. I'm just assuming this is the problem report for the issue that we are having.

I edited the hrender script to show me exactly what was going on, and where the problem was originating from. It's definitely not anything with the hrender script itself, the error is actually being returned from hbatch-bin. Which makes it rather impossible to troubleshoot.

However, I was able to get it to render from the command line without specifying any of the frame information “hrender -d mantra1 h9tester.hip”. For whatever reason, as soon as the flags for the frame ranges are specified, it gives the “ndif” error from hbatch-bin.

Not sure if this is any new information or if it's of any help, just trying to assist in specifying the problem.

tbird469
We are running houdini Houdini 9.0.782 on linux.

When we run a command from a shell like:

hrender -f 1 1 -i 1 -d mantra1 h9tester.hip

we get:

Unknown command: ndif

This should be fixed for tomorrow's build.

If you want to patch around this, you can easily work around it by
adding a “-i” option before the “-q” option on the hbatch command in
the script.


hbatch $renderonly -i -q $myverbose “$hip” < \
$myscript |& tee $myoutput | \
grep -v -e ‘Warning’ -e ‘Data may’

Well, we've been trying for a while to get that to work properly. It does in fact get rid of our error and allow us to render finally. However, it's still not usable on our render farm because the “-o” flag is unresponsive to our paths, or any path, for whatever reason.

The following command, should render to /tmp/test/ouput.0010.tga, instead however it's outputting to whatever is specified in the .hip file (in this case it's the same directory the hip file is in). So it's outputting to /home/admin/wherever/0010.tif

hrender -e -v -R -f 10 10 -o /tmp/test/output.\$F4.tga -d mantra1 h9tester.hip

Just to double check, I checked the latest daily builds hrender script and while the verbosity is prettier, it does exactly the same thing. We're still running 9.0.782, and I checked 9.1.123 for changes.

Here is my full input/output:

hrender -e -v -R -f 10 10 -o /home/dahale20/SFDM-HOME/test/output.\$F4.tga -d mantra1 dahale20/test9.hip

Skipping unrecognized parameter “picture”
dahale20/test9.hip (/out/mantra1)…
Rendering
mantra1 frame 10
mantra Version 9.1.123 (Compiled on 01/15/08)
Generating Image: /home/dahale20/SFDM-HOME/dahale20/0010.tif (640x480)
Plane: Cf+Af (16-bit float)
Render Time: 0.65u 0.08s 0.64r
Memory: 5.49 MB of 6.40 MB arena size. VM Size: 9.50 MB

I also checked on the unrecognized parameter “picture” (which we've been getting from day one), and that's being generated from one of the if-statements that has to do with the “-o” flag. I have a pretty strong feeling that has to do with why it's not accepting our paths.

phuziun
Well, we've been trying for a while to get that to work properly. It does in fact get rid of our error and allow us to render finally. However, it's still not usable on our render farm because the “-o” flag is unresponsive to our paths, or any path, for whatever reason.

I also checked on the unrecognized parameter “picture” (which we've been getting from day one), and that's being generated from one of the if-statements that has to do with the “-o” flag. I have a pretty strong feeling that has to do with why it's not accepting our paths.

Looking at the script, it appears the -o option is trying to set the
“picture” parameter on the output driver. However, in H9, the
parameters specifying output are different. I'll try to work on a
solution.

I've submitted bug 29382 for this issue.

Guess I posted too early!

Haha, hopefully this is it. I've gotten it to render with the renderfarm commands, and I finally got it to output to whatever is defined with the “-o” flag. Here's my command (same as your's):

hrender -e -v -R -f 10 10 -o /tmp/hrender_tests/output.\$F4.tga -d mantra1 h9tester.hip

And it renders /tmp/hrender_tests/output.0010.tga perfectly.

The problem was when the opparm was trying to assign the variable to the mantra1 rop. It was trying to assign it to the “picture” parameter, which doesn't exist, and is why we've been getting the Skipping unrecognized parameter “picture” error. The parameter it should be assigning it to is vm_picture.

So here's the fix:

We still need the “-i” before the “-q” obviously, and in hrender on line 276:

opparm $rop picture ( $o_option )

should be:

opparm $rop vm_picture ( $o_option )

phuziun
Guess I posted too early!

opparm $rop picture ( $o_option )

should be:

opparm $rop vm_picture ( $o_option )

Which doesn't work for RIB or mentalray renders :-( I'll try to have a general fix in place for 9.1.

Thanks,