[Sidefx-houdini-list] Multiple VRAYprocedural-files

Van Aarde nanocell at gmail.com
Sat Jan 21 20:10:31 EST 2012


@ Sebastian: You are definitely not the first who have encountered the
single VRAY procedural file being an ... inconvenience. I'm sure I
submitted an RFE a few years back to get procedurals loaded via a set of
path specified in an environment variable, n a similar fashion to DSOs.
Although, I may be imagining things :)

@Mark: With regards to dealing with different plugin versions - I'll share
my experiences, in broad strokes. I'm sure many studios manage their
software in a similar fashion.

As Sebastian has shown, the software is typically installed into different
directories, according along with the version numbers, .e.g:

/software/houdini/10.0.734/
/software/houdini/11.0.834/
/software/houdini/11.1.118/
/software/geo_procedural/0.1.0/
/software/geo_procedural/0.2.0/
/software/fur_procedural/1.5.0/
/software/point_instancer/2.1.0/
/software/fx_sop_nodes/3.0.0/

What we typically want to do is construct, for the lack of a better word, a
toolchain. Say, I specify that I want to construct a toolchain with houdini
11.1.118, geo_procedural-0.1.0, fx_sop_nodes-3.0.0, and
point_instancer-2.1.0.  The toolchain builder can now run a small
initialisation script that would add each requested software package to my
environment.

For the "houdini" package it can be as simple as doing:
source houdini_setup

For the fx_sop_nodes, the init script can append to the houdini path:
export HOUDINI_PATH=$HOUDINI_PATH:/software/fx_sop_nodes/3.0.0

These toolchains typically differ on a per-shot basis across larger
productions. The list of packages can be stored in a text file, and the
toolchain can be constructed when the user enters that shot. Clean and
easy.

