So in ICE I'm used to export a compound, it being added to the list of available compounds and me being able to place a referenced instance of it in the node field, so even if I update the compound file it also gets updated in the scenes its used.

How do you do the same in Houdini or are there other ways of working better than this in Houdini?

I already have my parameters in place.


Thanks

you can create digital asset, which is like compound in ICE, however much more powerful
http://www.sidefx.com/docs/houdini15.0/assets/ [sidefx.com]

Thanks. But how to get a SubNet node to expose the parameters?

probiner
But how to get a SubNet node to expose the parameters?

If you mean ICE style ports, or something like this [knowledge.autodesk.com]. There is no such functionality in H. Generally you can imagine SOP nodes as separate ICE trees, so communication is limited to processing the previous result, saved attribute or expression, and that's it. Inside custom Attribute VOP (or old VOPSOP), there is some sort of ‘compounding’ - but user have to dive in, also only one ‘turn’ is allowed, no way to ‘set and get’ data like in ICE.
Bummer, but well, that's what we have to accept in H life.

probiner
Thanks. But how to get a SubNet node to expose the parameters?

I am not sure what exactly you need. You can use digital assets which is more powerful than ICE compound. Also you can save that node in Gallery and reuse if you need it? Can you explain little bit better what issues you have?

amm

probiner
But how to get a SubNet node to expose the parameters?

If you mean ICE style ports, or something like this [knowledge.autodesk.com]. There is no such functionality in H. Generally you can imagine SOP nodes as separate ICE trees, so communication is limited to processing the previous result, saved attribute or expression, and that's it. Inside custom Attribute VOP (or old VOPSOP), there is some sort of ‘compounding’ - but user have to dive in, also only one ‘turn’ is allowed, no way to ‘set and get’ data like in ICE.
Bummer, but well, that's what we have to accept in H life.

?

If you want ICE like workflows, do everything inside an Attribute VOP SOP.
VOPs as with ICE create an actual compiled in time application that executes on the incoming geometry.

You can create VOP HDA's which are similar to Compounds. Note that this is different from building SOP HDA's. The top data input in ICE is not a concept in VOPs as it is assumed that the VOPs will work on whatever context data is wired in at the top level in SOPs which is not a concept in Softimage/ICE where you nave to bind an ICE tree to high level nodes and then tell what data to work on. Houdini is very explicit. Houdini's SOPs also do a lot of the housekeeping for you as well, implicitly modifying attributes in a predictable fashion.

You can take 1, 2 or even thousands of these Attribute VOP SOPs (equivalent ICE trees) and wire them together as high level atomic operators with a single wire. This is a very elegant solution to provide to artists. You can teach every artist in your team to use SOPs. I'd argue that less than 10% of artists would even desire to work with ICE to do work. There is over 25 years of research that has gone in to making these high level atomic operators work very efficiently on massive data sets. Not an easy task by any measure for any dev team wishing to implement such an infrastructure. Nothing is stopping you from doing much of your work in VOPs and then promote handles on the top level along with parameters and multiple inputs. Up to you.

As mentioned above, have a look at how to construct HDA's to build higher level VOPs. Building parameter interfaces in VOPs requires you to use the Edit Operator Type Properties dialog. Lots of customization options in there plus additional facilities to add execution scripts based on call-backs, embed any data you want, etc.

You can pre-compile your VOP HDA's as well, as long as they themselves don't have parameter VOPs embedded inside them. This makes for more efficient run-time compilation of VOP networks.

Hope this helps clarify some things.

probiner
Thanks. But how to get a SubNet node to expose the parameters?

judging from your screenshot you are in SOP level, trying to create SOP level asset/compound
so once you package your attribvop into subnet and convert to digital asset
you can edit it's interface and promote all desired parameters to the asset level
http://www.sidefx.com/docs/houdini15.0/assets/asset_ui [sidefx.com]

jeff

amm

probiner
But how to get a SubNet node to expose the parameters?

If you mean ICE style ports, or something like this [knowledge.autodesk.com]. There is no such functionality in H. Generally you can imagine SOP nodes as separate ICE trees, so communication is limited to processing the previous result, saved attribute or expression, and that's it. Inside custom Attribute VOP (or old VOPSOP), there is some sort of ‘compounding’ - but user have to dive in, also only one ‘turn’ is allowed, no way to ‘set and get’ data like in ICE.
Bummer, but well, that's what we have to accept in H life.

?

