I would like to call every ICE artist diving into Houdini to discuss porting the very practical (and not so granular) nodes Softimage provides to Houdini so we can make the transition even easier.

Many of these nodes I am sure will appeal the Houdini community, like the various statistic related tools, so it will need some help on the translation to Houdini.

My question would be, could we put a list of the more important nodes to be translated, get some contributors to help and kickstart this project to create an open source library?

:-)

jb

There are some killer ICE tutorials for any Houdini artist wanting to know more about ICE too.

Pooby Ice Tutorial and Demos
http://vimeopro.com/pooby/ice [vimeopro.com]

Always good to see what can be done elsewhere

hey jordi,
I am not sure I understand.

I think that there is an equivalent to every (low level) ice node in vop sops. I do not miss anything so far, besides the whole array stuff.
so do you mean compounds?

.sebastian

sekow
hey jordi,
I am not sure I understand.

I think that there is an equivalent to every (low level) ice node in vop sops.
well besides the whole array stuff.

.sebastian

My impression so far is that the capability is there but in a very low level way that means certain tasks you have to build every single time, for this reason softimage wrapped certain low level nodes onto bigger compounds to make people's life easier.

A good example is “Test random probability” compound that contains this inside… Notice the functions from Mean Value and Variance…

The same for “Get closes location” which is not trivial to build in Houdini.

I would love to discuss this further and see if there is real value on such an effort.

jordibares
A good example is “Test random probability” compound that contains this inside… Notice the functions from Mean Value and Variance…

The same for “Get closes location” which is not trivial to build in Houdini

“Get closest location” is currently implemented as Minimum Position VOP (new in H12.5 or 13). “Test random probability” might be good candidate though (Compare VOP between Random VOP and trigger value plugged into a Two Way Switch VOP, so one instead of three nodes…).

Generally speaking making ICE nodes for VOPs might be unrealistic. Perhaps better approach would be a database of common idioms? So an atomic operations in ICE with corresponding VOPs counterparts would be listed in alphabetical order.

I feel like ICE is too different from VOPs to make straight ports possible in any but the easiest cases.

SYmek

jordibares
“Get closest location” is currently implemented as Minimum Position VOP (new in H12.5 or 13). .

please correct me when I am wrong, but that wouldn"t be closest locations.
that would be closest position.(see attached pic)
locations are barycentric coordinates where you can fetch all kind of attributes.

ive learned that the equivalent for closest location would be a xyz distance with a primitive attribute vop. so far I understand its the exact same concept, its just that its called primitive uv.

sekow
please correct me when I am wrong, but that wouldn"t be closest locations.
that would be closest position.(see attached pic)

Absolutely! Both are new in VEX land (were present for years in hscript). Sorry for confusion.

just want to add that i feel very comfortable in vop sops.
the closest location functionality was the only thing so far I could not figure out right out of the box.
what could help is to translate popular tasks done inside ice trees into vop sops: reading color values from a second object, modulated by distance for instance

Test Random Probability (XSI) node in VopSop example:

jordibares
I would like to call every ICE artist diving into Houdini to discuss porting the very practical (and not so granular) nodes Softimage provides to Houdini so we can make the transition even easier.

Many of these nodes I am sure will appeal the Houdini community, like the various statistic related tools, so it will need some help on the translation to Houdini.
jb

Jordi -

Great topic!

One thing I've missed a lot is the “UV to Location” node that works on nurbs curves and surfaces which lets you feed in a u or v coordinate (or array of coordinates) and evaluate the curve (say, to get P, Normal, and Tangent) at that parametric location.

Also a mechanism for geometry traversal would be nice, like if I have a primitive handle I'd like to be able to get the prim's points and iterate over them, for example.

In VopSops it would also be nice if there were OpInput ports in the Globals in the same way that they have them in the AttribVop Globals, that would make any of the geometry query nodes (pcOpen, xyzDist, etc.) quicker to set up.

Of course also the statistics nodes (max/min/average in set) in SI would be nice to have out of the box (instead of having to build detail attributes beforehand - there's something to be said for having as much of the relevant data in the same place instead of scattered about), but I can understand maybe why they don't exist (or why if they did, they might impact performance adversely).

-T

takita
In VopSops it would also be nice if there were OpInput ports in the Globals in the same way that they have them in the AttribVop Globals, that would make any of the geometry query nodes (pcOpen, xyzDist, etc.) quicker to set up.

Like this?

owlYzarc
Like this?

Yes, I did something like that myself but even then it's far more ergonomic (and obvious) to just have it in the globals, don't you think?

I understand that the usages of pcOpen beyond simple geometry access (for say shading context or reading from disk) make it sensible to have a filepath, but even for consistency with the AttribVop it's quite convenient and nice to have it right there.

cheers,

-T

+1 Excellent idea Jordi.

Obviously, us SI users will understand the overlap between ICE and vopsop a little better once you enlighten us with your guides to that respect (keep up the amazing work!)

In ICE I'm constantly using things like ‘modulate by null’, ‘fcurve’, and locations (generally speaking) to create non-simulated behavioral motion, kicking out quick C4D-style mograph effects. Gustavo's Motion Tools are a nice example of how to bundle the built-in ICE nodes to create these types of effects even faster.

I can fairly easily see how to re-create these compounds with lower-level vopsop nodes in Houdini, but the speed advantage of having compounds at the ready is huge. That's the main reason why things are so fast to prototype with ICE.

Where would be the proper place to start hosting these? Is that the idea behind orbolt? in SI territory, rray.de/xsi became the central repository for this sort of thing.

takita, yes, definitely, but that would have to be done by Sidefx
i'm just offering a solution till then

owlYzarc
takita, yes, definitely, but that would have to be done by Sidefx
i'm just offering a solution till then

Understood, thanks.

I'll put in an RFE and keep my fingers crossed for that.

cheers,

-T

It is a matter of wrapping common things as you guys pointed out…

I don't think we should pimp Houdini to be something else but our experiences with ICE and how trivial these things could be is something worth passing to Side Effects.

As the example with the globals suggestion, this is clearly a winner in my book for BOTH parties and I am sure Side Effects will embrace these ideas.

Keep them coming.

Keith Johnson
+1 Excellent idea Jordi.
Where would be the proper place to start hosting these? Is that the idea behind orbolt? in SI territory, rray.de/xsi became the central repository for this sort of thing.

Feel free to host them on your own site. I must admit I am no fan of orbolt, the exchange was great but the search function was awful. Certainly an interesting thread.Most of old school Houdini people have a raft of otl vops sitting on the drive to cut down the remake roundabout

Good to see you hear Nick !

Rob

Someone should ask rray to make an rray.de/houdini

May put it on GitHub so we can all chip in..

git is nice, after a proper setup it enough to “git pull” and everything is up to date (like with qlib)