Bezier handle HDA built with H17 python viewer state. Please let me know what you think, issues, requests etc.

Thanks.

UPDATE: New Version coming to Orbolt, this one will still be here.

i will try this later, and this is great. I was hopeing somebody would build exactly this.

Looks great!

In your HDA, you could register the state in the OnInstall event and do the unregistration in the OnUninstall event instead. OnInstall is called when the HDA is loaded. Also, when you save your HDA, OnUninstall and OnInstall are called, this allows the state to get updated without having to quit and restart Houdini.

Self-installed python states (i.e. states implemented on disk) can be reloaded from Houdini by calling hou.ui.reloadViewerState. Take a look at the `stateutils.Menu` utility, there is menu entry you can use to reload the underlying self-installed state.

e.g.



-mab

That is awesome, thank you for sharing

Hi Thomas,
great work, it works!
I would also like to see an optional node input to be able to edit existing curves. (Just added this myself)
Box helpers and sphere helpers is ok, but lines connecting the box and sphere helpers would be even nicer…

regards and thx

Olaf

Thanks goldleaf!

Thanks Olaf! I addressed both issues; I'm not sure how you implemented the curve input? I added an optional fit node to allow the user to create a bezier curve that will work with the handles.

mabz
In your HDA, you could register the state in the OnInstall event and do the unregistration in the OnUninstall event instead. OnInstall is called when the HDA is loaded. Also, when you save your HDA, OnUninstall and OnInstall are called, this allows the state to get updated without having to quit and restart Houdini.

This appears to create a number of warnings when Houdini starts up claiming improper handle binding on certain assets, however it doesn't seem to actually break anything.

mabz
Self-installed python states (i.e. states implemented on disk) can be reloaded from Houdini by calling hou.ui.reloadViewerState. Take a look at the `stateutils.Menu` utility, there is menu entry you can use to reload the underlying self-installed state.

e.g.


m = hou.ViewerStateMenu(state_name+'_menu', state_label)
m.addMenu( su.Menu.debug(state_name, state_cat) )
m.addSeparator()

# bind the popup menu to the stroke state
template.bindMenu(m)

When I tried calling ‘su.Menu.debug’, there where a number of errors that appeared to be coming from where ever the UI file generation takes place, the inner menu didn't populate and in the temp folder it wrote out the UI file (I don't know the language syntax so I can't tell if it's valid). Am I calling it incorrectly?

I was able to cut and paste the meat of the function into my code and it does work. Saves a huge amount of time, Thanks mabz!

EDIT: Updated asset; redesigned to use Drawables API.

Thomas Bishop
Thanks goldleaf!

Thanks Olaf! I addressed both issues; I'm not sure how you implemented the curve input? I added an optional fit node to allow the user to create a bezier curve that will work with the handles.

mabz
In your HDA, you could register the state in the OnInstall event and do the unregistration in the OnUninstall event instead. OnInstall is called when the HDA is loaded. Also, when you save your HDA, OnUninstall and OnInstall are called, this allows the state to get updated without having to quit and restart Houdini.

This appears to create a number of warnings when Houdini starts up claiming improper handle binding on certain assets, however it doesn't seem to actually break anything.

mabz
Self-installed python states (i.e. states implemented on disk) can be reloaded from Houdini by calling hou.ui.reloadViewerState. Take a look at the `stateutils.Menu` utility, there is menu entry you can use to reload the underlying self-installed state.

e.g.


m = hou.ViewerStateMenu(state_name+'_menu', state_label)
m.addMenu( su.Menu.debug(state_name, state_cat) )
m.addSeparator()

# bind the popup menu to the stroke state
template.bindMenu(m)

When I tried calling ‘su.Menu.debug’, there where a number of errors that appeared to be coming from where ever the UI file generation takes place, the inner menu didn't populate and in the temp folder it wrote out the UI file (I don't know the language syntax so I can't tell if it's valid). Am I calling it incorrectly?

I was able to cut and paste the meat of the function into my code and it does work. Saves a huge amount of time, Thanks mabz!

EDIT: Updated asset; redesigned to use Drawables API.

I fixed some syntax issues in your HDA to be able use OnInstall and OnUninstall. For the debug sub menu problem, it seems to be related to the state name syntax itself, I'll file a bug to fix this. I also changed the state name to use the debug menu, see attachment.

Thanks mabz!

Hello. Forgive me for digging up an old thread here, but was this tool ever made as an hda rather than hdalc?
It's really useful, but hda would be super handy so it can be used in FX. It's not on Orbolt as far as I can tell.

The problem I had was that, Orbolt doesn't allow editable nodes, and this setup uses an editable node so it can store edit deltas, allowing the curve edits to be applied procedurally. It was a lot more complicated to implement that with stash nodes instead of editable nodes and keep it procedural.

Could you store the deltas on the node's Python data dict itself? Then no need editable nodes, which usually cause problems unless it's part of a specific artist workflow.

Hmm, using a hou.GeometryDelta doesn't seem to be workable, it seems it can't be converted to a string for the userDataDict, unless you mean store the deltas as just string data but it's not even that bad. It can be done with a stash node to store the deltas, by using VEX to first calculate and then to apply them back.

