how to find $HOME directory to install shaders

   13135   7   3
User Avatar
Member
50 posts
Joined: 7月 2005
Offline
I am going through the underwater tutorial with shaders and do not know how
to find $HOME directory to install the shaders. It says to open a textport and type $HOME. I have no idea how to do this. Might be silly but i don't. ops:
User Avatar
スタッフ
2540 posts
Joined: 7月 2005
Offline
The quickest way to find out where $HOME is on windows is to launch Houdini and open a textport. Then type:

echo $HOME

It should return something like:
CDOCUME~1/jeff/MYDOCU~1
which expands to
cDocuments and Settings/jeff/My Documents

This is the default path if you haven't set $HOME which will be 99.9% of windows users unfortunately. Why I say that? Read below after.

In this directory you will find a houdini8.0 directory. This is the directory that Houdini creates the first time it is run. This is where all your user-preferences are saved as you re-configure Houdini's many preferences, desktops and defaults as you work. This is also where I would recommend that you save all your HDA's, shaders, etc.

The other “Windows” way to find environment variables for the current user and the OS in general is to naviage through the Start menu like this:
Start -> My Computer -> View system information -> Advanced -> Environment Variables

done.


Now for my rant…

Phew, now you can see the very powerful environment variables for Windows. If you look closely you will see that there is no HOME environment variable present. Houdini sets it's own environment up as it starts if the variable it is looking for and needs isn't present.

These system-wide variables are quite critical for many apps yet windows users work day in and day out blissfully unaware of these. For an OS that lays it's underpinnings on a rip-off of unix to blissfully thumb it's nose at a multi-user environments and user-based environments is criminal IMHO.

Then again I see users day in and day out use Windows successfully to do great work. This works fine at home and in small shops but to employ windows on a large scale, say 50 users or more starts to become a living nightmare to manage. That is why so many large shops use unix of some variant of which linux and the Mac OS are two specific examples.

Believe it or not the major appleal of unix is it's ability to support multiple users within the same environment by utilizing “shells” that can have their own configurations using environment variables. More importantly, it is completely configurable by the end user so power users can customize a base facility-wide project and job environment to easily support their work habbits.

The other important part of unix is in it's implementation of access to files and folders as a user, part of a group or as an administrator. It is fundamental. In Windows it is an option that is loosely adheared to. As far as I am concerned, Windows is not suitable for enterprise CG work because you have really smart people hacking away and most likely have some sort of administrator privelage on their local machine because you can't even install a simple app without this level of access. Unix is different. I can install apps with ownership just set to me and not even have to become the administrator known as root or more aptly the “super user”! In unix a super user is really THE super user. Only call him/her if something is gone real bad!

If you haven't seen someone work in a properly configured unix environment and how fast they can work, employing scripts, managing background process and doing several things at the same time, then you really need to! It is either awe inspiring or you yawn and go back to your own style of working blissfully unaware of what is possible.

I inherited work habbits from the incredible developers here at Side Effects. Watching closely how they worked and reading reference books, I can whip around in unix doing multiple things. Others who happen to watch me just wonder what the hell I am doing to move so fast. It's unix baby.



Now for a bit of a tretiese on Environment variables for Houdini users of Windows that have never encountered environment variables before. Note that the Houdini on-line help has a pretty good overview of environment variables with consideration to windows users.

There are also a great many books on unix, shells and environments.

In the larger picture, there is an all-conquering Houdini environment variable called:
$HOUDINI_PATH
This path is a special one in that it can have numerous locations on disk defined for Houdini to go and pick stuff up. Once again if it is not present, launching Houdini will create it for you. Unforutunately this particular variable can not be echoed from Houdini's textport. It does default to the following:

.; ./houdini; $HOME/houdini8.0; $HFS/houdini

Wha? More unix stuff here and I'll explain.

The “.” or dot means “here”. This means that the file that you double clicked on to launch Houdini, in that folder if there is any Houdini specific files or directories in there, they will be used first.

The “./houdini” is more of the same. Once again the “.” dot means here or the directory that houdini was launched from. Now if there is a houdini directory present, anything in this directory will be used by Houdini. Note that this is searched right after “.” is searched for relavent files. First one wins!

The third entry for HOUDINI_PATH is $HOME/houdini. This is the one that is guaranteed to be there as I said before, Houdini generates this one automatically. Remember that $HOME simply expands to the directory path that we saw above. It just holds that information in a central place that is easy to change and re-configure.