Something like pic, obviously is not possible in H, while in ICE it is possible [matkovic.com] to have a mix of what's in H called SOP, together with all sorts of math or any else nodes, all that nicely exposed in one ICE tree, without writing a single letter of expression. Or, to ask from opposite side, why loop nodes in H 15 are ‘flattened out’, if everything is already presented in best way.
Just to make clear, I really like Houdini for home, evening experiments, ICE uniformity become somehow boring through the years - but, that constant ‘diving’, plus compositing app node style (no any modern 3 app looks like this) are parameters that rounds my willing force to zero, to use H for anything with deadline - while ICE can go. I'm afraid I'm not alone with such stance.
I do not have ‘my artists’, I am 3d artist.
Regarding 25 years of research, I just only hope, that there is no some stronger team around, who will need one or two years, to prove exactly opposite.
My apologies if I said something inappropriate.

No issues here. Just trying to get to the real issue and finally you get to the point. Good. The image is pretty much what I was trying to coax out of you.

This is all packaging in the network and please submit an RFE for this.

What is interesting is that we introduced VEX Wranglers as a compact way of writing VEX code at the SOP and DOP level without having to dive in to VOPs and do the context switch. This is why Wrangling has taken off in the Houdini community and is very effective.

What you describe is a parallel workflow where you use VOP nodes to construct vex logic to be read in to a SOP at the top.

one step toward flattening all contexts.

just be sensitive about it, we don't want to end up with network mess ala Maya where everything is connected to everything even single node to itself with multiple lines, just because everything is on one level
but I really liked ICE as well

exactly.

amm
Just to make clear, I really like Houdini for home, evening experiments, ICE uniformity become somehow boring through the years - but, that constant ‘diving’, plus compositing app node style (no any modern 3 app looks like this) are parameters that rounds my willing force to zero, to use H for anything with deadline - while ICE can go.

To clarify are there other reasons too to not use H for serious work? Just want to be sure that these issues are the major reasons.

Thanks!

MartybNz

amm
Just to make clear, I really like Houdini for home, evening experiments, ICE uniformity become somehow boring through the years - but, that constant ‘diving’, plus compositing app node style (no any modern 3 app looks like this) are parameters that rounds my willing force to zero, to use H for anything with deadline - while ICE can go.

To clarify are there other reasons too to not use H for serious work? Just want to be sure that these issues are the major reasons.

Thanks!

Of course it is not only that, this is only a not so good metaphor. First reason is Indie license, which effectively disables around 4/5 of possible work. Second is not enough of confidence, which is nothing unexpected. Felt enough confident with Softimage after let's say two years. Now is only one year of H, while I'm learning Maya, too.

Third is, that these days, work of one man band, or small studio, already is described by something like Max - or more correctly, it is ‘formed’ by Max and similar apps (where I feel familiar, already) - so even Softimage and especially ICE, represent a huge overload of abstractions. A lot of comments about ICE, by ‘small people’, on SI forums, actually were negative. I think it was a small exodus in ‘back to Lightwave and Modo’ direction, when ICE was introduced. Perhaps some my ICE stuff holds the record , of several pages in one day on old XSI Base, full of negative comments about been too technical. Now, when happened what happened, ICE is all good.

However that ‘compounding’ question, this is where I am, very personally, sensitive as an author of some ICE stuff, mainly used by small shops and individuals ( but not only them ). Where development was a sequence of simplifications, but at one point, finally got a few of artistic souls. able to promote it by their really attractive work. Or, people just figured out that there is no other choice , who knows.

So, from that, always amazingly interesting point of view, of ‘encounter of cultures’ (programmer and artist, here) , I'd believe any as much clear message is important - against somehow typical bombarding with all possible options. Perhaps it's not that much about combining the VOP and SOP context - ICE tree from link, full of switchers, is mine, ‘my artist’ won't go with all that. But, abstraction of creating an attribute in advance, while overridden parameter, somewhere later n network is not even greyed out - this is really unpleasant part.
Also, any as much simplified, streamlined default of saving and installing HDA's is welcome, while actual state is good enough, imho.
Anyway I hope I'll have some exact, finished ‘product’ to share (small hair system), the end of this year, so let's wait and see.

thank you for reading a long story

amm
First reason is Indie license, which effectively disables around 4/5 of possible work.

Perhaps the FAQ might change this:

Q. I am an individual working as a freelancer. Can I use Houdini Indie if I earn under $100,000 annually but I am contracted to do work for a large company that has revenues over $100,000?

A.

If you produce final renders or baked out data for the large company then they are considered a client and you may use Houdini Indie. If you want to share scene files and assets then you are partners and will require a commercial license.

