When you are trying to deliver difficult shots under tight deadlines, it's the small things that make the difference in my opinion.

With all the major feature requests, they fall through the cracks. I thought it would be useful for SESI to have these listed in a single thread so they could potentially address these.

Import Attrib VOP is prone to errors
Some VOPs require element number (point, primitive, etc) to be connected for it to work (Import * Attribute VOPs), while others don't.

This can really go unnoticed if you are used to not connecting some VOPs. It would be nice if this was unified.

Feel free to list your small issues but make sure you log it first and include the ID# in your post please.

If your working with larger volumes it seems that jumping in or out of the volume vop causes a re-cook even though nothing is modified. This is pretty painful when trying to sculpt clouds.

A similar issue happens when you delete inputs or nodes inside a VOP network, the node itself fails to cook which forces you to go to outside, and then inside to get it to cook properly. This is a long standing issue.

Another thing that slows down workflow is when working inside a VOP network, if you add new nodes that do not change the result of the VOP network, it shouldn't trigger a recook.

For example if you add a new VOP that's not connected anywhere, it doesn't change the end result but initiates a recook. This takes a lot of time for heavy geometry/volume, which forces you to set updates to Manual.

I appreciate that you're trying to help and thanks for that, but posting bugs in a long thread in the forums is exactly the opposite of what we'd like you to do. Log BUGS and RFEs - that's what gets tracked and assigned to our programmers: Forum posts do not.

If we get the same BUG or RFE logged by multiple users, THAT would get our attention.

If you want to discuss bugs or rfe's in the forums that's cool - I'm honestly not trying to discourage that. What I'm trying to do is make sure people actually let us know in a BUG or RFE while discussing things in the forum. Not logging bugs is how things fall through the cracks.

Please, carry on - just log 'em as you go. Thanks!

And post the Support ID and/or the Bug ID tracking number to the post.

Pile on!

Thanks guys, I didn't mention it but of course I always log an issue or a feature request long before I post it here

Will update my posts to include the ID#s as well as inform that everyone should do that before discussing it here.

And for anyone who has missed Chris M's sticky about posting RFE/Suggs, I recorded myself submitting a bug using the web form!

https://vimeo.com/146724468 [vimeo.com]

The ID that Jeff is referring it will be given to you by support, if you submit via that web form. For example, this is the email I got back when I submitted that doc bug:

Side Effects Support Ticket: #31593

Hi Chris,

Thanks for pointing this our. I will alert our docs team.

Cheers,

Silvina
(#72580)

Note, the bug number isn't the same as the support ticket, so make sure you get the number that's inside the message, not at the top. In this case, the bug is #72580

Thanks, goldleaf! Hopefully it encourages more people to submit bug reports.

Regarding the example bug, it's extra confusing that the “scatter-” page is the *old* one, and “scatter” is the *new* one. Hopefully the new help system lets us finally fix that strange naming. They also both show up as just “Scatter” in the big list on the “nodes/sop/” page. Same with “polyextrude” and “polyextrude-” being “Poly Extrude” and “PolyExtrude” in the big list.

When you try to copy paste from a Non Commercial Houdini to Commercial, it prompts twice if you cancel

Installing new HDAs shouldn't create them in the scene

When you are working on heavy scenes and in the middle of improving a setup with a colleague, installing a new HDA automatically creates it inside a new geometry node taking you out of your network. I really don't know the reason behind this but it's very annoying and I never saw anyone who didn't complain about this.

Houdini often pans the network view so the nodes are outside the visible area
I don't have a repro case but this happens a lot. I am sure people would vouch, I see it daily in colleagues machines. Generally it happens when you open a new scene or go into a new network you didn't go in before, but has nodes.

Snippet VOP that shows its code should not prevent panning, zooming inside the network editor (3 years old)

RFE: Ability to restore network editor's zoom to default (3.5 years old)
My biggest request of all.

Installing new HDAs shouldn't create them in the scene

Assets > Install Asset Library > Show Details > turn Instantiate Asset OFF
(I hate this…too )

arctor

Installing new HDAs shouldn't create them in the scene

Assets > Install Asset Library > Show Details > turn Instantiate Asset OFF
(I hate this…too )

and I've reactivated the issue, because I don't like it either. It at least shouldn't be hidden under “Show Details”, and I think it should default to off, because I agree that it's very annoying, and sometimes problematic, especially for SOP assets that need an input or very heavy assets.

I hates as well and submitted 66427 for this almost a year ago!

Also, 70314 where the instantiating can bust desktops where you have network editors explicitly linked to parm panes.

arctor

Installing new HDAs shouldn't create them in the scene

Assets > Install Asset Library > Show Details > turn Instantiate Asset OFF
(I hate this…too )

Thanks I never thought of looking under there, pretty hidden

ndickson

arctor

Installing new HDAs shouldn't create them in the scene

Assets > Install Asset Library > Show Details > turn Instantiate Asset OFF
(I hate this…too )

and I've reactivated the issue, because I don't like it either. It at least shouldn't be hidden under “Show Details”, and I think it should default to off, because I agree that it's very annoying, and sometimes problematic, especially for SOP assets that need an input or very heavy assets.

Thanks a lot, that's why I love SESI

The “Install Digital Asset Library” dialog in tomorrow's build of Houdini 15.0 should hopefully satisfy more people. After some discussions, the new dialog has the following changes:

• “Accept” has been replaced with 2 buttons: “Install and Create” and “Install”. “Install and Create” is only enabled if there's a single node type in the asset.
  
• “Show Details” is now “Advanced Options”, and is still off by default, because it now no longer has anything as critical hidden by it, and it's much clearer what it's hiding
  
• “Instantiate asset” is now “Instantiate asset on Enter”, to indicate whether to instantiate when hitting Enter when the library path field has keyboard focus, or to just install.
  
• If it creates the node in an existing SOP network, it will move the display and render flags if they were both on the same node before, instead of just moving the display flag.
  Attached is an image that shows what it looks like after choosing an asset with a single operator type in it and turning on “Advanced Options”.
  
  Edit: I have no idea about the pinning issue in Bug #70314, but hopefully it's at least slightly less of a problem with the new dialog.

Hello,

chrism
If we get the same BUG or RFE logged by multiple users, THAT would get our attention.

But is there a way to put a vote or another way to tell you that it's an interested RFE for us instead rewrite and re-argue an existing RFE (in particular if we don't have access to the existing list of RFE).

