RGaal

alexeyvanzhula1984

I created a tool on the shelf, copied your code into the script and ... nothing happens when you press it. Both versions of the code.

Ah, I get it. You have to press the hotkey constantly. I thought the flag was set after clicking the mouse. But it turns out that you have to press the hotkey, then what's the difference from the "r" hotkey?

RGaal
Ah, I get it. You have to press the hotkey constantly. I thought the flag was set after clicking the mouse. But it turns out that you have to press the hotkey, then what's the difference from the "r" hotkey?

R key:
1. Hover the cursor directly over the node
2. Press R
3. Click on node
4. Release R
Result: The node's display flag will be activated.


Script:
1. You don't need to hover the cursor exactly over the node
2. Tap hotkey
Result: The node will become active (selected), with its display and render flags enabled.

Maybe I'm missing something, but I just want to pick the colors correctly.
It's driving me nuts having to use sites to convert hex to RGB and then RGB to ACEScg.
On top of that, it would be so cool if we could sample a gradient from an image, like in Substance Designer, and paste it directly into the color ramp.

https://www.rapidtables.com/convert/color/hex-to-rgb.html [www.rapidtables.com]
https://acescolorspace.com/rgb [acescolorspace.com]

This is unhealthy

Adding one more small usability item. Dropdowns in parameter editors. In most software I can click the dropdown list and use arrows up and down to select on the fly while updates are made. From a user perspective it’s very easy way to experiment with settings. In Houdini this process seems to be much slower as I have to click, open the drop down, select, repeat.

alexeyvanzhula1984
1. Stabilize Python States.
2. Fix the bug where viewport camera transformation gets disrupted if you start navigating in the viewport and release the mouse button over a Python panel. This doesn’t happen when releasing the mouse button over a native Houdini panel.
3. OpenSubdiv isolines. No, don’t add them. it’s unnecessary as it is.
4. Completely rewrite Edit SOP.
5. Finally start improving TopoBuild.
6. Fix the incorrect display of MatCaps.
7. Make all icons consistent in style.
8. Fix unexplained crashes, such as when dragging shelf tools.
9. Eliminate the viewport performance drop when dealing with a lot of self-intersecting polygons.
10. Improve gizmo manipulators.
11. Merge pivot mode with detach handle. Why have two ways to adjust the pivot?
12. Refine the hotkey system to a functional state.
13. Redo PolyBevel, which currently handles angles poorly.
14. Allow transform manipulators involved in Python states to switch the mode with T, R, E. Currently, pressing the hotkey activates Edit SOP state.
15. Enable selectors involved in Python states to switch component types using hotkeys 2, 3, 4. Currently, pressing the hotkey activates the selection state.
16. Improve geometry caching in the Sculpt tool. It’s currently difficult to continue modeling after sculpting as components may stop being selectable.
17. More native multithreaded nodes instead of wrapping numerous attribute wrangles in assets.
18. Provide better default material display settings in the viewport.
19. Eliminate conflicts with Python UI objects. A simple change of panel type can lead to Python errors.
20. In the Sculpt tools's Move mode, the Ctrl+LMB combination should move the geometry along the normal, instead of the meaningless reverse movement.

Alexey - assuming that for most of these fixes/bugs/small enhancement you created RFEs and/or bug reports?
Seems that many issues and requests are around hotkeys and python states.
Could you elaborate on number 19, 17, 10 and 4?

I wish that SideFX, in the next major release of Houdini, would concentrate on Quality of Life, UI/UX improvements, and extending current tools rather than introducing new ones. It's almost complete anyway.

So... of course, UI reinvention and a redo using the newest technologies that, for example, allow for dynamic rescaling, hiding, extending, UI animations when needed, etc.

The rebranded main UI should be flat-designed, with minimalistic yet communicative icons that don't distract while animating, with proper spacing and alignment (which is a really important part of design—managing negative spaces for better readability). Clear type fonts that don't look like they're from MS-DOS xD—there are quite a few good inspirations, like, for example, Unreal Engine 5 or NVIDIA Omniverse.