So, as Sebastian have stated, the annoyance comes in when having to
construct a central VRAYProcedural when dealing with such dynamic
toolchains. Unfortunately, the mantra procedurals are not picked up via the
HOUDINI_PATH or any other similar environment variable. :(

We can always work around it, by doing something like this in the
prodedural init scripts:
export VRAY_PROC=$VRAY_PROC:/software/geo/0.1.0/

And then after all the packages have been loaded into the environment, run
another tool that constructs a temporary VRAYProcedural file using the
paths in the VRAY_PROC environment variable, but this is less than ideal. I
would like nothing more than to have the mantra procedurals being picked up
from HOUDINI_PATH, or some similar environment variable, in the same
fashion as DSOs and OTLs are loaded.

So, that's more or less the process, as I see it, in broad strokes.I hope
it makes sense.

And then the inevitable question, what are the chances of getting the
feature of multiple mantra procedurals loaded via an environment variable,
or multiple VRAYProcedural files, rather than a central VRAYProcedural file?

Kind Regards,
Van Aarde.



On Sat, Jan 21, 2012 at 1:37 PM, Mark Elendt <mark at sidefx.com> wrote:

> How do you deal with the different plug-in versions?  i.e. how do you
> determine which plug-in gets put into the file in /tmp?
>
> On Saturday Jan 21 at 13:19, Sebastian H. Schmidt wrote:
> > Hi Mark,
> >
> > thanks for this snipped, it makes sense, and i guess it'll work just fine
> > with a couple of shots/different configurations.
> > But when it comes to bigger production and a huge number of different
> shot
> > configs, keeping the VRAYprocedural-files in each shot up to date adds an
> > additional level of complexity especialy if you have a tool that manages
> > the config, but does not modify the VRAYprocedural file as well :/.
> >
> > I've modified the mantra-wrapper so it searches through the $HOUDINI_PATH
> > for all VRAYprocedural files, combines them into a single file and puts
> > that one in a temporary directory (/tmp/mantra-<pid>)
> > that path gets prepended to the HOUDINI_PATH and than mantra starts up.
> >
> > Have all a nice weekend!
> >
> > Seb
> >
> > On Fri, Jan 20, 2012 at 6:44 AM, Mark Elendt <mark at sidefx.com> wrote:
> >
> > > VRAYprocedural is processed by CPP.
> > >
> > > I'd create a site-wide file, say "MyPlugins.inc" which contained
> > > something like:
> > >
> > > --- CUT-HERE ------ CUT-HERE ------ CUT-HERE ---
> > > #define DRIVE /myDrive
> > >
> > > #if defined(WIN32)
> > >    #define DSO_FILE(FILENAME, VERSION) DRIVE/mantra/FILENAME-VERSION.so
> > > #else
> > >    #define DSO_FILE(FILENAME, VERSION)
> DRIVE/mantra/FILENAME-VERSION.dll
> > > #endif
> > >
> > > // Always include plug-in A.  If the caller hasn't specified a
> > > // particular version, use the latest.
> > > #define LATEST_A_VERSION 1.3.4
> > > #if !defined(A_VERSION)
> > >    #define A_VERSION LATEST_A_VERSION
> > > #endif
> > >
> > > #if defined(A_VERSION)
> > >    DSO_FILE(PluginA, A_VERSION)
> > > #endif
> > >
> > > #if defined(B_VERSION)
> > >    DSO_FILE(PluginB, B_VERSION)
> > > #endif
> > > --- CUT-HERE ------ CUT-HERE ------ CUT-HERE ---
> > >
> > > Then, since you need control on a per-shot basis, I'd create a
> > > VRAYprocedural file for each shot, with something like:
> > >
> > > --- CUT-HERE ------ CUT-HERE ------ CUT-HERE ---
> > > #define A_VERSION 1.2.0
> > > #define B_VERSION 1.5.3
> > > #include "/myDrive/MyPlugins.inc"
> > > --- CUT-HERE ------ CUT-HERE ------ CUT-HERE ---
> > >
> > > Of course, since the path is searched according to the HOUDINI_PATH,
> > > you can have different VRAYprocedural files at each level.  So,
> > > site-wide, you could have one set of procedurals, then override them
> > > as needed on a per-show/per-shot basis.
> > >
> > > That's how I'd do it, though I'm sure there are other approaches.
> > >
> > > On Thursday Jan 19 at 18:00, Sebastian H. Schmidt wrote:
> > > > Hi All,
> > > >
> > > > i'm running into a problem where I have mutiple VRAYprocedural files,
> > > which
> > > > are somewhere in the $HOUDINI_PATH.
> > > > and the $HOUDINI_PATH changes depending what i'm doing
> > > >
> > > > so sometimes i have
> > > >
> > > > /myDrive/myPluginA-1.2.0/VRAYprocedural
> > > > /myDrive/myPluginB-1.5.3/VRAYprocedural
> > > > /myDrive/myPluginC-0.2.3/VRAYprocedural
> > > >
> > > > and another time i have
> > > >
> > > > /myDrive/myPluginA-1.3.0/VRAYprocedural
> > > > /myDrive/myPluginF-2.5.3/VRAYprocedural
> > > > /myDrive/myPluginC-0.7.0/VRAYprocedural
> > > >
> > > > etc.
> > > >
> > > > BUT i'm only alowed to have one VRAYprocedural. :/
> > > >
> > > > I cant build one general VRAYprocedural,  because the
> version-numbers &
> > > > plugins  are changing depending even on a shot-basis.
> > > >
> > > > Am I the first who encountered this ?
> > > > Does anybody have an idea how this can be solved ?
> > > >
> > > > Thanks for your help!
> > > >
> > > > Seb
> > > > _______________________________________________
> > > > Sidefx-houdini-list mailing list
> > > > Sidefx-houdini-list at sidefx.com
> > > > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
> > >
> > > --
> > > Mark Elendt
> > > _______________________________________________
> > > Sidefx-houdini-list mailing list
> > > Sidefx-houdini-list at sidefx.com
> > > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
> > >
> > _______________________________________________
> > Sidefx-houdini-list mailing list
> > Sidefx-houdini-list at sidefx.com
> > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>
> --
> Mark Elendt
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>



-- 
Van Aarde Krynauw

FX TD
Method Studios, Sydney

http://za.linkedin.com/in/jivakrynauw



More information about the Sidefx-houdini-list mailing list