Houdini 16 Wishlist

[Guest tar]

On 6/2/2016 at 5:38 AM, malexander said:

What basically happens is that the viewport object that encapsulates the node's viewport data becomes de-synchronized from the node, and doesn't receive notifications anymore. Then it just sort of sticks around forever.

Wondering if this has changed in H16 with the rewritten Node graph.

[Gilly123]

post it notes on the node parameters or a note text section.

when notes are present within a node, some sort of visual que to signify their presence.

Unless of course, this was already requested 40 pages ago, it was a passing thought and I didn't want to waste it, if it has any merit.

Using the post it notes in the node layout view can sometimes be vague if you want to explain something, leave a setting note, you have to note the node the setting was for. 

[bonsak]

Keyboard shortcuts for navigation between the different contexts.

-b

[Matt_K]

54 minutes ago, bonsak said:

Keyboard shortcuts for navigation between the different contexts.

-b

+1

[sebkaine]

this might sound iconoclast, but the concept of prebuild context is kinda legacy imo. i personnally always use custom subcontext.

starting a houdini scene at root level /  and then let the user populate the htree like he want would be nice.

at least having the choice to not have the default context and start with a void scene would be cool.

[pezetko]

12 hours ago, bonsak said:

Keyboard shortcuts for navigation between the different contexts.

-b

Try attached tool, unpack it to your %HOME%/Houdini 15.5 folder (readme is included). It adds custom shelf with 5 buttons. You can reassign keyboard shortcuts to those tools if you don't like default ones (stored in HotkeyOverrides). I posted it long time ago on sidefx forum. It was written for Houdini 14, but it's working in 15.5.565 too (tested under Windows with default desktops).

 

10 minutes ago, sebkaine said:

this might sound iconoclast, but the concept of prebuild context is kinda legacy imo. i personnally always use custom subcontext.

starting a houdini scene at root level /  and then let the user populate the htree like he want would be nice.

at least having the choice to not have the default context and start with a void scene would be cool.

That sounds nice, but in bigger team with small number of pipeline programmers this is not the best way to go unless you are delivering only final pictures or caches exclusively.

Having pre-build contexts and basic set of rules like: objects go always only to /obj/, materials only to /shop/, ROPs only to /out/ helped us to run quickly projects with team of people who had minimal or zero experience with Houdini without any serious problems or slowdowns and with only simple or no pipeline scripting.

I think you can imagine the mess if you have to finish or fix multiple scenes from different users you never seen before just right before deadline. And if artists would be allowed to put nodes in every context they personally prefer instead to standardized places it would became a long job. E.g. having materials all over different contexts like having some materials inside shop sub-context inside sop sub-context in obj context, another in shop sub-context in cop2 context and so on. Also possibly having name conflicts as some materials are different version just copy pasted and unlinked from originals or even modified. Or having some mantra rops in /out/ context and other in /obj/ropnet/ or in worse places that... That wouldn't be nice.

Naturally I would end up with something similar that is already there. I think good example is DNegTV presentation about they Bogeyman workflow with Clarrise. Having pre-build those standard/common/uniform places to put stuff is great in bigger team where time is rare.

 

Yes, now I would like to delete some of those contexts as I don't use them on some projects at all. And I can see that maybe sometime in very far feature we would see a single contextless environment. But having the "forced" naming means I can open old assets from one project and materials from different and they will be internally linked as basic context names are still same between versions. I hope that till that happen we figure out some strong future proof convention for placing and linking all data.

 

 

pz_switch_context.zip

[bonsak]

20 minutes ago, pezetko said:

Try attached tool...

Hey! That's great. Thanks a lot.

-b

[LaidlawFX]

55 minutes ago, pezetko said:

That sounds nice, but in bigger team with small number of pipeline programmers this is not the best way to go unless you are delivering only final pictures or caches exclusively.

Having pre-build contexts and basic set of rules like: objects go always only to /obj/, materials only to /shop/, ROPs only to /out/ helped us to run quickly projects with team of people who had minimal or zero experience with Houdini without any serious problems or slowdowns and with only simple or no pipeline scripting.

I think you can imagine the mess if you have to finish or fix multiple scenes from different users you never seen before just right before deadline. And if artists would be allowed to put nodes in every context they personally prefer instead to standardized places it would became a long job. E.g. having materials all over different contexts like having some materials inside shop sub-context inside sop sub-context in obj context, another in shop sub-context in cop2 context and so on. Also possibly having name conflicts as some materials are different version just copy pasted and unlinked from originals or even modified. Or having some mantra rops in /out/ context and other in /obj/ropnet/ or in worse places that... That wouldn't be nice.