• UI should be designed with animation in mind, so it should contain all the elements that are in MAYA, Cascadour, and yes... in Blender too, but all more coherent and ergonomic.
  
  
• Introducing time manipulation UI (something like bars in Adobe AE or other video editing software) so new features oh Houdini can be made, for example: modeling in time (like Sculptron from OTOY, making possible to quickly tweak deformed meshes or adding some muscle tension or facial expresion without simulating it. Just tweaking by hand
  
  
• Catching up with animation-based features like pose library (where you can blend between poses, not only hard copy-paste. This should work like morphing). That should be state of the art.
  
  
• A central search box where all those presets from tabs could sit, with nicer explanations. There should be something like a new asset browser or something (also with new UI and ergonomic functions that are very important for the tired eyes of artists who sit and watch it all the time).
  
  
• Camera sequencer (based on the new UI with nonlinear time operations), something like compositing footage clips together in Davinci Resolve—with transitions and blending between layers using Bezier curves.
  
  
• NEW animation curves editor. IT MUST BE EASY to work with for animators!
  
  
• Redone gizmos and 3D handlers to modern standards.
  

Basicly concentrating on User Interface with USER in mind

--

LukeP
Alexey - assuming that for most of these fixes/bugs/small enhancement you created RFEs and/or bug reports?
Seems that many issues and requests are around hotkeys and python states.
Could you elaborate on number 19, 17, 10 and 4?

No, it's not just about Python states and hotkeys. Read it again. It's about the program's flaws. In fact, the list can be significantly expanded.

4. Edit SOP: This node is severely outdated and needs a complete overhaul. First of all, why does it even have a Sculpt mode when we now have a "cool" dedicated sculpting tool? I know why they didn’t remove it, but I’d rather not say anything. Secondly, its symmetry function is terrible when it comes to transforming points near the symmetry plane. Symmetry settings should be preserved for future uses of the tool. And in general, the node is outdated. Not too long ago, they just added the local transformation function, and that’s about it.

10. Gizmo: Working with gizmo is terrible. You often end up selecting the wrong handle and adjusting something you didn't intend to, especially when other manipulators are involved. For example, with the Box node, you might want to drag an axis to move the box, but instead, you end up grabbing a face and scaling the cube. Additionally, configuring manipulators requires way too many steps. I won't go into all the nonsense involved in setting up manipulators, but I suggest you look at how it's done in XSI. I've never seen better gizmos than those in XSI.

17. SOP Nodes: For about the past 5-7 years, SideFX has preferred to build new nodes by packaging existing ones into assets rather than creating native C++ nodes.

19. UI Conflicts: As soon as the developers started trying to enhance the UI/UX with Python and Qt, a lot of bugs appeared, where different subsystems conflict because not all critical situations are accounted for. This is why there are so many issues with HUD sliders and Python states. For example, launch the Curve tool or any other Python state tool, then press Alt+2 in the viewport to switch the panel type to the node editor. You'll see an error. There are many such issues. Before these "Python UI/UX improvements", everything was really stable.

Really good and constructive lists so far. Truly hoping that SideFX is listening here and taking notes for all the listed items as backlog items, fixes, enhancements and future big ideas.

Houdini positions itself as a parametric program, but there are fundamental flaws that greatly devalue this advantage.
Nodes work with point numbers and your tree will work if the numbering of points does not suddenly change higher up the tree, right? Well, this is an obvious fact. It is clear that changing the number of points somehow changes the numbering. And we use groups to avoid numbers, which allows us to keep the node running regardless of the number of points and expect that if the number of points and topology do not change, then the numbering should not change. Logically. And so the moldy edit node comes on the scene, which does not save the names of the groups, but saves the point numbers to its cache. And this node is always automatically called when the points are transformed. So if your numbering changes, then the presence of groups will not save you, because the edit node does not care about groups, it will write the point numbers to its cache and break the entire tree.
The second participant is boolean, in which the numbering of points is constantly changing chaotically. You have subtracted two objects, move the object and the number of points does not change and the topology is almost the same and you do not expect any trouble, but the numbering of points can change chaotically. This means that your tree will break down below. You expect from the promised parameterization that if you do not change the number of points, you will be able to do a little (a little!) adjust the objects to find the optimal view, but nothing will work, because the numbering changes randomly and everything tied to the point numbers breaks. But we have groups, let's work with groups! And then Edit node comes out- hold my beer - and destroys the benefit of the bands. Bingo! Two very important and mandatory modules in modeling - boolean and edit - are guaranteed to reset parameterization and turn it into a bad version of Blender. Forget about parameterization. SideFX, please pay close attention to this! You have destroyed your main advantage with your own hands.
Also, one of the reasons for using a boolean value is to get the correct interior angles, because the bevel node is moldy even more than the edit node and creates terrible angles on the plane and interior corners on mesh. You solve this problem with a boolean - and you get an even bigger problem because of the numbering madness. Bevel, Boolean and Edit are the three horsemen of the apocalypse.
Why not save the numbers of the points of object A that are not affected by the boolean ? And make the algorithm somehow number the other points equally?
I was hoping to see improvements at 19.5, 20, 20.5 and now I'm hoping for 21.

Improve the interface for the ONNX nodes, maybe just make it a python text interface.
Currently not usable.

Add Miro like Network View for Management of Projects so we can start in Houdini for planning.

RETHINK PYTHON COMPLETELY -- cannot really create anything cohesive with the UI experience.

Create a python notebook/ vex notebook for literate programming and reference development
Add .venv to the Python SOPs
Add Python in Copernicus
Add run button for Python SOPs (not auto-run by default)

Handle Python imports and variables so that you declare them once and not in every node.

Add other LLVM backend to VEX other than just CPU, could VEX be have a GPU backend like JAX?

Surface Bullet Solver RL features from already included lib.

I have a long wishlist which I'll be posting later, but for the time being my only request is to:
- Fix the bugs in Python States which have been bugging us ever since Python states have been introduced. It's much better now, but errors still do happen.
- Finish all the betas. H20.5 is a great release (Coperniucs!), but at the same time it's the most buggy and crash prone Houdini release I have experienced since Houdini 13.

I know I'm speaking for myself, but I don't need new revolutionary tools in H21. Please polish what is already present in the program.

ajz3d
\ H20.5 is a great release (Coperniucs!), but at the same time it's the most buggy and crash prone Houdini release I have experienced since Houdini 13.

Still, the most glitchy version was 20. It crashed every minute and I couldn't use this version at all until 20.5 came out. So I jumped from 19.5 to 20.5. I remember version 20 with horror. 20.5. is incredible stability compared to 20.

RGaal
Nodes work with point numbers and your tree will work if the numbering of points does not suddenly change higher up the tree, right? Well, this is an obvious fact. It is clear that changing the number of points somehow changes the numbering...

I mean it's how Houdini works... if one can invent an algorithm to automatically fix Edit SOP after you make arbitrary changes on upstream nodes, I'm sure SideFX will happily buy it. With millions of dollars. It would be the most revolutionary thing in the world of DCC.

raincole
With millions of dollars.

I give away the idea for free. The same thing that the transform node does, for example, and any other node that works with groups. When cooking, it takes the group name and takes points from it. And there are no problems with changing the numbering higher up the tree. All nodes do this except edit. What prevents edit from saving the group name if it is entered and using it? Are you afraid of an error that if the group disappears, the node will return an error? Well, now it is useless and breaks the tree.
Okay, here is another way - enter a local frame and everything that is attached to it into the transform node. And the edit node will not be needed in 90% of cases, except for the point slide. We have a separate sculpt, a separate peak, there are software options, they all work with groups, we will add a transform with a local frame, which works with groups without problems. And for edit there will only be a slide of points, which it does so badly that it would be better to throw it away completely and make a normally working Slide node with snapping and all sorts of goodies.

raincole
fix Edit SOP after you make arbitrary changes on upstream nodes

This is an ancient RFE, something like: select using fixed attribute indices instead automatically re-rolled indices.

For example:
- make a box
- append a pointwrangle, with i@ppt = @ptnum;
- Edit: move point 2
- prepend a Bevel, it breaks the indended edit
- tell Edit to move ppt 2: it will move all points prevously known as point 2

My biggest wish:

No more need for this Labs tool


Having to reset the viewport every nth mouse click

Adding some more after spending more time with H20.5... Echoing some of the above thoughts...

1) Stability stability stability - I've spent 15 min in Solaris and logged 3 defects... obvious stuff, like material linked lists not updating properly (rules). Core functionality.

