Houdini 17 Wishlist

[acey195]

Oh yeah theoretically it could totally work, definitely in sub .5 releases (H16.0.000 till H16.0.999 for example) 

Im also pretty sure that there is no way around doing major releases either. On SESI's side, certain features are just not possible to gradually release (such as the Network view rework) as I'm pretty sure that underwent a lot of iterations and testing.
And it would be a nightmare to release fixes for certain versions only, say you are waiting for a fix in H16.0.3, but in H16.0.2 something gets introduced that only negatively affects a very few people, but you are one of them, so you can't use that particular version or many after for instance. So to maintain sanity its probably best to almost only add things and general bug fixes in sub-versions, reworks or removal of stuff just sounds way too dangerous for automatic updates.

I mean you could open all the cans of worms too, and let everyone compile their own version of Houdini.... (this is not a real suggestion... duh xD)

However it is already quite easy to just have 10 (and keep adding) different Houdini Installs on your machine. If you have some clever data-management people, to make sure all the paths to scripts are automatically updated and stuff.
It just takes 20 minutes out of your day, if you do it daily right now. That said, I don't think its unreasonable for some companies to have their own automated distribution and install of Houdini every Night/morning, after downloading it to central depository or something. I guess that is what you mention at the start of your last post, now I reread it..
 

[LaidlawFX]

Ok soo... lol... now I need to deep dive into this not so theoretical system. Mostly for humor sakes.

So the "Production Launcher" for the dev team, only notifies and propagates it's users when a new version is available. Not for all users across the studio. By default it should not download when a new build comes out. At the start of a project you download a Production Version that you are going to begin your project with. With Houdini this can even live on a share directory, not even locally, if the server can handle the load request, def preferable for mid to large studios, and for farm access.

As the project goes on, bugs and rfe are sent to SideFX. Due to their amazing skills these different issues get update with different versions. You either keep an eye on the Daily Logs for the current issue, which the launcher can also share, in addition to the response(s) back from support. You can then trigger a version to download as an alpha user. This alpha version is just for the dev team. They can run Houdini locally, run their test scene, compile their local hdk tools, and see what errors.  Fixing any known or visible issues. If it's a bad build it stop there, they can report back to sidefx if their is an issue. Helping SideFX debug on top of their own internal system.

If it passes the Alpha stage, then it goes to Beta stage, where you can give the option to remotely install on "pro" users, usually the TDs of the team, leads and really technical users. So locally their primary launcher is the original production version of Houdini. However if they are checked in, or subscribed, to the Beta group after a notification/email, they can automatically install and launch Houdini. Installs would happen remotely, or through what ever internal, or sidefx given installer program you want. The beta group then runs this version of Houdini through it paces. If it passes muster, they can approve it to be used for their team/project.

You should always back up that version of Houdini, especially when the .hip file is checked in via ghithub or something, with a tag of which version of Houdini it was last launched in. This way every file has a note of the authoring software version it was created in. That way if you every get a sequel you can relaunch in it's environment of that day.

Usually if you do keep versions local you can save up to 3 versions, encase something dastardly happens and you need to roll back. You change the Houdini_Path variable to ignore that build of Houdini, plus any associate launch options, like shortcuts, or aliased terminal commands. Usually three is enough locally where you would uninstall the oldest of the three versions, when a new one came online, so you don't swamp your hard drive. You can allways retroactively install it if for some reason you approved three broken production build(s) by then I'm guessing you be fired, lol. 

This is turning into an RFE beyond a rant now, lol.

[eetu]

A "this" or "self" value you could enter into the geometry path of all the attribute import functions, which would bind data from the "current" object. In mantra.

[Thomas Helzle]

I haven't touched H16 yet, but if the VEX editor isn't changed significantly, I'd still make it my number one FR to have:

• a more fuzzy search for VEX commands in the code-intelligence tooltip - type "curve" or "point" or "pnt" and get all commands that contain those letters, even if spelled slightly different, not only those who start with it. So if you're unsure how a  command was named exactly, you could go fishing...
• when a VEX command is entered and the opening bracket is set, show the syntax of the command in the tooltip. It is such a waste of time to always have to hunt for it in the docs.
• While you're at it, add some sprinkles like auto-closing brackets, a way to define how closing brackets should be indented (at the moment they are wrong ;-) ), offer to add custom code snippets ...
  ... simply look at some good code editors (I guess you use them to create Houdini anyway ;-) ) and make the VEX editor their equal.

And one for the toolmenu: The nodes in Houdini often have very weird names that make a limited amount of sense if you are used to other packages. So one of my main struggles is, to find the node I'm looking for. Now this could be made much much easier, if the toolmenu search would be more like the one in Rhinos Grasshopper: There, you can for instance type "curve" and see of course all the nodes that have "curve" in their names, but also those who deal with curves. I guess they are doing two things there:

• Have a fuzzy search, that finds stuff everywhere in the node name or even if typed slightly wrong.
• Add a tagging system to nodes or also search through their description, so that the divide node can also be found when I search for "voronoi" (which "create dual" basically means for practical purposes), bring up the fuse node if I search for "join" etc. In Grasshopper there are tons of nodes too, literally hundreds of them are custom ones from users, but finding them was much easier because of this advanced approach to searching. In Houdini, finding the node that does what I need is one of the major hurdles and also makes exploring and discovering new things much harder.

The other very very helpful thing in the toolmenu in Grasshopper is, that if you move your mouse over an entry in the list, you get a short description as a tooltip. Again, helps the newbie tremendously with finding the right node without first dropping it down, see what it does, delete it, rinse and repeat...

Oh, and now that the Mantra shaders seem to look up to par with other renderers, go GPU with it...  :-)

