HDK vs. Python

[Daniel]

I'm guessing this has been talked about before but I'm a little late to the party and I'm not seeing any threads at the moment (but being a bit lazy too). I haven't used houdini hands on extensively since h8 and figured while I have a little time I should take a look at what I'm missing.

HOM looks very powerful as it appears to have many of the features that you used to have to go to the hdk to get. So I'm just trying to figure out when it's worth going with HDK or HOM. My guess would simply be speed, I would guess the HDK would be faster but I don't want to assume that. I'm also guessing the HDK is more flexible in the end and HOM probably only supports a subset of what you can do in the HDK. Just want to get your impressions after using both for a while now.. If a sop can be built in HOM is there a reason not to?

thanks

D

[johner]

To me this is a bit like the question of C++ vs. Python in general. My answer lately is always Python if at all possible. If you find out it's too slow, then, and only then, move it to C++. Your code may perform fine for the particular case you have in mind, in which case you're done. If not, you've got a working prototype that you got to develop in a more productive programming environment for iterative development. Just the creation and tweaking of parameters for the UI in a Python SOP vs. the HDK is worth it, IMHO.

That said, HOM could still use some fleshing out. There's definitely some features still missing, although you can often resort to hou.hscriptExpression (although there's that speed thing again).

[Guest xionmark]

Hi there Dan,

The machine code vs. interpreter is one argument, but if performance isn't an issue, and you deploy with Python, you'll at least avoid the often unpredictable HDK recompiling required for some, but not all, minor Houdini upgrades ...

Also, there's been a bit of talk about using the HOM to wrap up C/C++ compiled code as DSO's that are not required to recompile because the cpu intensive function resides in the DSO, and all the Houdini API interface is accessed through the HOM. Then one doesn't have to recompile the DSO(s) that are dependent on the various HDK bindings. Haven't gotten around to that yet, but it's so easy to extend Python with C/C++, should be easy enough to do. And since the GPD code is public, I think all the ingredients are there to build such a system.

Mark

[johner]

Yeah, that's a really good point about not having to fight HDK versions. And with things like Cython, you can develop a lot in Python, then incrementally move things to something like Cython (which is quite straightforward) and have Python extension modules that are version independent.

[Guest xionmark]

Yeah, that's a really good point about not having to fight HDK versions.

Of course it still depends on what you want to do. Haven't had time to work this out yet but you should be able to load any of the SESI DSOs at run time like any other DSO and therefore still be able to have access to the full HDK API. So your Python code can handle passing off the parms and gdp pointer and let your DSO handle it from there on out, and returning to Python the new/modified data and status. All straight up C++.

Mark

[sibarrick]

Don't forget too that now Vex has arrays that is strongly back in the mix when deciding what to code in. As recent experience has shown Vex can out perform the HDK as it can taken advantage of threading.

My route at the moment is to knock up a proto type in HOM and then switch to Vex or HDK to speed things up.

Here's a good example, and something you might be interested in too if you missed it

Coding WIP

Edited September 26, 2009 by sibarrick

[Daniel]

Don't forget too that now Vex has arrays that is strongly back in the mix when deciding what to code in. As recent experience has shown Vex can out perform the HDK as it can taken advantage of threading.

My route at the moment is to knock up a proto type in HOM and then switch to Vex or HDK to speed things up.

Here's a good example, and something you might be interested in too if you missed it

Coding WIP

Thanks Simon, I'll take a look. Been out of the loop for a long time. I currently have an interesting node running in python and it does need to be faster, so going to weigh my options. That Cython looks interesting as well.

One thing I learned while working with HOM is if I update a module I'm sourcing while houdini is running it doesn't pick that up, a restart of houdini appears to be needed (unless there's some sort of flush command that I need to run?)

[rdms]

Thanks Simon, I'll take a look. Been out of the loop for a long time. I currently have an interesting node running in python and it does need to be faster, so going to weigh my options. That Cython looks interesting as well.

One thing I learned while working with HOM is if I update a module I'm sourcing while houdini is running it doesn't pick that up, a restart of houdini appears to be needed (unless there's some sort of flush command that I need to run?)

Use the reload command in the Houdini python shell. For example:

>> import foo

>> reload(foo)

[graham]

I agree with pretty much everything johner mentioned. It's much faster to prototype specific things using a Python operator, especially when you have to deal with the operators interface. Python can be slow when you are trying to modify geometry but there are certain tricks you can use to get around it. If not there is always VEX or HDK. I prefer to use Python if I can though since it offers a lot of flexibility. It would be nice if HOM wasn't missing things, but being one who has used it since pre-alpha 9.0 days, it's a lot better than it used to be.

As for running C/C++ code from within Python, I know Luke spent a little bit of time investigating that and I think he came up with something that worked pretty well. Not sure if/when we'll see it in Houdini though. I know he always wants to add PyVex as well.

Daniel: Like any other module in Python, if you have imported it in an active session, all you need to do is call reload(mymodulename) and it will update properly in your session; no restart required.

[lukeiamyourfather]

All are good points. One not mentioned yet is the fact that Python isn't implemented fully or even at all in many aspects of Houdini. In those cases the HDK is the only option.