Jump to content

Houdini 17 Wishlist


LaidlawFX

Recommended Posts

Not sure if there is a better place to draw attention to this, but more compile friendly SOPs
For our pipeline in particular:

-Sort, for when you want to get the point in a certain group (or connectivity class) with the lowest or highest float value (and you can't use http://www.sidefx.com/docs/houdini16.0/vex/functions/findattribval)

-Clip, the boolean SOP already works, so the clip probably should too. :)

-Ends, with the new amazing smooth SOP, converting polygons to open (unroll) and back can be used to smooth the outer border of shapes (when shared edges are removed)

-Triangulate2d, related to the previous one; in addition, tetrahedralize already is compilable, but can't create convex shapes (when the input doesn't have volume)

-Findshortestpath, I can understand if this one is more/too complicated.

Not sure if there is a place where Sesi lists their current compilable SOP priorities...
If there is, please let me know!

 

Edited by acey195
added context and more SOPs
Link to comment
Share on other sites

6 hours ago, acey195 said:

Not sure if there is a better place to draw attention to this, but more compile friendly SOPs
For our pipeline in particular:

-Sort, for when you want to get the point in a certain group (or connectivity class) with the lowest or highest float value (and you can't use http://www.sidefx.com/docs/houdini16.0/vex/functions/findattribval)

-Clip, the boolean SOP already works, so the clip probably should too. :)

-Ends, with the new amazing smooth SOP, converting polygons to open (unroll) and back can be used to smooth the outer border of shapes (when shared edges are removed)

-Triangulate2d, related to the previous one; in addition, tetrahedralize already is compilable, but can't create convex shapes (when the input doesn't have volume)

-Findshortestpath, I can understand if this one is more/too complicated.

Not sure if there is a place where Sesi lists their current compilable SOP priorities...
If there is, please let me know!

 

I think it's been said that you should send them an email if you want something verbified/compilable. If it's an easy fix you might even be lucky and get it in a daily build. 

  • Like 1
Link to comment
Share on other sites

19 hours ago, marty said:

break up the AddSOP into different nodes just like the way the group node was.

Agreed.

When I first started using H16, the break up of the Copy and Group SOP's used to irritate, but six months in, they're second nature in use. More importantly, it makes far more sense to artist's new to Houdini.

Link to comment
Share on other sites

23 minutes ago, jonmoore said:

Agreed.

When I first started using H16, the break up of the Copy and Group SOP's used to irritate, but six months in, they're second nature in use. More importantly, it makes far more sense to artist's new to Houdini.

As regards the AddSOP, here (link) 24:20, Jeff Wagner said, that maybe in a production build in 16.0 the AddSOP will be new. Quote "dramatic improvement into the Add SOP, RnD is thankfully taking look at that"

So you may watch production builds for that update.

  • Like 2
Link to comment
Share on other sites

I would enjoy if SideFX cared more about the UX of each node's parameter interfaces. Some of the new nodes are increasingly getting better. But there are soo many nodes that are just clunky to use. The conversation about the Add Sop highlights it. It's a very ugly UI for a nodes parameter lay out when you sit there and stare at it. Another reason to look forward to it being split up.

Having to make multiple clicks in a parameter's interface to get to the more common usage area of it is unclean. They need a heat map of each node's parameter use, and do some spring cleaning.

  • Like 2
Link to comment
Share on other sites

6 hours ago, pusat said:

There are many other kitchen and sink nodes that need to be broken up: Facet SOP, Primitive SOP, Fuse SOP, etc.

All for that too, but within reason. Going atomic in SOP's is great for those nodes that contained too many disparate tools. But monolithic nodes still have their place if all the tools and functions have a natural fit.

  • Like 2
Link to comment
Share on other sites

3 minutes ago, jonmoore said:

All for that too, but within reason. Going atomic in SOP's is great for those nodes that contained too many disparate tools. But monolithic nodes still have their place if all the tools and functions have a natural fit.

Yeah the old uber shader versus the multitude of shaders. :D I would say as long as those monolithic nodes have good ui design then i'd be ok with them keeping some. The add and delete sop are definitely good candidates for demolition. 

Link to comment
Share on other sites

The multi-input nodes nodes (Merge, MultiSolver or other) could have a button "Reorder list by the screen positions" ... reorder them by their x,y position in the network editor. Or: dragging the node with a hotkey pressed will make the nonselected connected nodes "straddle" apart, and selected nodes (wires) will go in between, swapping live. (btw dragging with left mouse button and holding right mouse button is easy, it may be used for this or other tweaks)

  • Like 1
Link to comment
Share on other sites

It would be nice if houdini 17 would make some improvements in modeling. Out of my head these features would be nice:

- Subdisvision creases must be preserved if you modify your object

- Elementar polygon opereations should not break your model if you insert the nodes in the middle of the node graph (yes sometimes this is not possible, but in the most cases the model should not break)

- Edge Flow, refine model with topology in mind

- Better selection tools (ring selection for example)

- Construction plane is ignored if you create box, sphere tube and so on, why ? If a CP exists everything should be created on it, otherwise you have to orient and move everything in place

- UV workflow in general, it is a pain sometimes (for example moving Vertices around, is difficult, because you have to grab all 4 of a point)

- make selection planar (should be implemented in a way which is fast accessable)

- Shell SOP like a Shell modifier in MAX.

- curves need bezier handles

- local mode in Edit SOP (e.g rotate  along the face normal). In Extrude SOP it is possible, but not in edit mode, why ?

- Isolate selection in an effective manner (yes there is a Visiblity SOP, but it is cumbersome to use)

 

Bug fixes:

- sometimes snapping does not work, snaps not to points

- sometimes  Start orientation on Edit SOP Handle does not work. It lets you select orientation but does not orient the handle

 

Improvement of modeling workflow

- sometimes you loose your selection after an operation, then you must select again

- tighten and speed up workflow in general. I have the feeling that sometimes there is too much fiddling around

 

And perhaps there will be some nice suprises. Would be cool.

 

 

 

 

 

 

 

Edited by Houdini7
Link to comment
Share on other sites

animation tools: motion path which allow to direct tweak curve in view port for better animation arc, improve view port perfomance because when enabling onion skinning the perfomance become very slow, drawing tools like doodle.

rigging tools: autorig with facial controls.

modeling tools: bridge tool improvement the current workflow of selecting the source edge/polygon and the selecting the destination edge/polygon it's real boring and time consuming, hope the improve this by allowing selecting both edge/polygon and apply bridge.

edge loop tool need improvement to allow symmetry adding two edge direct to the conner of the object, this will increase speed in modeling process like modo loop  slice  has many functions (symmetry ,free, uniform).

grooming: improve the perfomance when applying the hair gen it's like simulating ocean on my laptop the perfomance become very slow. due to this it's real hard to make grooming process hope the sideFX improve the perfomance of hair and fur tools.

Link to comment
Share on other sites

  • 2 weeks later...
On 2017/02/15 at 4:27 AM, malexander said:

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).

 

Hoping the viewport display of volumes can be multithreaded. A 1 billion voxel volume just sits on a single thread trying to redraw.

Link to comment
Share on other sites

  • 1 month later...
On 2017/09/24 at 2:59 PM, marty said:

 

Hoping the viewport display of volumes can be multithreaded. A 1 billion voxel volume just sits on a single thread trying to redraw.

The only thing that isn't multithreaded in the viewport is the calls to the GL functions to build buffers/textures and issue draw calls - because drivers have enough issues with single-threaded GL dispatch. I suspect what you're seeing is the single threaded texture upload/draw time.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...