Cheers,

Tom

Edited February 8, 2017 by Thomas Helzle

[acey195]

First of all, I'm going to make a request repeat I guess:

adding 2 VEX functions to check and set edge groups.

I know there are "vertex groups" functions, but they don't work with the native group nodes or almost any other SOPs.

11 hours ago, LaidlawFX said:

Ok soo... lol... now I need to deep dive into this not so theoretical system. Mostly for humor sakes...

.....

This is turning into an RFE beyond a rant now, lol.

For the launcher as you describe it, you would need a massive team to be worth all the testing processes.

If you omit the potential HoudiniEngine users, you would need at least 10 Houdini specific artists for this kind of stuff be worth the hassle I think.
Especially if you are working with daily testing and version building (in the terms of games) for FX there may be less constraints in that regard though, not sure.
In fact, I do not really have a good idea at all, of how many Houdini people would be generally working on a large movie project.

But yeah totally possible to do, even without direct Sesi support I guess.

 

[Guest tar]

Has anyone found a way to increase the size of those onscreen viewport sliders? I want non-delicate large controllers in the viewport

Edited February 9, 2017 by tar

[MrScienceOfficer]

Drag and Drop nodes onto shelf tools, to call the tool with that node in the kwargs dict.

[JDee]

Overlay network view right on scene viewport option
And just one hotkey to hide/unlock it...
 

Edited February 11, 2017 by JDee

[Pazuzu]

More love to the small scale fluid pipeline (Rewriting of SPH solver and related microsolvers)

New methods for the gas pipeline (incompressible Schrödinger flow for example)

 

[Guest tar]

Nuke-like way to change the parameter values with keyboard- you can move the value up and down with the up and down arrow keys

[jonmoore]

3 hours ago, marty said:

Nuke-like way to change the parameter values with keyboard- you can move the value up and down with the up and down arrow keys

Damn fine FR.

It's the simple things in life that make the most difference.

[McNistor]

9 hours ago, marty said:

Nuke-like way to change the parameter values with keyboard- you can move the value up and down with the up and down arrow keys

Interesting. Do you have to select the digit you want to increment first or is it based on the cursor's position? If it's the latter like it appears to be, it's quite useful.

Edited February 14, 2017 by McNistor

[jonmoore]

5 hours ago, McNistor said:

Interesting. Do you have to select the digit you want to increment first or is it based on the cursor's position? If it's the latter like it appears to be, it's quite useful.

It's simply based on the cursor position.

And funnily enough it's always reminded be of the value ladder as an interaction model. It functions in much the same way and answers the same UI challenges but for mouseless interactions.

[McNistor]

@jonmoore Awesome. WOuld like to see this in a future Houdini version.

 

[sebkaine]

On the rigging side, i would also add the need of a new simple / fast / efficient / predictable cloth solver that we could link with our rigs.

Something simple derivated from pop in a similar fashion of the granular solver.

FEM cloth is still not on par with nCloth. And doing that sort of things in Maya is really an advantage over H.

https://www.cgcircuit.com/course/skinning-with-ncloth

Edited February 14, 2017 by sebkaine

[eetu]

1 hour ago, jonmoore said:

It's simply based on the cursor position.

And funnily enough it's always reminded be of the value ladder as an interaction model. It functions in much the same way and answers the same UI challenges but for mouseless interactions.

And with mouse as well - mouse wheel adjusts the digit under mouse cursor in an identical way. A small ladder superpositioned on the number itself.

[symek]

On 7 lutego 2017 at 0:33 AM, marty said:

Metal/Vulkan viewport shaders to free up CPU compute time.

I really hope they won't rewrite viewport again... last time it took a couple of years to stabilize it. Fortunately OpenGL4.3+ has all (most?) features to work with the same speed as Vulcan. 

[malexander]

46 minutes ago, symek said:

I really hope they won't rewrite viewport again... last time it took a couple of years to stabilize it. Fortunately OpenGL4.3+ has all (most?) features to work with the same speed as Vulcan. 

No plans to rewrite the viewport. We've had a strong foundation since H14, and we've built upon that with each version. H16's viewport is no exception. There are parts that need updating (as always), but that's about the extent of it.

I interpreted "use Vulkan/Metal shaders" to mean "use compute shaders to move computation from the CPU to GPU" which is a valid request for some instances (like light baking for volumes).

[Guest tar]

@malexander thanks! Also are there any advantages to doing the whole viewport in Vulkan/metal for a DCC, like it can be for games? I haven't been able to read a clear answer anywhere. 

@eetu option/alt LMB drag L/R on the digit too to change.  

Overall Nuke's way to change values feels pretty fast and accurate, and, would be a nice backup for when Houdini's viewport ladder doesn't work properly - it can get vertically offset on MacOs when screens have different resolution, and, which one is set to be the primary one.  

 

 

 

[malexander]

33 minutes ago, marty said:

@malexander thanks! Also are there any advantages to doing the whole viewport in Vulkan/metal for a DCC, like it can be for games? I haven't been able to read a clear answer anywhere.

There are, primarily in reducing CPU usage by the driver and more easily allowing threading, but currently this is vastly outweighed by the cost of managing everything, including main and GPU memory, object transitions, lifetimes, usages, etc. Basically the app now does the work of the high-level driver. Metal is slightly more helpful, but has its own shading language (facepalm) and of course is platform-specific.

Vulkan's main benefit to Houdini would be the ability to precompile all the shaders to bytecode,  avoiding all the GLSL compiler parsing errors that are platform/driver/vendor specific. But that even has a few gotchas, such as being unsupported on MacOS, which is where the lion's share of shader issues seem to be.