It really needs a proper C++ implementation though, in fact Houdini already as entire C++ library dedicated to geometry deltas… the VEX implementation was not a robust solution, probably why it required an entire C++ library in the first place.

Worse yet,ch expressions in data parms do not like cooperating, ever. The Operator Type Properties window almost always fails to properly create them and I can never get ch refs pointing to ch refs set ups to work, so it makes putting this HDA in another HDA difficult.

I painstakingly went back and forth around these issues(using an editable node or different geometry stash setups) for over a week and decided that the editable node workflow was the only one that is actually going to work(with the version of Houdini sitting on machine at that moment in time, with the tools I needed it to work with).


Going forward I'm likely to just rewrite this to do almost everything in Python, instead of elaborate and extremely fast SOPs. I would only use this setup if you wanted to have like over a thousand curves on screen and editable at the same time, perhaps unlikely… but if not that, why not just use an edit node and skip all this…

In theory all the functionality is there to make something work, but I was unable to pull it all together. It's unfortunate there's not a good (or at least a clear) solution here, and to instead have to rewrite functionality in python when it could be done way better in SOPs.

Viewer State require maintaining state between cooks, SOPs are not designed for that and while Python can maintain state it's not a very performant language and wasting time re-writing slow implementations of code that already exists(and that you in fact paying money for) is not a preferable choice. In my opinion this setup (preferably with some kind of C++ delta stash node) should be the supported workflow for this type of work. Houdini is seriously lagging behind (itself) in this area, it's a real shame how much is left on the table, that even with C++ it's just not possible to write production capable and flexible code with what's exposed. SESI will catch up but it always takes way more time then it probably needs to, I've learned it's best to adapt to it then fight it (though I'm a character rigger who jumped ship from Maya and started using using Houdini with H12, back when I thought C++ was cool).

Sorry about this, I'm sure it's not what you were hoping for, I do intend on rewriting this HDA to work right soon, but it take more then a day to get it working really smoothly; it tends to be more of an art then a science.

Thanks for the replies. There are many ways to skin a cat aren't there?
I think many would be interested in that HDA, especially those of us coming from other packages who have had handles on bezier curves to play with.

The new version is now live on Orbolt and can now be found https://www.orbolt.com/asset/tombishop::bezierhandle::1.0

Now that I've gotten it up I need to ask about a few things.

1. Pricing; it's $100 for commercial usage as of right now. I think that's too high(I thought Orbolt would let me change prices a bit more easily…). My initial thinking was ten dollars per year for ten years, I predict bezier handles will still be awesome in ten years, and that Python and HDA will still require maintenance. Also, I just like to make updates and improve my tools, because I use them too. (I want at minimum a real bezier drawing tool and robust snapping).

2. Use cases; I only ever wanted this so it can be integrated into other assets mostly for character related stuff, usually for procedurally generated curves from within an asset where the curves may be changed.

3. Is this what you really want? In my experience(I make no money so take it with a block of salt), tools like this are better left to specialized assets, the curve SOP and Edit SOPs are more flexible. You would need to be editing hundreds of handles to make this worth it, and there's probably a way cooler automated way to do that or way a cooler tool could be made to do it. The last point is of particular interest to me, because when you add the work and maintenance required to make a generic workflow you usually spend more time then if you had just made all the specialized tools, that's been a serious pain point for me.

Cheers for the upload Thomas,

That pricing is indeed a bit high. In an ideal world, this handled bezier approach would be available in the software by default, so I appreciate the time you have taken to make this.

There is a downside. My first impressions downloading the trial and playing about with it this morning in 17.0.459 (we can't upgrade to 17.5 here yet for boring farm-related reasons), is that it feels less functional now, which is probably not what you want to hear. See the attached .hip
If I draw out a curve, sometimes handles merge together, and almost all the time, I can't move them. Chatting to my colleague here, we're likely to avoid using the tool for now for reasons similar to what you say. We need something that works now, on this version, the next etc etc. Often scenes are opened up on future series of the same show and reused. If tools break at that point it's a problem.

That being said, I think you're onto something here and it's well worth persuing.

Are you getting Python errors like such and such node can't be found making the asset unusable, can you dive inside the node?

How do you mean merged? Are you sure you mean to not fit the curve first?

Because I see six points and six handles although since the curve isn't fitted to be a proper bezier (by checking the ‘Fit Curve’ toggle). You don't have to use a proper bezier curve but I chose a terrible default to expect the user to want to use any other then a properly set up bezier, these kinds of things are what feedback so important .

I'm unable to dive inside the curve.

I get a much cleaner result using the curve button on your tool rather than feeding in another curve I'll admit, but at the moment I still can't move any points or handles without them snapping back. This is Windows 10 btw which I still consider unready for VFX.

By merged, I meant the handles on nearby points occasionally end up being shared rather than unique to the neighbouring points. Imagine 2 people stood next to each other waving their arms around. Now imagine them holding hands. Wherever one person's hand goes, the other's does too and that's not always ideal.

It seems the asset must be free for all licenses in order for the trial version to not be copy protected, I guess that makes sense. However I know no other way to implement this tool.

It appears it's no longer worth the effort to sell this, as I have already spent more hours dealing with Orbolt then actually writing the damn thing, so it's free now… pending Orbolt's review of my price change of course.

https://www.orbolt.com/asset/tombishop::bezierhandle::1.0