Every time I open Houdini, I want to make art; what I do not want to do is to click ten things to get setup while forgetting others. I don’t want to keep telling it where my project folder is, or risk losing my work because I once again forgot to turn on autosave (you know that pain). So, I decided: enough is enough — Houdini should behave the way I want it to, the moment it boots.

What began as a simple idea — “hey, can I set some global variables from a JSON file at startup?” — turned into a very nerdy, surprisingly satisfying deep dive into how Houdini starts up and what you can teach it to do automatically.

First, I Wanted Global Variables

I had a global_vars.json file like this:

Obviously, I have more in the real thing — but for demo’s sake, let’s keep it simple. The idea is to define your custom environment variables as key-value pairs in a JSON file. Super clean. Super portable.

Creating a Custom Startup Folder

Now, I didn’t want to just drop files into Houdini’s default preferences folder. I like keeping things clean and under my control. So, I created a custom folder called:

You can place this folder anywhere you like. I saved mine here:

Which I’ll now refer to as:

(Just be sure to replace this with your own custom path.)

Inside that, I created a scripts folder. So now the full structure looks like:

This is where the fun begins.

Why 456.py?

Houdini has a few special filenames it watches for when it starts up. One of them is 456.py — it runs automatically each time a new scene is opened or created. It’s like saying: “Hey Houdini, every time you load, please run this custom script for me.”

So, in our case, we drop that file inside scripts/456.py.

Here’s the first version of my 456.py:

You can also save your global_vars.json right here in the same folder — it keeps everything together and predictable.

Tell Houdini Where to Look

Now we need to let Houdini know that this custom startup folder exists.

Open up your houdini.env file (you’ll find it in your Houdini user preferences folder — usually in Documents/houdini20.x/).

Add this line:

That tells Houdini: “Hey, check this folder too when you’re looking for startup scripts and tools.”

(You can also add a custom variable for convenience – This will come in handy later, although it took me a while to figure out, like so:)

Before you ask about slashes

Yes — the direction of slashes absolutely matters in Houdini’s .env files.

Use forward slashes / — not backslashes — in houdini.env

Backslashes () are interpreted as escape characters on Windows, which breaks the parsing. Houdini expects POSIX-style paths (with forward slashes), even on Windows.

Try It Out

Now, with your folder structure all set, your 456.py and global_vars.json in place, and the path added to houdini.env, fire up Houdini.

You should get a nice little confirmation popup and output to the Houdini console:

If you see that, congrats — Houdini is reading your startup script successfully! 🎉

Now that the plumbing works, you can start wiring in your own defaults and preferences — and that’s where things get exciting.

Automating the Boring Stuff: Default Preferences

Once I had 456.py running and pulling in my global variables (I’ll get to this in a minute), I thought — why stop there?

There are a bunch of tiny (but annoying) things I always have to do when starting Houdini. Things like:

• Setting my default project directory
• Making sure autosave is turned on
• Adjusting how often it autosaves (if it even does )
• And maybe more as I go along…

Setting a Default Project Path

I want Houdini to always open with my project path set to:

To do that, I added this line to my 456.py:

This sets the HIP variable — which Houdini uses to define the current project root — right at startup. Now when I hit save or browse for assets, I’m already where I want to be.

No more clicking through folders like it’s 1998.

Enabling Autosave Automatically

Raise your hand if you’ve ever crashed Houdini and realized autosave wasn’t on

Or better yet — made massive progress on a scene, thought “I should probably save soon…”, and right as your finger inches toward Ctrl+S… KPLC (our lovely power company) in their wisdom decides “Now would be a great time for a blackout.”

Cue the scream. And the slow, painful reboot.

Also — why isn’t this (autosave) on by default anyway?

So let’s fix that forever.

You can’t use hou.setPreference("autosave.enable", True) — I tried, and Houdini threw a TypeError tantrum.

Took me a while to solve — a bit of internet sleuthing, some trial and error, and a few deep dives into chat forums later, I found something that worked:

That’s right — good old hscript to the rescue.

This tells Houdini:“Hey, always turn on autosave for this session.”

You could also run this directly in the Python shell, but putting it in 456.py means you never have to think about it again.

But What About the Autosave Interval?

Ah yes — you’d think you could also set the autosave interval (say, every 10 minutes) in the same way. But nope.

I tried:

And Houdini clapped back with a TypeError: argument 2 of type 'char const *'.

Unlike other preferences, autosave.interval expects a string, not an integer — and even if you convert it to a string, Houdini won’t accept it here. There’s no exposed HScript command for it either (as of Houdini 20.0.547), so unfortunately, there’s no way to set the autosave interval programmatically at startup (that I know of 🤷‍♂️).

For now, this has to be set manually in the Preferences window (Edit → Preferences → Hip File Options → Autosave Interval).

If anyone finds a hidden way to set this — please let me know!

Perfect — let’s wrap up this post with the final piece: reading and setting global environment variables from a JSON file using your 456.py script.

We’ve already set up the folder structure, told Houdini where to look, and even celebrated a little popup when 456.py runs. Now let’s make it do something actually useful.

Reading Global Variables from a JSON File

Remember that global_vars.json file sitting next to our 456.py? It’s time to make Houdini read it and use it to set up our environment.

Here’s what my global_vars.json looks like:

And here is what my variables in houdini look like:

Now let’s load and apply those variables in 456.py.

Replace the contents of your 456.py with this:

Let’s break that down:

• We read the file using the CUSTOM_START_UP_PATH environment variable you defined in houdini.env. (Side note: I originally tried using __file__ and os.path.dirname, but Houdini didn’t love that — so this method keeps things reliable.)
• Then we loop through the JSON and set each key-value pair as an environment variable using hou.hscript(f'setenv {key} = "{value}"').If you want your variables to show up under Edit → Aliases and Variables → Variables Tab (and actually be useful in Houdini expressions), you need to explicitly use hou.hscript() to call Houdini’s internal setenv command.
• If something goes wrong, you’ll get a Houdini popup telling you what happened — which is way better than Houdini silently ignoring you.

Double-Check: Are the Variables Set?

Once Houdini launches, go to:

Edit → Aliases and Variables → Variables Tab

You should see DATA (and any others you added) listed there. That means it worked!

Why this works

• hou.hscript("setenv VAR = VALUE") sets the environment variable inside Houdini’s context, which means it behaves like a true Houdini global variable — accessible to parameters, expressions, and the UI.
• Using os.environ alone won’t get your variable to show up in Houdini’s interface.

Now when you launch Houdini, not only does your script run — it sets up your custom paths, values, or flags in a way Houdini understands and uses throughout your session.

Want to test it? After startup, open the Textport and type:

And boom — your value should print back to you. Houdini is now loading your global preferences like a pro.

Wrapping It Up

What started as a small question — “Can I load global variables from a JSON file at startup?” — ended up teaching me a lot more about Houdini’s startup process than I expected. But honestly? It’s been worth every rabbit hole.

With just a bit of setup, I can now:

• Load all my global paths and settings from one clean JSON file
• Keep my startup files in a dedicated, portable folder
• Automatically turn on autosave so I don’t lose hours of work
• Set up my project defaults exactly how I like them — every time

Below is a screenshot of my actual global_vars.json, which includes more useful paths I use in my day-to-day Houdini work, and what the Aliases and Variables panel looks like after startup — Houdini is picking everything up automatically

This small change has made a big difference to my daily workflow. No more forgetting to toggle autosave or digging through folder paths every time I start a project. Houdini just feels… ready for me now.

If you’re building your own setup, feel free to borrow, tweak, or expand on this approach. And if you run into weird gotchas — like Houdini ignoring 456.py unless the path is in HOUDINI_PATH — hey, at least now you know what to check.

Happy customizing!🧠💥