https://www.sidefx.com/index.php?option=com_content&task=view&id=2908&Itemid=398 [sidefx.com]

amm
But, abstraction of creating an attribute in advance, while overridden parameter, somewhere later n network is not even greyed out - this is really unpleasant part.

Do you have an example of this. I'm probably too familiar with H to understand the issue.

Thanks as always for writing, always appreciate a coherent perspective!

MartybNz

amm
But, abstraction of creating an attribute in advance, while overridden parameter, somewhere later n network is not even greyed out - this is really unpleasant part.

Do you have an example of this. I'm probably too familiar with H to understand the issue.

Typical short example could be H wire object/solver. There's ‘width’ parameter which is doing what is supposed to do, as long it is ‘alone’. If ‘width’ is set earlier in static network, width parameter in DOP network acts as multiplier of what is previously set in another network. But it doesn't display anything about new state. To figure out what exactly a number means, one has to checkout both networks, possibly to MMB over nodes. Which is a double inspection, for something really basic.

Longer story is something like pic - it's ICEs (custom, but frequent) ‘strand function curve’, acts like ‘flying gradient node’. Under the hood it takes a previously set relative distance of hairs (like ‘hairdist’ in Mantra fur procedural), pass it through function curve, output is able to modulate any float attribute of same class. So, user is able to attach the gradient where he wants. Also it shows very exactly, what is modified, while ICE disables the overriden scalar input in ‘main’ compound.
This one is a ergonomic workhorse, used by everyone. Now in Houdini, so far I was able to re assemble the ‘flying gradient’ alone, in similar way to H 14 ‘attribute randomize’ but user has to type the name of modified attribute, (instead of ICE's plain plug-in), while input field of modified parameter is still alive, but does nothing. Maybe I'll find a way for disabling by using expression or something.
In short, I think there's some kind of too early pushing the user into ‘analytic mode’.

Regarding Indie license, very personally I'm more around assets for others, hard surface modeling or animation. However I'd believe majority of people are around rendering, where Mantra is, imho, really nice baby, but in category of CPU path-tracers. One would like Octane, V-Ray's interpolated GI, what not.

Very interesting. If I'm thinking of this correctly , this is an axiom of the Houdini Interpretation as pre-assigning a multiplying effect from Sops to Dops doesn't seem to have any negative connotations as one is mentally normalising, i.e. 0-1 as a divisor and above 1 as a multiplier, any values of the coefficent. I'll keep the Ice Interpretation in my thoughts to see where it may be more powerful.

The Indie license does indeed stop supplying non-baked animation.

Of course you can drive parameters with a node network - using CHOPs (“Motion FX”), it's just in yet another node context.

As for a flat network, I could see that it might be possible to kerjigger the UI so that you can have VOPs (or CHOPs) appear in SOPs and drive parameters via VEX or overrides. You could possibly have COPs in SOPs if you create specially typed outputs (gdp vs img).

I think it might end somewhere here before the execution methodologies really can't coexist. I must say it's fun to see images and 3D scenes built in Nuke, and I wonder if it another “Universal Context” or dependency contexts can at least view nodes in a unified manner.

We've spoken about all of this for many, many years, and only the devs might know how far they could dissociate the strict UI segregation from the node contexts.

MartybNz
Very interesting. If I'm thinking of this correctly , this is an axiom of the Houdini Interpretation as pre-assigning a multiplying effect from Sops to Dops doesn't seem to have any negative connotations as one is mentally normalising…

Nope, no automatic normalizing, just remapping values by curve. It is just this (ramp parameter)


The part about “clearness when something is modified by something else in ICE” is something like referenced values or override from chops. It's visualized in ICE by blue icon. (There is nothing like Show Dependencies in Houdini afaik).

I think that Anto Matkovic confuses parameters and attributes in Houdini because in Softimage ICE you can use only Get Data and Set Data nodes to set both parameters and attributes.
And you can use expression to set parameters of the ICE nodes, but it's not commonly used.

In ICE there is only single context (VOP) to set parameters and attributes. (This is very limiting and often very slow. imo).
In Softimage there is nothing like SOP network, there is linear Operator Stack that is evaluated from bottom to top. And ICE tree is just single Operator (like AttributeVOP). But it can affect different parameters and in limited way attributes across different objects (in similar way how VOPs could be used). All connections in Operator Stack happen behind curtain and aren't visible to the user.

Guys,

what I've talking is closest to description by Jeff: 'What you describe is a parallel workflow where you use VOP nodes to construct vex logic to be read in to a SOP at the top".
No need for anything additional, especially not self convincing, imho.