[Sidefx-houdini-list] non-hardened environment variables in IFDs?

Robert Kelly meshsmooth at optusnet.com.au
Thu Oct 21 15:34:53 EDT 2010


So with the thread alive again It looks like they didn't find an
answer. Has anyone done path changing with Python Filtering of IFD's


>>>>>>>>>>>>>>>>>>>>>>> Georg Duemlein

I've got a bookmark for this thread - it's coming up regularly :)

>>>>>>>>>>>>>>>>>>>>>>> Peter Bowmar

I believe the paths are expanded, however I recall some voodoo to hack
IFD files to do what you describe, maybe the Python filtering will now
work :)

>>>>>>>>>>>>>>>>>>>>>>> re stating My question
         Should one IFD be able to be rendered cross platform? windows / mac

Can i create an IFD on a windows box that will be able to render on
both windows and mac using environment variable like $JOB inside the
IFD with $JOB being set one way for windows and another for the mac
boxes then the IFD?

Or are the paths always collapsed into one path when the IFD is made
and it will only work on one platform so deal with it?

I expect Dealing with it  may be Python filtering the IFD's to replace
all "X:/Projects' with "/Volumes/Projects"..... is that the answer?


>>>>>>>>>>old thread brought back from the dead

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Email 4

On 11 July 2007 12:09, ken <ken at corefa.com> wrote:
> oh yeah, ick...forgot about all that.
>
> We use renderman here and have adopted strong usage of RiFilters to help
> parse and filter our rib files. We proposed the same thing for Mantra and
> they have done some work exposing standard python filtering for IFD in H9.
>
> Only think I could think of is to store your env vars and create a lookup
> file (mapping the expansion of the variable in an array) so you can quickly
> post process your IFDs (which is probably what you are doing already).
> I can't think of a "nice" way to do this across the board in a hip file. You
> can't clobber them all with a mapping file via "opchange" since that might
> break any cooking you have going during the generation of the IFD.
>
> -k
>
>
>
> Darran Edmundson wrote:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>email 3

>> Hi Ken,
>>
>> The issue with a pre-render script is that there's no easy way of
>> determining where environment variables are hiding.  ROPs for sure, texture
>> maps in shaders yes, but also geometry render tabs for instanced geometry.
>>  At least in the ifd everything is in one location ;-)  And the postrender
>> script can get the expanded $HIP as an argument to search on.  I don't like
>> having to do this though.  It would be really nice to have a number of
>> environment variables in the IFD ($JOB_MAPDIR, $JOB_RENDERDIR, etc.).
>>
>> Cheers,
>> Darran.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> email 2

Can you protect $VARNAME with \$VARNAME... you could make a python
script to put the backslash there on the preRenderScript field of the
ROP.

maybe?
-k

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> email 1

Is it possible for Houdini to *not* expand environment variables when
writing to IFD?

More generally, what options are there for dealing with relative paths
when moving from one's local machine over to a render node?  For a
given project, I tend to create a directory tree with one or more .hip
files in the root folder.  Resources are then referenced as
$HIP/shaders, $HIP/maps, etc.  In the ROP, I'll then prepend my output
filenames with $HIP/render/diff, $HIP/render/spec, etc.  This works
great on the local machine.  However, writing to .ifd, the $HIP (or
any other environment variable) gets expanded.  My hack is to run a
post-render script that does a search/replace of the hardened strings,
converting them back to envvars.  Of course this only works with ascii
IFD.

I'd be very interested in hearing how others deal with path issues ...

Cheers,
Darran.



More information about the Sidefx-houdini-list mailing list