2) Errors... I'm honestly sick and tired of the console or others popping up errors. Was working in Solaris. With material linker mostly... literally must have seen over 30+ errors. And of course random crashes, but guess what - most of the time the fatal / segmentation faults seem to be not reproducible, so it goes nowhere...

3) Attention to detail. Attention to user experience... thinking through best workflows... while this has been getting better, Houdini is opposite of apple... Apple obsesses with user experience. I'll leave it at this.

RGaal

Carlos_Rivadulla
Procedural NURBS Modeling. Once someone in the world develops such a thing, even AI will have a hard time surpassing it. Furthermore, parametric modeling is less destructive than polygonal, minimizes manual tweaking which is closer to Houdini's idea. A workflow example would be: convert to nurbs > bevel > convert back to poly, this way u would steal the most envied feature of Plasticity (which is the NURBS beveling). Another killer feature to start with would be nurbs lofting and bridge edges for surface modeling.

You will be surprised, but existing NURBS nodes already allow you to solve this, you need to study them in more detail. But the "problem" is that in most cases skillful use of subdiv turns out to be equivalent to nurbs, but simpler, cheaper and faster.

Edge Flow SOP like the one from Tom Jerry - these plugins are available in the modeler and separately.
Limit Bevel (plasticity) - this is easily implemented by conventional means. The bevel has other problems in the form of inaccuracy, mismatch of the bevel of the same angle on the curve and mesh, lack of a proportional bevel, by radius and a HORRIBLE bevel of the inner corner.
Extend Sheet Trim (Plasticity) - unclear.
Project Curve Curve (plasticity) - easily solved through 2 extrudes + boolean + converter, wrap in hda, or extrud + ray.
Wrap Face and Unwrap Face SOPs (plasticity) - This makes a vex out of 2 short lines. Save as a wrangle preset and enjoy!

Sketchup Extrude

- Modeler or extrud + boolean.

As you can see, a lot already exists, but you do not know how to use it.

Could you elaborate on these solutions please?

Could someone explain what this Edge Flow SOP is?