The Quality of Life stuff...

Better cache node:
Push cache node to tops, ordered. Right-click on cache node.

Local / Global cache path - sim locally then push to NAS when accepted (not always applicable workflow, but it should be there) or localize files to workstation. all this requires is a local, lets call it volatile cache var and scene cache file, say $VCACHE which is a local machine temp folder, and $HIP/cache, not geo, folder and option to migrate between the two from within houdini. Obviously user decides what to use, as it would be impractical to migrate / localize > 1tb of data , also the operation should be "non-locking"/bg task.

Basic file management for cached files - eg. purge cache files for certain version eg purge v2 or all from given path.

I'd prefer if the workflow was more logical with Solaris in context of a single artist, it's always easier to follow /obj -> /stage data flow instead of garbing things from solaris. Say you are on obj level, you have clear overview of all the nodes, select them all, right click and push them to solaris, where in solaris you have all the nodes created unordered, but set up, as sop imports, instead of going sop import node, set parameters, sop import node, set parameters, sop import node, set parameters, link, debug, figure out what you missed, sop import node, ad nauseam... So similar logic to cache node and tops.

Compositing context is a bit disconnected from houdini. Clicking on file dialog button via shift click option to bring up "internal file system", or have a dedicated button, and leverage a path as an op: would better connect cops and other contexts, say dops collision volume proxy

togglable attribute addition exclusion inclusion, say you have Cd id pscale in att delete and you've decided you only need v, alt clicking on v should remove all and set v as the only attrib, so add/remove/replace...

Better selection tools, currently five sel tools, and five modes, some times you just need to select stuff efficiently and not worry about the procedural nature of the universe...
so brush and laser could be one tool - a brush tool with a global pref for three states that it would have radius 0 which would be "laser", radius 10 (definable in prefs), radius 20 (definable in prefs), hitting a hotkey for select (forgot the default one, I use v for brush, and shift-v for rectangle), would toggle between three states 0-10-20-0-10-20, each of them modifiable on the fly (radius), and considering that you can zoom in or out of geo, you really don't need more than that, brush should be always visible only, and rectangle could be all. toggling between box and lasso could be on the same hotkey, as it makes sense to sort of concatenate similar tools. selection should be always additive, with shift toggle while pressed to remove from selection, a tool to flood fill select polygons from edge boundary should really exist in houdini, unless I missed it somehow... this is a tested thing and it is soooo much faster and better to work with, albeit in a different dcc.

Nodes from tree view, context sensitive, eg grab a selection from treeview and drop it in current geo/obj context for populated mergeobject node instead of rather useless navigate to option, just one example, it could be bidirectional.

shelf, redesigned. single shelf, instead of bunch of tabs you could have icons with pop-ups for sub commands/tools? say light -> list of lights, anything that registers as a light should popup there... freely movable/reorderable and dockable

cursor hot-tracking / navigation, grab mat from /mat, hover over node to select it, hover over param view/render tab, it gets selected, drop material... just one example.

dockable/undockable windows

freely movable playbar, shelf and statusbar

attach statusbar options (sim) to main network view or all views.

status bar could be made as an overlay "attached" to certian user def. network view

houdini should be made aware of number of displays and resolution and act accordingly

ground up redesign of the viewport and transform gizmos and right click options, and associated toolbars, with options to modify/reorder them.

playblast should have an option to use offscreen rendering without going to /out/ogl etc.

better organization of anything related to presets saving/loading/editing

better gradient management

better color swatch with prefs, currently it rather annoys me that it's always going rgb-hsv-tim, when it needs to be hsv-rgb-tim

color presets/swatches

non-monolithic vex preset system, ie. source from folder, and all it's subfolders all files function.vex instead from one file as it is currently, and sort them accordingly
folder1
sub-folder-category1
vex4
vex3
vex1
vex2
vex5
vex6
etc.


(float) ramps should add a sort of shift key override when moving values - eg. use on mouse up while shift is pressed to move the "dots" and not try to keep up with the updates

working with curves/splines should be as easy as in any 2D app, and not convoluted and complicated

complete rework of animation editor, without any convoluted mmb clicks to do stuff, straight forward selections, better curves handling (at least better than the current/redesigned spline tool) it feels a bit like they are stuck in the 70's in regards to ux and early 90's for the ui. Sorry :/


when cooking is interrupted it should stop on whatever frame it was interrupted-1frame and not cook for one more frame and then stop