Naturally I would end up with something similar that is already there. I think good example is DNegTV presentation about they Bogeyman workflow with Clarrise. Having pre-build those standard/common/uniform places to put stuff is great in bigger team where time is rare.

 

Yes, now I would like to delete some of those contexts as I don't use them on some projects at all. And I can see that maybe sometime in very far feature we would see a single contextless environment. But having the "forced" naming means I can open old assets from one project and materials from different and they will be internally linked as basic context names are still same between versions. I hope that till that happen we figure out some strong future proof convention for placing and linking all data.

 

The problem with your logic is that you could still define how people work within your studio. If all the context gain you are SOPs, DOPs, OBJs, OUT then you really aren't gaining much. You can easily replace this with shelfs, presets, custom startup environments no problem. The one thing it wouldn't simplify is the number of nodes in the tab menu, but the tab menu could easily be redesigned for this issue. Your thinking old school, think like Nuke. I'm throwing down the gauntlet on this, think outside the "context".

[sebkaine]

I see your point petr , prebuild context help to have a predifine layout on big show.

but i have to disagree, on big show the supervisor can define a :

- context layout convention

- node color convention

- name convention

build a template scene in lib ref folder, and each artist has to start from that.

actually any good nuke workflow work this way.

 

but you can define exactly How you wanna work, and you can avoid redudancy of useless ui element that you will not use in the show.

 

i am not saying context switching must be kill, but if you want to use them you have the ability to choose their

- type

- name

- number

[pezetko]

21 hours ago, LaidlawFX said:

The problem with your logic is that you could still define how people work within your studio. If all the context gain you are SOPs, DOPs, OBJs, OUT then you really aren't gaining much. You can easily replace this with shelfs, presets, custom startup environments no problem. The one thing it wouldn't simplify is the number of nodes in the tab menu, but the tab menu could easily be redesigned for this issue. Your thinking old school, think like Nuke. I'm throwing down the gauntlet on this, think outside the "context".

 

Maybe I'm bit of old school but actually I don't mind having single contextless environment. I would prefer that. And I would love to delete pre-build CHOP context without hesitation.

