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

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.

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 .

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.

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

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.

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.

AnngryKitten
I also intend on doing work in Harmony regarding 2D animation

I would check with ToonBoom about the GPU before you buy anything. I had serious issues(Harmony was completely unusable) with Titan Xp, their support acknowledged they don't test on one.

Calling scene_viewer.clearPromptMessage() before the call to setPromptMessage prevents the error message for me.

I can replicate the abort message, there seems to be some issue with the node's selectors, you should file a bug report. It only seems to happens when the state is first entered, definitely a defect.

I saw this post a few times and was like ‘meh, what do I need this for’.

But I figured I would try it out anyway… after two seconds I'm hooked, this is a seriously impressive tool.

Thanks so much!

Thanks for the scene file and videos! You got me to take a more serious look at and really helped me get started with numpy.

Great stuff!

BabaJ
Actually, it does.

I may be missing something, but I think what you're referring to is interpolation between points not fitting. amelnychuk's setup fits a curve to a set of points, rather then drawing a smooth curve through each point.

scene_viewer.showHandle('name you assigned to handle', 1(for on 0 for off)) should work.

As long as the plugin is GPL compliment(as it ideally links statically to blender) I don't think there's an issue. Houdini engine plug ins are linked dynamically(to Houdini), the same way Blender links to the OS.

One solution is to create menu items that say ‘Start Task’ and ‘End Task’ and have the user click them.

You can also create a callback for file changes in the 456.py callback. scripts/456.py is called when you create a new scene then you can match that with callbacks on saves to scene file. Or use 456.py to mark the start time and add a menu item for commiting the task then just measure the elapsed.

Most pipelines will have their own way defining what the ‘end of the task’ means, so if your looking for a pre-packaged solution that handles this you'll have to look to some external tool.

You can achieve that with compiler directives.

Awesome demo! Thanks _mab_

kwargs is a dictionary implicitly(Houdini adds its to the python environment before it calls your code) passed into virtually every python callback(things like parm callbacks, onInstall, onLastDeleted but not the HDA's python module as that's not a callback). It gives you the context you need to work within the scene, so you'll have things like the node the callback is called for or the previous and current parm values. I usually print it out first to see what I have to work with.

In order to reference the nodes inside your HDA you would use relative paths.

Are you assuming Houdini Engine is placing your asset at “/obj/wall_generator”? Try using kwargs to get the node, instead of hard coding the path.