customizable playbar and it's buttons

better hotkey window, or just columns that work. namely location of the function for the given key
better organized hotkey pref window with clear grouping, and optional minimal set of shortcuts, currently it's overloaded for no reason, and nobody's going to remember all that, especially when spread out... anyway it's a longer discussion...

a "modern" edit parameter interface so that you can drop things where you want and how you want them, auto expansion of labels from name - my_function -> auto set as My Function in the label field

ramps that work in sub level without promotion, and have a unique/random id on creation attached to them

complete redefining of parameter attributes, a sort of visual dictionary - input field and it's options self contained sourced globally if that makes any sense

colorful but not overly skeuomorphic icons, grouped by color

reduction of nodes, say one wrangle node instead of five, with run over iconified, colorized and spread out in one line, so it is immediately obvious which mode it's in

alt click create spare parameters button should destroy and recreate the entire ui, effectively removing non-existing parms.

selecting preset from dropdown for wrangles could have shift toggle, so shift click preset to append to current code.

global color theme and font selection for wrangles
comment un-comment for selected via #, obviously it should result in // or ''' ''', selection/context sensitive

complete rework of autosave system. (I can explain upon request, I'm just too lazy to do it now )

rework menu system to anything other than xml, with easier function calls that live elsewhere, to be honest, I just glanced over it, seemed annoyingly convoluted and left it.

obliterate houdini.env and source everything from packages.json first.

network box text options, size and placement inside or in titlebar + size.
color palette for nodes + hsv selector.

alt drag input field to another to ref. it

rmb menu entry convert fields to single float, like you have in attrib noise - amplitude.

most of this, if not all, I already submitted as an RFE in one form or another...

show display operator instead of current as default, where most actions are aware of this and don't break, seems inefficient to double the displayed geo, there's got to be a better way.

dedicated icon or dropdown for preset selection in parm menu

transform box if dragged on one side and you introduce shift as a modifier should recalculate and display constrained resize for both sides on that axis, hopefully that made sense

removal of all auto calculate options from view, eg lights intensities, near/far clipping planes, that is always producing issues and artifacts and is kinda unacceptable.

and now the biggest annoyance - moving around in the viewport is not a tool, it's a baked in option, alt+whatever should instantly work and not think about - wait, I'm a tool, ok, hold on here we go, we are moving... move rotate zoom is first order of operation, any other option that conflicts with that should be removed, obliterated, gone, since alt mouse navigation is an after thought in Houdini...

the new dashboard is so noisy, and lacks any sort of customization that I find it rather useless, and the tab menu should really have history section above the input field...

anyway it's starting to turn into a rant so I'll stop here

So there, quality of life IMPROVED .

EDIT:
Forgot to mention that the ladder system is rather unreliable and could get you into trouble, and instead there should be a context sensitive, based on cursor position in the input field how much to increment values, alternatively scale mouse drag via ctrl,alt and shift instead of ladder… a cross between nuke style value editing and adobe...

Since the nature of the question forces us to focus on the negative aspects of Houdini, it’s worth mentioning that Houdini is more stable, reliable, and polished with each new release, an easy test is to download earlier versions and see how you like them for a change

Great compilation of quality of life ideas hMonkey.

I specially like the ones that feel like small change but quite big QOL improvement.

hMonkey
togglable attribute addition exclusion inclusion, say you have Cd id pscale in att delete and you've decided you only need v, alt clicking on v should remove all and set v as the only attrib, so add/remove/replace...

hMonkey
status bar could be made as an overlay "attached" to certain user def. network view

hMonkey
selecting preset from dropdown for wrangles could have shift toggle, so shift click preset to append to current code.

Others ones you mention seem bigger change but I also think they could be great.

vinyvince

tsiwt
Redo the whole Houdini U.I from scratch.

I and people around me don't see the Houdini UI has a priority at all, i have personally like it and would *much more* prefer efforts to be focused on other areas:

- Bugs fixed ( totally agree on viewport comment)
- Have viewport improvement and python state to be more straightforward like it is in Blender
- Rewrite COP yes this one maybe you could do it from Scratch imo
- Better RAM control for complex PDG graph,
- Some Houdini and especially LABS tools really needs to be more clean and with few minimal comments at very least!
- Anyone who has ever tried to seriously link Houdini to custom game engine knows the pain as soon as you could pass non trival cheesy things.. and the unity support today is close to none today...
- Vex Wrangle preset need Tag search, Python code editor is even weaker

Great suggestions.

tsiwt
Redo the whole Houdini U.I from scratch.

I agree GUI is completely outdated but I personally care more about the functionality of the GUI more than the look.

I would hope that at least some functionality gets improved or added in the next versions.

Many cool small improvements mentioned in this thread.

hMonkey
Since the nature of the question forces us to focus on the negative aspects of Houdini, it’s worth mentioning that Houdini is more stable, reliable, and polished with each new release, an easy test is to download earlier versions and see how you like them for a change

It's kind of strange that talking about QOL improvements end up sounding like a rant.

It makes me think perhaps there is a common feel that QOL and GUI related features haven't improved that much in the last versions.

andreuparri

hMonkey
Since the nature of the question forces us to focus on the negative aspects of Houdini, it’s worth mentioning that Houdini is more stable, reliable, and polished with each new release, an easy test is to download earlier versions and see how you like them for a change

It's kind of strange that talking about QOL improvements end up sounding like a rant.

It makes me think perhaps there is a common feel that QOL and GUI related features haven't improved that much in the last versions.

Sure they have, but only for new nodes, a good example is pyro, it’s parameters ui is considerably better, although still a bit to "tabby"… For some reason sidefx tends to pack parameters so they fit into a box that is 1/4 screen size...

Anyway another QoLi would be to have file cache created when clicking the node lock, or rather turn the lock into filecache node on every node… where upon clicking a file cache is created as a side-flow… or toggle it - click to insert into flow, alt click to branch it, instead of lock, which is more trouble than it’s worth...

andreuparri
It's kind of strange that talking about QOL improvements end up sounding like a rant.

annoyance * frequency of use * time = rant

hMonkey
Sure they have, but only for new nodes, a good example is pyro, it’s parameters ui is considerably better, although still a bit to "tabby"… For some reason sidefx tends to pack parameters so they fit into a box that is 1/4 screen size...

Yes but that we can already do this ourself in our tools.

What I'm looking forward is to improve the functionality of the parameter architecture, they have added a few things over the years but not that much.

More parameter types, more customisation, better and simpler python control of parameters, live import parameters from other nodes, etc...

The stuff that we can not do but only the devs.

hMonkey

andreuparri
It's kind of strange that talking about QOL improvements end up sounding like a rant.

annoyance * frequency of use * time = rant

Nice formula.

That was actually my initial point, the frequency of use and time of use are crucial for a QOL improvement.

The more often gets use the more QOL improvement it is imo.

I’d settle for a more manageable/organized houdini env…
Better handling and organization of snippets, presets and anything and everything that is customizable, from within houdini.
That way you can build and manage your env/tools on the fly…
Almost everybody has their own cheatsheet of vex somewhere, why not within houdini.
If you write a wrangle, you should be able to save it under a specific category instead of saving it as a node preset, sooner or latter that menu is going to be overloaded and impractical…
Same thing with shaders, vops, etc (where it makes sense, of course)
If the idea of houdini is to "build your own™", they should facilitate such workflows instead of a lazy approach "just-dump-it-anywhere-worry-about-it-latter™"
Say a package that defines a custom dir for preset saving, and and everything gets dumped there, but with clear structure…
You can do that now to some extent, but it’s nowhere near as elegant as it should be.
And third party tools keep poping up to solve this, so obviously there’s a need for them.

-It would be useful to have a built-in way to save fields in vdbs as separate files automatically, similar to how render aovs can be put in one exr or split among multiple files.

-vex wrangles should have an additional text box where we can define functions to be used later in the main code. I think the inline code vop already implements something like this with the outer code text box.

Soothsayer
-vex wrangles should have an additional text box where we can define functions to be used later in the main code.

You can do that with #include <textfile_with_your_functions.h>

BabaJ

Soothsayer
-vex wrangles should have an additional text box where we can define functions to be used later in the main code.

You can do that with #include <textfile_with_your_functions.h>

Includes are a possibility but in the spirit of Quality of Life here are the problems as I see them:

-dependency management: includes becomes a dependency of the main code file and it's associated houdini version and you need to manage dependencies and track changes to the code. Name collisions will also occur and be dealt with.

-code clarity: the included file either contains a large amount of code, which makes it difficult to read and understand or you end up with countless artist supplied files.

-accessibility: if you are in a studio environment permissions and potentially file structures need to be set up and approved. Pipeline might want to get involved and cause much delay and overhead.

-debugging: tracking down problems, especially if they happen to the farm or more junior users become more complex. If pipeline insists on version controlling the code then it deters artists from using includes.

Defining and using new functions in VEX can and should really be straight forward. There's no need to open a can of code management worms if all you want is organizing your own little wrangle backyard.

Soothsayer
-It would be useful to have a built-in way to save fields in vdbs as separate files automatically, similar to how render aovs can be put in one exr or split among multiple files.

-vex wrangles should have an additional text box where we can define functions to be used later in the main code. I think the inline code vop already implements something like this with the outer code text box.

Soothsayer
-It would be useful to have a built-in way to save fields in vdbs as separate files automatically, similar to how render aovs can be put in one exr or split among multiple files.

-vex wrangles should have an additional text box where we can define functions to be used later in the main code. I think the inline code vop already implements something like this with the outer code text box.

I many times missed the extra text box too.

It would be cool if we could
#include /obj/geo/anotherwranglewithfunctions

Soothsayer
-dependency management: includes becomes a dependency of the main code file and it's associated houdini version and you need to manage dependencies and track changes to the code. Name collisions will also occur and be dealt with.

None of that is an issue if you actually use the already existing Qaulity of Life Houdini has given you, in terms of file structure.
$HIP is your friend.
Your main directory holding your hip file also holds all your easily referenced project user created 'dependencies', like backup, geo, etc. folders. In this case you have a vex/include folders. You .hip file looks to your $HIP directory. It's a very good 'Quality of Life' if you make use of that.

If you move that $HIP file around, everything else comes with it.

Are you going to use a more recent version so Houdini with such a system with a specific .hip file?
Are you saying you have to change the function/s because of it?
If so, it's much easier and quicker to change the function once in the vex/include file than to hunt around in your hip network looking for all the nodes and change them there multiple times. But if your thinking of having one text box like a python cource editor in which all the nodes have access; Then aren't you going to back up that as a text file anyways? or everytime you need those same functions in a new project are you going to go and search for hip files that have those functions and copy and paste? Much easier and quicker to have an already existing directory/file that you can reference quickly.

-code clarity: the included file either contains a large amount of code, which makes it difficult to read and understand or you end up with countless artist supplied files.

Your include files are created by you. If they are too big, then don't make them too big. Break them up into seperate files that you understand. If I have a specific function that has like say 800 lines of code, I save that as a single file and the name of the file is set as the name of the function. When I include the file in my wrangle I can use that function easily because if I forget the name of the function I just look at the name of the file I included.
Same goes for 'artist' supplied files and 'artist' supplied .hips. I would rather sort through their files of functions rather than going through their nodes, hunting down for functions written in text boxes.

-accessibility: if you are in a studio environment permissions and potentially file structures need to be set up and approved. Pipeline might want to get involved and cause much delay and overhead.

If you're in a studio environment then this whole conversation is moot in regards to 'dependencies' and the issues you cite.
A studio environment is going to have all kinds of dependencies and workflow setups by necessity and functional efficiency anyways.

-debugging: tracking down problems, especially if they happen to the farm or more junior users become more complex. If pipeline insists on version controlling the code then it deters artists from using includes.

How is version controlling your code(functions) any different whether its sitting in a file in a vex/include directory or sitting in a wrangle text box. At least if you need to debug the function, looking at the one file, knowing all references point to that is much easier to inspect rather than each instance of a node with a function in a text box that holds the possibility of having some variance - intended or not.

"Defining and using new functions in VEX can and should really be straight forward."
For me that's what it is using the advantage of having a $HIP and vex/include folders/directories.

andreuparri
It would be cool if we could
#include /obj/geo/anotherwranglewithfunctions

You have the same thing with #include <$HIP /vex/include>

BabaJ

andreuparri
It would be cool if we could
#include /obj/geo/anotherwranglewithfunctions

You have the same thing with #include <$HIP /vex/include>

That's pretty cool, I never thought of that. I'll start using this.

BabaJ

andreuparri
It would be cool if we could
#include /obj/geo/anotherwranglewithfunctions

You have the same thing with #include <$HIP /vex/include>

That's cool but not the same.

I think it would still be even more useful to use nodes instead of vex files next to hip file for the same reason I prefer wrangles than vex files in disk.

Including functions from other nodes would also allow for importing vex functions from hdas which is something I many times wished was possible.