Actually I would like to be able to modify textures with COPs and CHOPs and fetch them to SHOPs/VOPs and link them directly next to OBJ or SOP context in single multi-threaded network without having to jump between "subcontext" like I have to now. Yes from ui point of view Tab menu would require a huge amount of smart stuff to be effective to use and not to be cluttered. Katana tried to solved that by its "progressively filtered zoom out menu" (I don't know if they have some naming convention for that), 3dsmax has quad-menu, Maya has gesture circular menus etc... I don't know what would be best for Houdini.

I suppose that Houdini also pulls out data in a different way then Katana or Nuke graf does as these applications results usually in single output while in Houdini we can do a lot of stuff that are not connected at all. But it seems that all of them are merging in term of target functionality with just a bit of different specialization. In Nuke I don't like that you have to have "convertors" to switch from 2d to deep or 3d and back. Also I don't like they tried to solve cluttered tab menu with removing aliases. Having to search for opposite operation is not intuitive to me and using that left button pane with sub-menu is too old school to me

But mainly I was trying to point out that those pre-building contexts helped us to run a bigger shows quickly with limited knowledge, zero pre-production time and almost zero pipeline scripting or "supervisor" intervention into 3d pipeline.

I'm not defending separated contexts as only best possible workflow as it's clearly is not and it was evolution and extension. I see basic pre-build contexts as nice start for new users to get familiar with this unique software and to be able to read other scenes easily before moving to customization for their pipelines and workflows.

 

 

 

[LaidlawFX]

47 minutes ago, pezetko said:

Maybe I'm bit of old school but actually I don't mind having single contextless environment. I would prefer that. And I would love to delete pre-build CHOP context without hesitation.

Actually I would like to be able to modify textures with COPs and CHOPs and fetch them to SHOPs/VOPs and link them directly next to OBJ or SOP context in single multi-threaded network without having to jump between "subcontext" like I have to now. Yes from ui point of view Tab menu would require a huge amount of smart stuff to be effective to use and not to be cluttered. Katana tried to solved that by its "progressively filtered zoom out menu" (I don't know if they have some naming convention for that), 3dsmax has quad-menu, Maya has gesture circular menus etc... I don't know what would be best for Houdini.

I suppose that Houdini also pulls out data in a different way then Katana or Nuke graf does as these applications results usually in single output while in Houdini we can do a lot of stuff that are not connected at all. But it seems that all of them are merging in term of target functionality with just a bit of different specialization. In Nuke I don't like that you have to have "convertors" to switch from 2d to deep or 3d and back. Also I don't like they tried to solve cluttered tab menu with removing aliases. Having to search for opposite operation is not intuitive to me and using that left button pane with sub-menu is too old school to me

But mainly I was trying to point out that those pre-building contexts helped us to run a bigger shows quickly with limited knowledge, zero pre-production time and almost zero pipeline scripting or "supervisor" intervention into 3d pipeline.

I'm not defending separated contexts as only best possible workflow as it's clearly is not and it was evolution and extension. I see basic pre-build contexts as nice start for new users to get familiar with this unique software and to be able to read other scenes easily before moving to customization for their pipelines and workflows.

Yeah the contexts evolved from Houdini being different software packages that were band-aided together and then fully integrated over the years. It could be possible that a good default for the context less environment is a modification to defaultscene.cmd with a simple layout with lights, a camera, a render node and some geometry, and if you don't want that you can easily modify that file or shut it off from a ui or environment variable(We have preset options like that). Maybe SideFX could just add more clear documentation on how to modify the environment so you could bang, bang set up a custom environment with no prior experience. 

For a context-less environment I believe SideFX would maintain backwards compatibility. I can't imagine them just flipping a switch and not being able to not go backwards, unless it was a product re-brand i.e. Prism to Houdini. I can imagine though the intro of a new context, a global one, as an option at first then switching to it by default in a later build, i.e. the new geometry spreadsheet. Only in the new global context would you have this new chaos. I do think Side FX could help itself with an update to their nodes that would help everyone, especially in this vein the for loops being a start. The UI for nodes does not need to be rectangular anymore as nuke has shown, and you can extend this to color and shape. Lights, Cameras, Sops, Dops and Vops could all be of different style and colors in their nodes, think of icon-ifying the nodes so they resemble their context or use better. They would have to do a purge at some point for the nodes, hiding duplicates (duplicate and a copy, or delete and blast), and one hit wonders. Turn any attribute creation nodes like the point/vertex/primitive sops into attribute wrangle/vop presets perhaps both? 

Maybe as a starter block for context less you start from one area and use managers for dops and vops, that have inherently different flows of nodes. I personally think flattening to the sop context would be the best starter block, and merging cops, chops, obj, and out to that level would be nice.

 

[Guest tar]

It would be great to hear more details about the node graph in H16, such as;

A better way to navigate the long node chains created when modelling. i.e. jump up/down n number of nodes, or, jump up/down similar types of nodes as you'll do a ton of blasting but want to see it before / after etc.

A big warning flashing 'idiot' that you are trying to select/edit polygons on a polysoup, again...  gains importance when sending meshes around with alembic!

Indicators on the nodes of the type of geo. ala Nuke when it has 'views', channels, animation etc.

A permanent window showing MMB info for the selected node

[MrScienceOfficer]

7 hours ago, marty said:

A better way to navigate the long node chains created when modelling. i.e. jump up/down n number of nodes, or, jump up/down similar types of nodes as you'll do a ton of blasting but want to see it before / after etc

It would be sweet if that was like a really long slider that sits in the little operations control panel at the top of the viewport.  Like the way undos work in ZBrush.  It would be really awesome if it could combine undos for the nodes parameters too, basically filtering out things like moving nodes and changing names, but keeping anything that has an effect on the geometry.

[mestela]

Re context-free interfaces, a tricky problem is making it clear why some nodes can be connected and others can't. I'm reasonably comfortable with Nuke, but still get frustrated when doing hybrid 2d/3d comps and try to guess what nodes go together. Usually makes sense in hindsight (node shapes, connector labels, general logic etc), but can be very tricky to navigate for new users.

And that's just 2 contexts. Throw all of houdini's contexts in the mix (obj, sops, dops, shops, vops, chops, cops, rops), thats a minefield of potential confusion. Don't get me wrong, I'd love it too, but would require some thinking to do it right. 

[Guest tar]

Another issue with Nuke is dual use nodes, that work in both 2d and 3d streams. e.g. Framehold wont always connect to a 3d node, the top part seems to be needed to first connected to make it 3d compatible, you can then connect up to it. Framehold is used to hold an animated camera (3d) or a frame (2d). 

In Nuke the node just wont connect if it's the wrong type/context; would that work for Houdini?

[sebkaine]

19 hours ago, mestela said:

Re context-free interfaces, a tricky problem is making it clear why some nodes can be connected and others can't. I'm reasonably comfortable with Nuke, but still get frustrated when doing hybrid 2d/3d comps and try to guess what nodes go together. Usually makes sense in hindsight (node shapes, connector labels, general logic etc), but can be very tricky to navigate for new users.

And that's just 2 contexts. Throw all of houdini's contexts in the mix (obj, sops, dops, shops, vops, chops, cops, rops), thats a minefield of potential confusion. Don't get me wrong, I'd love it too, but would require some thinking to do it right. 

Well i was not very clear in my previous post matt.

I do want to keep the context logic SOP / COP / POP / SHOP / ROP.  Context are indeed great and we just need to keep them exactly like they are.

What i am questionning is the fact that when you open Houdini you have a layout of default context that is there and that you can't modify.

 

For some it is not a problem because they still put their COP in COP / their SOP in SOP / their SHOP in SHOP etc ...

But some other users doesn't respect this initial context layout and tend to work only in SOP and build their different context in there.

 

The first method give a good basic canvas to start to work with , like petr has very well describe.

The second give you total flexibility on how you organise your scene.

 

basically default context are 

- just following root folder in the htree /

- define by a type and a set of node according to this type

 

@: /          Type : undefined

@: /obj/    Type : scene 

@: /img/    Type : compositing

@: /ch/      Type : motion fx

@: /out/     Type : outputs

@: /shop/   Type : shaders 

@: /vex/    Type : Vex builder    

 

my point is that having this context layout describe in a table in the houdini preference that you can modify with the ability to control exactly what you want for exemple:

Ex 1:

we can disable all default context and set only :

@: /          Type : Scene

 

or Ex 2: 

we can define additional context :

@: /                 Type : undefined

@: /model/       Type : scene 

@: /rigging/      Type : scene

@: /animation/  Type : scene

@: /lookdev/     Type : scene

@: /lighting/     Type : scene 

@: /sfx/           Type : scene

@: /comp/       Type : compositing

 

or Ex 3: 

just use 4 context instead of all 

@: /          Type : undefined

@: /obj/    Type : scene 

@: /img/    Type : compositing

@: /out/     Type : outputs

@: /shop/   Type : shaders

 

or Ex 4:

keep all by default :  

@: /          Type : undefined

@: /obj/    Type : scene 

@: /img/    Type : compositing

@: /ch/      Type : motion fx

@: /out/     Type : outputs

@: /shop/   Type : shaders 

@: /vex/    Type : Vex builder    

 

The idea is to find a generic way to define:

- a flexible way to organise our scene

- by keeping the ability by default to keep the old school context layout

- by giving the ability to totally modify it according to our needs.

 

But the fact that i never use those context :

@: /img/    Type : compositing

@: /ch/      Type : motion fx

@: /out/     Type : outputs

@: /shop/   Type : shaders 

@: /vex/    Type : Vex builder 

and that houdini has a rigid approach regarding this , is not perfect imo.

 

it could be the same thing but with an additional layer of flexibility.

Cheers 

E

 

 

 

 

Edited August 21, 2016 by sebkaine

[Yon]

On August 17, 2016 at 10:18 PM, Gilly123 said:

post it notes on the node parameters or a note text section.

You can add a string from edit parameter interface

[animatrix]

Wrt unifying contexts I posted my ideas on the SESI forum before:

https://www.sidefx.com/forum/topic/38948/

 

I think it's unlikely that it will happen but differentiating node types for the types of data they support can easily be done using intrinsic node, input, wire colors. So you could have a geometry with some image data and some fields i.e. density, vel, and an operator like Volume Blur would only work on the volume data, and signify this by coloring its input wire using a certain color.

That way you can tell only volume data is filtered using this node.

There is so much that can be done with this easily.

[Guest tar]

A nice upgrade would be to have curated Desktops. Say have a top modeller, animator, TD etc set up the workspaces and viewport options. Shipping them as defaults is much better than hunting them down.

[pezetko]

Just a bit more about unified (context-free) network (maybe this could be just a joke than anything else) :

I think you can recognize this (and it's clearly not the best piece of the procedural node based system out there):

And this is almost empty scene...