Another annoying issue that bugs me daily but is a bigger problem to explain to people who start using Houdini at workplace is, the behaviour of loading the desktop the hip file was saved with automatically on file open.

I don't know how to explain this other than to say “it just is”. I think I submitted this ~3 years ago but wasn't accepted. No other major 3d app does this AFAIK.

It's akin to loading a programmer's default UI and color scheme when you open his project file in Visual Studio if we can make a programmer analogy.

Everyone has their own setup, so it's very annoying to be forced other people's desktops on file load.

Even if this is what the majority wants, can we please at least have a setting that disables this and just uses the currently loaded desktop.

pusat
the behaviour of loading the desktop the hip file was saved with automatically on file open. … I think I submitted this ~3 years ago but wasn't accepted.

It's still active: RFE #50276. I pinged it with a link to your post. It gets me frequently too, since quite a few people use the technical desktop, but I get disoriented in it.

I also find that quite annoying. It's easy enough to get around at home (custom 456.py that just sets my desktop whenever something is loaded) but unfortunately that's not a practical solution in a production environment

Make preference! Most happy!

graham
I also find that quite annoying. It's easy enough to get around at home (custom 456.py that just sets my desktop whenever something is loaded) but unfortunately that's not a practical solution in a production environment

Make preference! Most happy!

ndickson

pusat
the behaviour of loading the desktop the hip file was saved with automatically on file open. … I think I submitted this ~3 years ago but wasn't accepted.

It's still active: RFE #50276. I pinged it with a link to your post. It gets me frequently too, since quite a few people use the technical desktop, but I get disoriented in it.

Glad I am not the only one IMO no software should force these kinds of settings on the user, nor require you to write code to circumvent it.

Another issue is since the loading of desktops are by name, someone's Build desktop isn't necessarily the same as someone else's Build desktop which makes this “feature” even less useful.

ndickson
It's still active: RFE #50276. I pinged it with a link to your post. It gets me frequently too, since quite a few people use the technical desktop, but I get disoriented in it.

I work around this by hiding all desktops except the Technical desktop. This forces all files to open in that desktop as it is the only available desktop…

jlait

ndickson
It's still active: RFE #50276. I pinged it with a link to your post. It gets me frequently too, since quite a few people use the technical desktop, but I get disoriented in it.

I work around this by hiding all desktops except the Technical desktop. This forces all files to open in that desktop as it is the only available desktop…

How do you hide desktops? By deleting it?

If SESI itself is annoyed by this, then it creates even more reason to fix this issue IMO.

pusat
How do you hide desktops? By deleting it?

Windows:esktops:esktop Manager
Then hit the H flag on the desktops you don't want. This will create DesktopName.hide files in your ~/houdini15.0 directory to suppress the desktops.

jlait

pusat
How do you hide desktops? By deleting it?

Windows:esktops:esktop Manager
Then hit the H flag on the desktops you don't want. This will create DesktopName.hide files in your ~/houdini15.0 directory to suppress the desktops.

Great info. I thought I had to delete the desktop files, but this is not possible at studios as we don't have write access to installation files, nor it's a good idea.

Unfortunately, all the settings within the panes are stored on the desktop itself within the hip file, so if you force your own desktop on a hip file you may lose some important information (camera the viewport is looking though, LUT, etc) along with the trivial (stowbar states).

Might not be a big deal to some but it's at least important to note that it's not just a trivial change - it has some far-reaching consequences.

twod
Unfortunately, all the settings within the panes are stored on the desktop itself within the hip file, so if you force your own desktop on a hip file you may lose some important information (camera the viewport is looking though, LUT, etc) along with the trivial (stowbar states).

Might not be a big deal to some but it's at least important to note that it's not just a trivial change - it has some far-reaching consequences.

That puts things into perspective. It would be awesome if they were decoupled in a future version. Because settings like cameras, LUTs, etc are generally set at project level, so aren't needed to be enforced on a file by file basis IMO.



regex VEX functions are unintuitive to use

The input string coming as the last argument is very unintuitive, even for VEX. It would have been easier to use if the first argument was the input.

I was told this is because:

"This is done this way to match python.

https://docs.python.org/2/library/re.html [docs.python.org]

While split can be thought of as a function on the string, the re_ functions are functions on the regular expression. Thus why they all start with the regex, not the string."

But the issue is VEX is not object oriented, and IMO it would make more sense to have it similar to C-like languages (C++, C#, Java) which VEX is based on syntactically more than Python.

Node connections are drawn incorrectly when the input order is changed (3.5 years old)

This is an issue I still see even other Houdini TDs at work suffering on a daily basis. It's painful when the network is heavy and/or you are using Manual update mode and you are confused which connection belongs to which node.

Another issues that causes a lot of grieving at work:

Houdini doesn't bring its child windows to front when one of them is brought to front. In Windows this works. So if you click on any window that belong to a particular instance of Houdini, all of them come to front which is great when you have multiple Houdini instances open with a floating window for each showing the viewport.

In Centos linux, this doesn't happen. I reported it but support couldn't reproduce. Because there is no easy way to tell which belongs to which instance in this case, it causes a lot of issues.

In fact just several of my colleagues confirmed as they saw me writing about it that this is also causing them to waste a lot of time. Please consider looking into this issue as it's real.

Try: Edit > Prefs > General UI > Keep Floating Windows on Top

twod
Try: Edit > Prefs > General UI > Keep Floating Windows on Top

Thanks a lot, that works great I will let other people know so they don't agonize over this anymore.

Jump to Operator button doesn't pan the network view after jumping

If you use the jump to operator button in any node, like Object Merge for example, it only goes into that node network and select that node, but you still have to wander around the network editor to see where that node really is, which makes this feature not so useful.

A lot of cooking related issues that's hard to submit in a single bug. There are lots of cases where you try to cancel a cook but Houdini is forcing the cook on you repeatedly.

For example, you try to enter into subnet, but subnet has to cook, which is ok, you press Esc, but that also stops you from going in. It should still allow you go in. So you have to try again to get into the subnet.

Or you copy paste a node that takes some times to cook, so Houdini not only has to cook the new node but also the old node that's copied. That's wasteful and annoying. Even setting updates to Manual doesn't fix, this as I assume the node is being flagged as dirty (needs cooking).

So many issues like this that needs to be carefully planned to make Houdini smarter and easier to work with in production.

pusat
Jump to Operator button doesn't pan the network view after jumping

If you use the jump to operator button in any node, like Object Merge for example, it only goes into that node network and select that node, but you still have to wander around the network editor to see where that node really is, which makes this feature not so useful.

Just hit ‘f’ in that network and the selected node that you jumped to will be centered. No wandering necessary.

This is the thread that never ends…..until now.