If the entire H gui was exposed in QT .ui files we could fully tweak it to our liking.
Every native panel interface should have its corresponding xml file with EVERY QT API SETTING EXPOSED.

Autodesk did a great job with maya, putting every native panel into its own qt/xml file.
(Everything is tweakable, you can even get rid of crap buttons on the parameter panel.)

Such tweaking is not possible in H, you can change some colors and thats it.
The only app with worse GUI customisation is probably Blender, and we all know how much Blender is loved for its gui…

I will add anther one:updating houdini dailybuilds is painful,you can’t update inside the software or just download/install the updating part,actually you have to download the whole software and install it again.LOL

@wanglifu - Houdini Launcher essentailly manages this. Give it a whirl and send SESI feedback.

goat
@wanglifu - Houdini Launcher essentailly manages this. Give it a whirl and send SESI feedback.

that’s a good move,although I can’t login…

Jonathan de Blok

EricSheng

seifdune
we need node/tool special for destruction modeling which will simplify and speed the modeling process in houdini. One tool which contain bridge,extrude,bevel,add loop,loop slice,make circle,fill polygon and others. This will help when you just want to model something without the need of the procedural workflow.

No, I don't want to see a new toy tool like Poly Draw. I just hope one day we can select/edit multiple points at a time with Curve SOP.

I wouldn't call it a toy tool, it's quite a leap forward from what it used to be! Look, some tasks just aren't procedural by nature and I'd like to see tools that are more aligned with that workflow. You can still mix and match them as you'd like.

Thank to topobuild now we can do retopology inside houdini we need more tools like this,it help to smooth the workflow from zbrush to houdini i don't need to use modo or 3d coat.

Addtionally, Unicode File Name support please!

When I was talking about the need of better UI, I was referring also to very practical and frustrating things like the following:

Afaik, the only way to have a custom label for each multiparm instance is to use a workaround of not displaying its actual label and using instead a label parm joined horizontally. You change the label parm by setting the value with parm.set('my_label')
The problem is the ridiculous alignment of the label parms. You can't justify them to the left.
You see how much space is getting wasted because of this?

Bugs related to the label alignment and justification are logged as #82270 and #85844

Andr
When I was talking about the need of better UI, I was referring also to very practical and frustrating things like the following:

Afaik, the only way to have a custom label for each multiparm instance is to use a workaround of not displaying its actual label and using instead a label parm joined horizontally. You change the label parm by setting the value with parm.set('my_label')
The problem is the ridiculous alignment of the label parms. You can't justify them to the left.
You see how much space is getting wasted because of this?

Bugs related to the label alignment and justification are logged as #82270 and #85844

The HDA interface alignment is really lack of control and user adjustment. The Icon Strip can't scale up, the Multiparm Block is buggy, if you have a ramp curve inside Multiparm Block, it's hard to link the parm to the inside nodes, also the Import Block is not working with Multiparm Block.
And the Callback Script icon shows Python by default, but when you write a line of Python code and hit “Apply”, it will jump to HScipt instantly. So the script won't work at all. Sometimes it drives me crazy when I find out the problem is caused by the buggy HDA editor.

EricSheng

Andr
When I was talking about the need of better UI, I was referring also to very practical and frustrating things like the following:

Afaik, the only way to have a custom label for each multiparm instance is to use a workaround of not displaying its actual label and using instead a label parm joined horizontally. You change the label parm by setting the value with parm.set('my_label')
The problem is the ridiculous alignment of the label parms. You can't justify them to the left.
You see how much space is getting wasted because of this?

Bugs related to the label alignment and justification are logged as #82270 and #85844

The HDA interface alignment is really lack of control and user adjustment. The Icon Strip can't scale up, the Multiparm Block is buggy, if you have a ramp curve inside Multiparm Block, it's hard to link the parm to the inside nodes, also the Import Block is not working with Multiparm Block.
And the Callback Script icon shows Python by default, but when you write a line of Python code and hit “Apply”, it will jump to HScipt instantly. So the script won't work at all. Sometimes it drives me crazy when I find out the problem is caused by the buggy HDA editor.

Hi Eric,
Regarding the icon strip size, some months ago I had submitted an RFE to increase the size of the icon. It's RFE #95064, if you want to support it.
Regarding the annoying autoswitch to hscript language of the parms callbackscript, I believe they finally fixed it in 17.5.385! (but had not chance to test it)

cheers

Hi, Andr:
Thanks for your reply, I'll test it later,(although it looks like not the case cause the problem comes looong ago instead of 17.5.382)
Also, I want to know is it possible to inject my custom Qt widgets into HDA's parameter pane? It seems impossible currently. It's interesting how the Visualize Node achieves the pane.

Cheers.

Eric I believe that they fixed it on .382


Anyway, more on the icon strip and button strip parms:
It seems that it's not possible to have multi-toggle strips with more than 31 items, as they return a wrong bitfield, and so you can't identify which button are selected.
It seems that it starts to fail at around the 31th position if you read the bitfield with python, due to python 2.7 integer limit?? I don't know.

Interestingly it seems to fail even earlier if you read the strip parm with Vex!
Maybe I'm doing some wrong, but in this example Vex is not able to read the correct bitfield after the 25th position.

Hope that with Hou 18 and python 3 we will be able to correctly read multi-toggle button strips having more than 31 items.

Curve node is a daily pain for me. Not being able to move more than one point is a real killer.

Andr
Eric I believe that they fixed it on .382


Anyway, more on the icon strip and button strip parms:
It seems that it's not possible to have multi-toggle strips with more than 31 items, as they return a wrong bitfield, and so you can't identify which button are selected.
It seems that it starts to fail at around the 31th position if you read the bitfield with python, due to python 2.7 integer limit?? I don't know.

Interestingly it seems to fail even earlier if you read the strip parm with Vex!
Maybe I'm doing some wrong, but in this example Vex is not able to read the correct bitfield after the 25th position.

Hope that with Hou 18 and python 3 we will be able to correctly read multi-toggle button strips having more than 31 items.

Yeah, I've tested on 17.5.382, it's already been fixed finally. For the multi-toggle strips, I have never used strips that much, it'll be a long parm in the pane.

peteski
Curve node is a daily pain for me. Not being able to move more than one point is a real killer.

Curve Node is one of the poorest parts in Houdini, but they think it's good enough so for so many years without any update. And we have to add an Edit Node to drag multiple points at a time. It's not productive nor procedural.