As my first Houdini project I've been trying to convert an ICE rig I did for rolling an irregular shaped object along a ground plane. The original is here:

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

and the Houdini .hipnc scene is attached.

Although I now have ‘working’ versions in Houdini it's thrown up a ton of questions and conceptual misunderstandings. It's also far from optimal. I thought I'd try and document them as much as I could to illustrate where things got confusing and in the hope that someone might point me in the right direction on some of those issues! The .hipnc file contains stickies illustrating specific problems, too. I apologise for the length in advance…

The most significant problem I've found is the transition away from a single monolithic ICE tree to multiple networks in Houdini. That's not to say that in Softimage there was no communication between different ICE trees but you could do an enormous amount in a single one. The ICE tree is like a loosely-typed visual programming container that could perform multiple types of calculations - point based, poly based, node(UV) based, singletons, arrays etc. By the very fact it is one tree the problems of hooking pieces of data together were largely overcome.The ease with which you can creatively piece together different data elements makes it both usable and artist friendly. That whole process is aided by the simplicity of the Get Data and Set Data mechanisms. It is a doddle to pull data into the tree and set data at any point during its execution. This mixture of data types and calcuation types in a single tree doesn't impact the parallel execution speed which is intelligent enough to apply itself when the data/calculation is valid for parallelisation.

The best example I can give of this is the problem of feeding the global transform of a driver object into a VOP SOP in my roll object scene. In ICE this is simply a question of dragging the Global Transform into the simulated ICE tree. Each frame I can store the old transform and then compare it to the new. Very simple. In Houdini, however, it seems more complex - possibly because I haven't found the best way yet. Certainly there are a lot more choices involved. In the end I constructed three different networks to try each method I found - using chf() to create a translation attribute for the driver null; using a chops to derive the translation vector and length; and finally using an inline vex node with optransform to pull the data directly into the VOP (most ICE like but I couldn't figure out a way to store the matrix for reuse on the next frame). But, even in the simplest of those scenarios (i.e. the inline VEX node it wasn't particularly obvious how to do that!)

All these scenarios involved writing some kind of expression and I fully understand this is why Houdini is so powerful but it is something of a culture shock after the simplicity of ICE.

Given the fundamental requirement to pass data from one network of nodes to another I wonder if some of the simplicity of the Get Data/Set Data mechanism could be applied - something that intercedes and lets you visually pick or drag and drop appropriate inputs and that's also contextually aware of what's permissable. Again, I'm a total newbie so this may well all slot into place after months of usage!

As others have pointed out in posts on this forum the ability to get a quick min, max, average of a pointset is a fantastic feature in ICE, a real time saver - I really wanted a node in the VOP to get the lowest y value of all the points after they had been rotated and it seems clunky to have exit the VOP to promote and demote the attribute to do so.Similarly, the visualisation tools in ICE for attributes are exceptional and seemingly much more accessible than those in Houdini.

In the end, however, I'm blown away by how powerful Houdini is and can see how it's like ICE on steroids. Learning where to get data from, how to get it and, more importantly, where and how you should perform the actual calculations is presumably the ‘normal’ Houdini learning process.

If anyone does have a chance to look at the .hipnc scene and comment on any of the craziness in there it would be greatly appreciated.

Julian
Glassworks

nice to have another xsi heavyweight on the houdini side.

hi Julian – no time right now to get into the details, but just a few short quick answers off the top of my head

Julian Johnson
The best example I can give of this is the problem of feeding the global transform of a driver object into a VOP SOP in my roll object scene. (…) - using chf() to create a translation attribute for the driver null; using a chops to derive the translation vector and length; and finally using an inline vex node with optransform to pull the data directly into the VOP (most ICE like but I couldn't figure out a way to store the matrix for reuse on the next frame). But, even in the simplest of those scenarios (i.e. the inline VEX node it wasn't particularly obvious how to do that!)

All these scenarios involved writing some kind of expression and I fully understand this is why Houdini is so powerful but it is something of a culture shock after the simplicity of ICE.

IMHO the best solution is to stick with VEX/VOPs (I think there should be an optransform VOP already – there's the Transform VOP, where you can specify an object name).

Inline VEX is far from obvious, yes (I often find myself struggling with it, too).

If you want to store something to reuse for the next frame, use a context that allows you to do that (i.e. a DOP network or a Solver SOP – which has a dopnet inside, btw).

(AFAIK that is one big difference between Houdini SOPs and ICE – that ICE stores its previous state, like a DOP network – but correct me if I'm wrong.)

Oh, btw, probably I'm not giving away any surprises, but it takes some time to get used to Houdini (when I started, for about half a year I could do all kinds of crazy and interesting stuff with it – with the exception of achieving anything that I previously planned to do ) With the ICE knowledge you'll be fine within a week, I guess

Julian Johnson
The best example I can give of this is the problem of feeding the global transform of a driver object into a VOP SOP in my roll object scene. In ICE this is simply a question of dragging the Global Transform into the simulated ICE tree. Each frame I can store the old transform and then compare it to the new. Very simple. In Houdini, however, it seems more complex - possibly because I haven't found the best way yet. Certainly there are a lot more choices involved.

Hi Julian -
I agree with you completely that data access in VOPs could be improved, especially WRT getting object transforms in to the graph.

One (slightly inelegant) way is to use the optransform() vex function and an inline code VOP to grab the full transform matrix. It's nice because you get the full matrix in one shot but it can also be inconvenient in that the inline code VOP disallows duplicate variables anywhere within the same VOP sop, so if you have multiple transform sources you will need to go and edit each of them manually (instead of just changing a single “SOP path” parameter or something).

cheers,

-T

it is not a ideal solution, but maybe this helps a bit. a inline node packed as an otl, it renames the parameter to fit the code and exports it to the vopnode

You can also set it inside the vopnetwork to the desired path

sanostol
it is not a ideal solution, but maybe this helps a bit. a inline node packed as an otl, it renames the parameter to fit the code and exports it to the vopnode

You can also set it inside the vopnetwork to the desired path

Nice, thanks for sharing!

-T

Julian Johnson
I really wanted a node in the VOP to get the lowest y value of all the points after they had been rotated and it seems clunky to have exit the VOP to promote and demote the attribute to do so.

Hi, Julian,

in your case you can you replace it(radius promotion) with
“bounding box” vop + “get vector component” vop. And stay inside vops
And it gives ~30%-35% speedup.

P.S. thanks for sharing the hip

Hi sekow - where else are all us ICE heads going to go? :-)

Hi Imre - thanks for the advice. I'll definitely look at the SOP solver. As far as retaining the previous frame's state in ICE goes it's just a question of whether your ICE tree sits in the simulation stack or below it. Anything queried from ICE in the simulation stack (in fact any operator in there) retains it's state from the previous frame.

I can't imagine being anywhere near confident enough to commit to using Houdini in production shots until I can clearly see how to get from A to B. At the moment, I'm not even sure I can see where A is!

Hi Todd, great to see you here. I'll bear the issue with multiple transforms in mind.

Hi sanostol, thanks for sharing that!

Hi owlYzarc - that's such a great tip and .hip :-) Got to start thinking in Houdini's own terms.

Very cool guys, looking forward to picking these apart!

Thanks!