Something like this http://mayafeedback.autodesk.com/forums/160514-ideas-for-maya-forum [mayafeedback.autodesk.com] for example.

Thanks.

ndickson
The “Install Digital Asset Library” dialog in tomorrow's build of Houdini 15.0 should hopefully satisfy more people.

This is a huge relief, thanks to SESI team

julca
Hello,

chrism
If we get the same BUG or RFE logged by multiple users, THAT would get our attention.

But is there a way to put a vote or another way to tell you that it's an interested RFE for us instead rewrite and re-argue an existing RFE (in particular if we don't have access to the existing list of RFE).

Something like this http://mayafeedback.autodesk.com/forums/160514-ideas-for-maya-forum [mayafeedback.autodesk.com] for example.

Thanks.

That's an issue currently. That's why I started this thread for visibility from other Houdini TDs. Otherwise the same thing can be submitted by different people and be filed as different bugs based on how they are worded, unless they are very specific.

Copy/Pasting of Ramp parameter references for HDAs are not as easy as other parameters

I couldn't find the bug ID for this but I submitted it at least 3 years ago. Should I resubmit? Yahoo mail search is not very smart.

I had to explain to a colleague who is just starting to use Houdini (experienced Maya TD) why he can't just copy a reference from a ramp parameter and paste it on a different ramp parameter, unlike the other parameters.

Even if this convoluted method can't be replaced, Houdini should at least do it for you in the background when it sees that you are trying to copy a ramp parameter reference onto another.

pusat
Copy/Pasting of Ramp parameter references for HDAs are not as easy as other parameters

I couldn't find the bug ID for this but I submitted it at least 3 years ago. Should I resubmit?

Looks like it's listed as RFE 39171, originally submitted by someone else about 6 years ago. Feel free to ping it!

ndickson

pusat
Copy/Pasting of Ramp parameter references for HDAs are not as easy as other parameters

I couldn't find the bug ID for this but I submitted it at least 3 years ago. Should I resubmit?

Looks like it's listed as RFE 39171, originally submitted by someone else about 6 years ago. Feel free to ping it!

Ok just referenced that RFE # to support to add my name

Btw the same Maya guy also asked something that I didn't think twice in Houdini, just got used to it, which is, why does the order of the operation in the Multiply VOP matters for vectors and floats? I know how it alters the result but not why?

Is there a good reason for this?

SOPs with Guide should have an option to hide the Guides

I know there is a global option but IMO any SOP that shows guides should allow the ability to turn them off locally within the node.

Even in production I have seen many times, people place a null after these nodes just to be able to hide the guides as I do too. This is the most obvious way as not everyone knows that there is a even global option. And even then toggling this option takes more time and it's still a valid reason to want to keep this option on so that you can see guides that are useful but not very cluttering.

Some of the SOPs that have cluttering guides are Copy SOP, Ray SOP off top of my head.