Finally there is $HFS/houdini. The $HFS is another environment variable that Houdini creates as it launches if it isn't already present. It points to the latest installed version of Houdini on Windows. Once again the /houdini directory is a sub-directory of $HFS and that is were Side Effects dumps all kinds of default environment configuration settings, support files, desktops, scripts and much more.

The semi-colons between the different paths is known as a “delimiter” and simply tells the shell and Houdini reading this variable were one ends and another starts.

Typically as Houdini users get more fluent with the way it works, they naturally inherit a more “unix” way of working without even knowing it. Discovering the $HFS/houdini directory and how it can be customized in various ways directly (not recommended) or copying and pasting to $HOME/houdini8.0 and reconfiguring in there opens up a whole new world.


The use of environment variables in Houdini is rampant. Houdini shows it's unix under-pinnings all the time. The path operator navigation is the most evident. Believe it or not this is a very good thing. Windows makes it very difficult to set and use environment variables. This is very unfortunate because they make working in an operating system quite unpleasant for users that require a more powerful way of controling the vast amounts of data the they need to process in different ways simultaneously instead of the way some programmer or TD has decided you should work. This is especially true on Windows where productivity is measured on the “next app release” for example to treat a sequence of images differently.

In my line of work, I have to constantly defeat system wide environment settings to peer in to data to discover what is wrong by making things right. So for me it is very important to know the various interfaces that unix has and how to override them at a user level.

Windows users have sparce fiew avenues to work the “unix” way with shells and environments. There is cygwin and it does it's best at emulating a unix environment on windows. I use this and have configured it to work almost identically to my linux environment. I would recommend you read up a bit on unix and on shells to see if this is for you. If you are interested, instal cygwin on your windows machine. Go to www.cygwin.com [cygwin.com] and download and instal with default settings. It takes about a gig of space. You can always uninstal it cleanly if it's not for you.

You can still use Houdini without shells and environment variables but if you get hired by a Houdini shop or that is your end goal, chances are you will be using shells. Expect the question to be asked at the interview. It's virtually guaranteed to be asked if not required so the sooner you jump in the better.

You can always lean on this forum for more info as you dive in.

Good luck.


-jeff
There's at least one school like the old school!
User Avatar
Member
50 posts
Joined: 7月 2005
Offline
Thanks Jeff. That is great information. Thanks for taking the time to write it down with great detail for me. The explination is awesome.
I will have fun.
User Avatar
Member
117 posts
Joined: 7月 2005
Online
Thanks for this Jeff. I wonder if you could go into a bit more detail about how to set up a multi-architecture pipeline, in particular how the JOB envar is meant to be used. It seem as though if it isn't explicitly set on the creation of a new hip file it's created, but after that it's not referenced from the outside environment. How would I for example use it if I wanted to have filenames be translated from JOB=c:\mapdir to JOB=/home/foo/mapdir when I tried to render a win32 created hip file on a unix machine ? I know about the //machine/home/foo/mapdir symbolic link trick when using samba but I was wondering if there is an environment way of doing the mapping ?

Also has anyone posted any good info on the way they manage pipelines where houdini versions are changing, custom dso's need to be associated with particular projects etc ?

-Drew
User Avatar
Member
7714 posts
Joined: 7月 2005
Offline
JOB should always be set to a path to use forward slashes (even on Windows). So there's no problem with translating. Houdini simply concatenates the strings together passes them onto the OS. Windows NT has always supported forward slashes at the Win32 API level, the backslash thing is strictly a UI decision from what I can tell (as holdover from the DOS days?).

As for changing Houdini versions, I've noticed that it's mostly just judicious changing of environment variables via shell scripts.
User Avatar
Member
1 posts
Joined: 2月 2021
Offline
Is there a way to change the $HOME path? Because mine right now is on C:/Users/user/OneDrive/Documents and I really want to get it out of OneDrive.
User Avatar
Member
833 posts
Joined: 1月 2018
Offline
Yeah, how does one go about changing the $HOME path in Houdini? I assume it would be done in the .env file?
>>Kays
For my Houdini tutorials and more visit:
https://www.youtube.com/c/RightBrainedTutorials [www.youtube.com]
User Avatar
Member
636 posts
Joined: 6月 2006
Offline
It is also possible to use packages.

https://www.sidefx.com/docs/houdini/ref/plugins.html [www.sidefx.com]
  • Quick Links