Hi all. Just interesting, as I understand correctly, VEX is something like shader language that can be processed for geometry, compos, etc. It can only manipulate existing data, not create new one. ICE looks like have combined contexts for manipulating and creating geometry, and rigging of course. So ICE was created for more general data processing than VEX?

you can look at it like that
ICE is more feature rich than VOPs alone, with great amount of functions that we'd love to have in vops, but Houdini is much more than VOPs
so there is more difference than it's possible to directly compare
ICE has one big disadvantage in keeping everything in the same network comparing to houdini multicontext workflow and that is getting the data from anywhere you want

so reaching from one ICE network to another and get data from say 3rd execute port is not possible (correct me if I'm wrong)
so you need to save everything you are interested in as an attribute which you can reach at the end (not sure if you can save topology into attribute can you?)
but even then I'm not sure if you can reach into modifier stack and get like result of modeling marker or individual modifiers, since that's what you are doing in houdini by referencing individual SOPs or anything
I've been hacking that in Softimage by cloning geometry after each stage I need to access (painful )

so as much as I love ICE I feel that Houdini is much more flexible and readable as well
also rigging in ICE is painful due to it's restrictions so I feel much more comfortable with SOPs/CHOPs combo for that as it's much more procedural

I'd argue that the comparison of ICE to VEX is a non-starter as VEX is just used to construct a single SOP which in turn can be re-used within the entire SOP context. ICE is ICE, all or nothing.

If you compare ICE to Houdini's entire geometry context and not just a subset of VEX, then you will easily find that Houdini's geometry context is entirely based around dynamic creation and deformation of geometry. And what a rich library of growing primitive types that is!

VEX/VOPs is used to construct a single node which is then used to deform geometry. Sure with ICE you create compounds but there is no relief from the constant maintenance of input/output types that you need to manage.
With Houdini, VEX/VOPs are used to build a singular operator which uses single wires to pass data from one operator to the next. Any artist can use this single wire approach and this has been proven over and over again. For the last 26 years at least.

VEX is written with a simple shader writing language which is compiled on the fly. More than artist accessible to write your own low-level operators and yes this means you don't have to require an R&D resource to push things forward.
ICE requires you to write c++ to do the same. Not nearly as accessible.

As for primitive support in VEX compared to ICE, this too is changing. In the latest release of Houdini12.5 many of the hscript commands to access primitive information have been ported to VEX which makes a lot of the preH12.5 VEXvsICE comparisons somewhat invalid.

Just what can you modify with ICE vs VEX?
ICE can process geometry within the Softimage context
while
VEX can process volume data and is the same language used to:
- compose compositor nodes
- compose geometry modifier nodes for SOPs and DOPs
- compose channel operator (CHOPs) nodes
- compose displacement shaders
- compose surface shaders
- compose cvex programmes for many Mantra procedurals

Remember this is all circa H12.5 and all VEX/VOP notes above are always subject to change, and in some cases shoved in to daily builds.
ICE is subject to maintenance updates at what Houdini user's would say “a glacial pace” making it challenging for them to adapt their technology to the rapidly changing landscape in VFX.

Ultimately you need to consider the application in which ICE and VEX are utilized.
In Softimage, it still has at it's heart a cache of the geometry. It is a modelling application first and foremost. It is no surprise that ICE is a take-all-prisoners technology in Softimage where it takes over what you are doing. For example you either rig traditionally or you use ICE.
In Houdini, everything is a node. Everything is passing data from one node to the next. There is no static result cache in Houdini as everything is dynamic. If you choose to cache geometry, then it is no surprise that you lock a SOP and at that specific point, Houdini must write the geometry in to the scene file.

Again comparing ICE to VEX doesn't wash with me. You need to compare ICE to SOPs. Then and only then will you start to ask the correct questions.

Finally, just download Houdini and invest a few evenings to see for yourself what SOPs and VEX/VOPs offer to you as a VFX artist. We do have a free Apprentice version with no obligations other than a user name and a password.

There are the generic wrangle operators introduced in to H12.5 which allow you to compose vex functions right at the SOP level for complete access and are designed for you to create and modify any attributes and easily throw vectors about, something that expressions on SOPs were used exclusively in the past.

As more artists adopt their SOP expression workflows to vex with the wrangle operators, more and more artists will become familiar with the rich library of vex functions and learn to compose shaders either with VOPs or at a lower level with VEX with their first taste in the form of the various wrangle operators.

Yet another way to quickly wrangle massive amounts of data that is more than possible in Houdini 12.5.

Thanks for detailed answers.

Tomas, can you please list some of the ICE functions you would love to have in VEX? I haven't used ICE personally but would be eager to know what they have that VEX lacks.

Jeff, VEX is a pretty elegant language, and the new Wrangle SOPs are very useful. If only we had the ability to define new VEX functions inside, they would be much more powerful. Lack of this ability forces us to create new operators needlessly that are very specific (one-offs).

pusat
Jeff, VEX is a pretty elegant language, and the new Wrangle SOPs are very useful. If only we had the ability to define new VEX functions inside, they would be much more powerful. Lack of this ability forces us to create new operators needlessly that are very specific (one-offs).

If I get you straight, you can as of H12.5. There is a new option in the Edit Operator Type Properties when working with a VOP HDA inside a VOP network: “Save Cached Code”. Same as with SHOPs.

This means you can now take a regular VOP HDA and enable this new option and you now have a new pre-compiled function inside of your shader exposed as that VOP HDA. You can reuse this HDA and it will call this function just like any vex coded node. Just create one and inspect your compiled vex code.


The only caveat is that you can not embed a Parameter VOP inside your pre-compiled HDA.

To get around this limitation, we added the Bind VOP which you use in place of any Parameter VOPs to import and export attributes.

Hope this is what you were asking for.

Thank you Jeff. That sound very useful as well. Not sure how much performance you would get out of it by using it on a VEX SOP HDA vs VOP SOP HDA. I imagine the gains are bigger for VOPs and the bigger the network is, the bigger the optimization. Although it seems to be disabled for SOPs.

By the previous feature, what I meant was being able to define local functions inside a Wrangle SOP (simplified):

float computeComplexValue ( vector p )
{
…
return value;
}

if ( P.x > P.z )
P.x = computeComplexValue ( P );
else
P.x = P.z;

Inline VEX VOP, Snippet VOP all inherit this limitation due to VEX. One of the SESI developers said this to me:

“The right solution to this is to allow functions to be defined inside function scopes in VEX. Then it would come for free.”

Hope you guys add this to H13. It would help in making very complex VEX-based HDAs without creating a ton of helper nodes that are unusable by themselves.

pusat
Thank you Jeff. That sound very useful as well. Not sure how much performance you would get out of it by using it on a VEX SOP HDA vs VOP SOP HDA. I imagine the gains are bigger for VOPs and the bigger the network is, the bigger the optimization. Although it seems to be disabled for SOPs.

The main performance improvement is in the pre-compilation of various parts of the shader.

I haven't used ICE much, but to continue with the SOPs vs ICE analogy… from my understanding, there's an “ICE Stack” that serves to provide different contexts to govern the behavior of a given ICE network… specifically, there's a “simulation” stack, as well as pre- and post- simulation stacks (which are, obviously, evaluated in order), as well as some other stacks. I think I have that right. So, if you had a twist deformer in a pre- or post- simulation stack, it would behave as usual - twisting the geometry to whatever degree; but if you had the twist deformer in the simulation stack, it would continue to twist per time-step, on and on. Again, not an XSI guy, so let me know if I have that wrong.

By analogy, in SOPs, you have a Solver SOP, which incorporates feedback from the previous frame - essentially permitting you to treat the entire Solver SOP context (which is actually a SOP Solver DOP wrapped in a DOP Network SOP inside a subnet… whew - but in practice, it feels like you're just diving into a ForLoop or Subnet SOP) just like an ICE simulation stack… and, therefore, anything that comes before the Solver SOP acts as a pre-simulation “context”, and anything after your Solver SOP serves as “post-simulation.”

Obviously, you can take this further… you're not limited to one Solver SOP should you want more, and it's very easy to visually gauge the relationships between and across these “stack contexts.”

Hope that's helpful?

Thank you guys for the time taken on those in depth replies, nice reading.

Just to add a bit of my own wonderings.
-I was a bit “shocked” to come to understand that ICE Tree and Render Tree are isolated in SI. So in Houdini it's all a single room where there's no disconnect?
-Order of Evaluation is something I feel is not very flexible in most applications. You choose what to solve but not always when, before or after what to solve and at what stage the data is being collected for further calculations and then set on the scene. How do you guys feel about it in Houdini?
-ICE allows to change properties of the objects, like a Camera FOV or the OGL display color of an object. Is this something the Houdini system comprises?

Lastly, whats the best reference you guys know to understand the structure of Houdini and it's acronyms (VEX, SOP, POP, VOP, etc…)?

Hopefuly these questions aren't too off.

Cheers

I will want to tackle the “order of evaluation” one.
In Houdini there´s no such thing as a forced order of evaluation unless you mean when the scene is sent to the render engine.
Stuff such as deformers, weights, or when dynamics kick in, all depend on where you place them into your network or where the geometry you send is placed.

For instance, if you create a deformer with a VOPSOP (VEX) this might be placed wherever in your modelling chain you want it to be, and thus, it will calculate at that point.

Another example involving DOPs: dynamics will calculate, of course, every frame (or sub-frame) but the geometry it uses for its calculations depends totally on what you decide to send, which might perfectly be an early version of the model, or a proxy or something you are deleting polys from every frame, etc…

As for Houdini structure and its acronyms…don´t feel bad if people sends you to the help docs :they are actually pretty helpful.

Cheers Netvudu help documents it is

Yes I was asking about Order also taking into account rendering in this regard: In Lightwave I can create the same render tree calculations on Displacement nodes, or in Surface nodes. My studio uses SI and I tried to build a Curvatures shader [imageshack.us] (average angle that the normal of a vertex does with it's neighbor vertices). Couldn't do it in the Render Tree, had to do it in the ICE tree [dl.dropboxusercontent.com]. Problem? SI's Scene Subdivision only kicks in at the end of all stacks and I wanted my ICE tree to evaluate after that. I see there's a “Manta Compatible Subdivision”…

Well I'll disappear now into documentation and videos like the 3DBuzz one. See you in a couple of months

Thanks