Korny Klown2
How do I know that this node is so intelligent? This behaviour is not documented in the help, that leaves me guessing what a node is capable to do.

Simply run a test. Your question was ‘ shouldn’t the primindexes change? Have a look at the spreadsheet.

Don't absolutely rely on the documentation, you have to confirm hunches yourself too.

Out of interest, take a look at this page:

"http://www.worrydream.com/# [worrydream.com]!/LearnableProgramming/"

Especially the 'Explain in Context' section

I'm making the assumption that if Houdini had a version of this system to explain ideas such as Attributes then it would be much easier. Let us know your thoughts.

Thanks!

SYmek
I hear you. Python in parameters is a long standing issue, I'm usually not conscious of it, because I hardly use Python here. But there is a little confusion in your post, so I'll try to explain. See bellow.

I mainly use Python because I'm most familiar with it since I use it in Maya and Nuke and as “standalone”.

SYmek
Houdini couldn't use os() perhaps because os is one of the most commonly used module [docs.python.org]in Python if not for other reasons.
…
$ at the front of $OS says: I'm a local/global variable, not a string. Type \$OS to turn it into a string and see how Houdini doesn't know what to do with that.

To address this, let me introduce the idea of having all Python functions start with a “_”. This would probably be a very consistent convention.
_pt(), _tx(), _os()

SYmek
BTW2 single Alt+LMB for setting keyframe/toggling Python expression isn't that bad after all
…
Because you put frame() into numeric parameter, where things are simple: anything which is not a number is an expression.

Contrary to this you use $OS in string parameter, so Houdini can't know if a string you have just typed has to be treated literally or as an expression to evaluate.

It's not only that. I also always have to take care if I am in the right state of the parameter input, whether I am in stringstate or in expression state. Maybe this is not a big deal but yet it can be optimized. See attchment 1 and for those who don't want this feature see attachment 2.

MartybNz
Out of interest, take a look at this page:

"http://www.worrydream.com/# [worrydream.com]!/LearnableProgramming/"

Especially the ‘Explain in Context’ section

I'm making the assumption that if Houdini had a version of this system to explain ideas such as Attributes then it would be much easier. Let us know your thoughts.

Thanks!

Sounds like a great idea, he really has some nice concepts but wasn't it you who told about company resources Setting this up would be an intense task. I think it would be a lot more benificial to redesign Houdini in a way so that it is less confusing and more inuitive in the first place and then we can talk about explaining the things that can't be designed any easier. I know that many Houdini users think that Houdini already is at that point, where it can't be designed any easier but as you probably already know about me, I don't think so

Korny Klown2
To address this, let me introduce the idea of having all Python functions start with a “_”. This would probably be a very consistent convention.
_pt(), _tx(), _os()

Bad idea, leading underscore in python indicates that attribute or method is intended to be private.


Just learn, that if you want to write expression put there keyframe first than write expression into that field, that is universal (across hscript and python).

Extended expression editor (Alt+E) is handy if you write longer expression or want to debug it.

I don't have any problem to distinguish between expression and it's return value, but if you really need it simple change of border's color (border of the input field e.g. yellow) or font change when expression is displayed should be enough.

pezetko

Korny Klown2
To address this, let me introduce the idea of having all Python functions start with a “_”. This would probably be a very consistent convention.
_pt(), _tx(), _os()

Bad idea, leading underscore in python indicates that attribute or method is intended to be private.

Ok, then no leading underscore but some other simple prefix to have easy equivalents. I'm just looking for something like
$OS = prefixos()
$TX = prefixtx()
$PR = prefixpr()

pezetko
Just learn, that if you want to write expression put there keyframe first than write expression into that field, that is universal (across hscript and python).

Yes it is universal but neither necessary nor efficient. The question is: Should it be universal throughout HScript and Python? No.
My attatchments show that it is easily improvable and still optional so you can keep your habits but others have the option to choose an alternative.

pezetko
Extended expression editor (Alt+E) is handy if you write longer expression or want to debug it.

Yes, that's why I want there to be a button within close reach.

As for writing expressions, I have seen that new users to Houdini from other apps want to write everything in code. That's fine to get up and running quickly but for the most part, that's not what you do in Houdini. You wire nodes together. That means you have to find the nodes, same way you find functions in code. In comparison you write very few expressions or wire together very few VOP networks to work and manage attributes. You use the SOPs more than most.

As attributes go, you can use Attribute Create SOPs with correct signatures on your attributes and then all subsequent SOPs will transform and manipulate those attributes for you automatically. Another big difference from other apps where this is foisted on the td to manage. This allows you to quickly prototype your work with SOPs with the understanding that they try to keep your attributes in tact. This means you can front load attributes way up the chain and expect them to filter down. It also means you can construct SOP networks that seamlessly work on any input attributes as you wish. This approach allows any artist to quickly re-work parts of their network at any time. This friendly approach encourages refinement by any artist, not just the advanced TD's. All the artist needs to understand is how the node works, not the actual code or logic driving it.

It is a different approach. Not bad or good. Different. And this is proven over 20 years in practice. In some respects this is backwards to the approaches you take in other apps.


And if you do write expressions to add and modify attributes, I'm using the various wrangler operators which use actual mantra shader code (vex) which allows you to use this wherever you want. This is used everywhere in Houdini these days. Not Python nor hscript.

Using these wranglers also gets you threading as VEX is mostly threaded when you want to write expressions.

Python is generally not used when iterating over large geometry sets as it is not as fast as vex. It's not threaded when you write either Python or hscript expressions in geometry SOP parameter fields. Everywhere else? Sure Python is what you use.

Hope this helps.

Korny Klown2
I mainly use Python because I'm most familiar with it since I use it in Maya and Nuke and as “standalone”.

I don't want to convince you endlessly, and I understand interface glitches you may find annoying, but I also don't get this push towards making Python the only feasible choice for any cost.

Python as any other language isn't the best option for everything. Any savvy user sooner or later starts using specialized tools for a purpose. At first people feel comfortable with one syntax, after some time, you easily jump between many, because after all it's only a syntax. XSI had 5 different languages, none of which was done right, you know… You use Python in Nuke, yes, but Nuke isn't expression heavy. Once performance is in concern, you stop doing Python. Take a look on every new tool out there: Fabric Engine? Custom language. Nuke's new Blink engine? Custom language…

Anyway, two state of parameters is annoying and after years of using Houdini I find myself lost and confused sometime too.


Also:

def TX():
if isinstance(hou.pwd(), hou.ObjNode):
return hou.pwd().evalParm(“tx”)
elif isinstance(hou.pwd(), hou.SopNode):
return hou.lvar(“TX”)
else:
return 0

def OS():
return hou.pwd().name()

hou.expressionGlobals() = TX
hou.expressionGlobals() = OS

Copy/paste it into Windows-> Python Source Editor and check if this really makes any difference. You can even use TX() on objects instead of ch(). I bet after a week of really using Houdini, you'd start hscript expressions…, which are - unlike Python - perfectly tailored for evaluation in parameters.

take care,
skk.

ps o I don't see the rationale for making double parameters window. One of the greatest advantages of Houdini interface is the you can put expression almost everywhere. Making twice as many parms as now, half of them with seriously jeopardized usability sounds strange to me. What I do like is that any parameter clearly indicates its state.

Just checking that AttriCreate is any clearer now?

Setting this up would be an intense task

The reward might be worth it.

Maybe Houdini 18 comes with something similar. It's next level efficiency for people. Everyone other software company is still busy trying to catch Houdini on node networks.

SYmek
ps o I don't see the rationale for making double parameters window. One of the greatest advantages of Houdini interface is the you can put expression almost everywhere. Making twice as many parms as now, half of them with seriously jeopardized usability sounds strange to me. What I do like is that any parameter clearly indicates its state.

What I actually meant was to introduce this double parameter for string parameters, like group name and such. Since numerical parameters recognise expressions automatically it's not needed there but for string parameters that, as you said, can't distinuish between expression and normal string input it makes sense to have a field where you can type in a string and one field that is especially for expressions. This way the user doesn't have to take are about what state a parameter is at the moment and to set a keyframe each time.

I was trying to make a basic DA that procedually (of course) creates a building from a curve. I wanted to use a custom attribute in a more or less senseful way. As far as I understand that, a detail attribute is not bound to a geometry and available everywhere in the network. I tried it and it doesn't work here.
What am I doing wrong?

Please don't finish it for me, just tell me what is wrong. I want to fix it myself, just for practice sake.

There are many problems in the file:

1. You can't access an attribute just by using the name: height in this case.
You have to use $HEIGHT

2. But even then you can't access this attribute Because you are in a brand new generator branch where there is no height attribute. You can MMB click on line1 to see this.

3. So you have to use the detail expression. In Python it's a different function, so you have to switch to hscript to use the detail function:

detail(“../attribcreate1”, “height”, 0)

Then it will work.

So a detail attribute is in fact NOT available for the entire network?

No Detail attributes are not global. They are a part of the given geometry. More specifically, to geometry that actually has a Detail Attribute. Use the MMB to see. Actually use MMB all the time to query SOP contents to remove any ambiguity.

I use the MMB all the time. If I am on a SOP, I MMB on the SOP coming in to this SOP. I see what attributes are available to me: point, vertex, prim, detail. If they have a signature, I can use them directly with the $ if the SOP in question can work with that type of attribute. For example a Point SOP can read/write point attributes. Vertex SOP read/write vertices. Primitive SOP read/write primitive attributes. There is no Detail SOP. Use the detail() expression.

You can use various expressions to reference attributes in to any SOP parameter from any target SOP using the expressions:

point()
vertex()
prim()
detail()

These expressions were ported to vex so you can use an Attribute Wrangle SOP to fetch these attributes as well.

Korny Klown2
So a detail attribute is in fact NOT available for the entire network?

Why would you need an AttributeCopy node if it was global?

Korny Klown2
So a detail attribute is in fact NOT available for the entire network?

It is avaiable FROM entire network, but exists when was created and bellow as long as you don't delete it.


I might be wrong but I have this feeling that you miss one entariely pivotal point about Sops. Unlike ICE network which defines the entire state of a geometry at once , SOPs are the chain of actions performed one after another on the same piece of geometry.

This really is a pipe with data pushed down through the nodes. Create a sphere push down, deform, push further, add color, push further etc (pull for that matter but it's not important now). that's why an attribute isn't available above node it was created, but you can use it anywhere down the chain and from anywhere. It´s literarily there, because leaving aside some recent optimization, Sops are sending between each other whole geometry as if it was a bgeo file…

Well, first of all I wanna thank you guys for the help. With the detail expressionit works, although you can easily imagine that (again) I'm quite dissapointed that there is no Python equivalent. At least I can't find it. I assume that its name has nothing to do with detail so I don't know what I'm supposed to search for.

SYmek
Python as any other language isn't the best option for everything. Any savvy user sooner or later starts using specialized tools for a purpose. At first people feel comfortable with one syntax, after some time, you easily jump between many, because after all it's only a syntax. XSI had 5 different languages, none of which was done right, you know… You use Python in Nuke, yes, but Nuke isn't expression heavy. Once performance is in concern, you stop doing Python. Take a look on every new tool out there: Fabric Engine? Custom language. Nuke's new Blink engine? Custom language…

I don't mind if a programm has several scripting/expression language. I've never used XSI, so I can't really judge, but probably there are 5 different laguages but most likely not all for the same task. It's not that HScript and Python cover two totaly different fields in Houdini. They're pretty much used in the places together so I assume a decent amount of equivalence. Let's take a look at Maya:
MEL: polyBevel, Python: polyBevel()
MEL: deleteAttr, Python: deleteAttr()
MEL: skinCluster, Python: skinCluster()
This is how it's done right.

SYmek
I might be wrong but I have this feeling that you miss one entariely pivotal point about Sops. Unlike ICE network which defines the entire state of a geometry at once , SOPs are the chain of actions performed one after another on the same piece of geometry.

This really is a pipe with data pushed down through the nodes. Create a sphere push down, deform, push further, add color, push further etc (pull for that matter but it's not important now). that's why an attribute isn't available above node it was created…

I do understand that very well but this downstream theory isn't quite correct either.
In a copy SOP you create a variable in the Stamp tab and you then use this variable on a node that is above the node it was created. So you actually evaluate a variable that isn't created at that point in time. I just thought something similar is possible with a detail attribute.

MartybNz
Why would you need an AttributeCopy node if it was global?

Unfortunatelly this AttributeCopy doesn't work either since you can only wire it after the line SOP, so it's still not present there.
All nodes dealing with attributes should have an attribute input, like COP nodes have a mask input on the side.

Korny Klown2
All nodes dealing with attributes should have an attribute input, like COP nodes have a mask input on the side.

A warty node is the pure definition of ugly UI i.e. proper compositing in Nuke rarely uses the mask input. You use a node like the ShuffleCopy to bring a channel in as a mask, amatures use the mask input

Think of Attributes as channels in Nuke, you create or copy them into a stream for processing.

MartybNz
A warty node is the pure definition of ugly UI i.e. proper compositing in Nuke rarely uses the mask input. You use a node like the ShuffleCopy to bring a channel in as a mask, amatures use the mask input

Think of Attributes as channels in Nuke, you create or copy them into a stream for processing.

Yeah, that's right and in some way I actually am thinking about them like channels in Nuke but there's a slight difference. In Nuke I can shuffle in a channel at any point in the nodetree, which I can't do with attributes in Houdini. In this example it's not possible to “shuffle” that attribute in above the line SOP, so you can call compositing with the mask input proper or not but at least it's there, as an option

Is there something like the shuffle node in COP networks? So far I was using this mask input, which I think isn't THAT ugly

Korny Klown2
…With the detail expressionit works, although you can easily imagine that (again) I'm quite dissapointed that there is no Python equivalent.

Agreed that this is one of confusing example where SESI wanted to fix old mistakes and has called Python detail() expression hou.Geometry.globalAttrib().

I don't mind if a programm has several scripting/expression language. I've never used XSI, so I can't really judge, but probably there are 5 different laguages but most likely not all for the same task.

Actually not. They were originally as a complete alternatives, want VBScript/JavaScript/Perl/Python? Welcome.

It's not that HScript and Python cover two totaly different fields in Houdini. They're pretty much used in the places together so I assume a decent amount of equivalence. Let's take a look at Maya:
MEL: polyBevel, Python: polyBevel()
MEL: deleteAttr, Python: deleteAttr()
MEL: skinCluster, Python: skinCluster()
This is how it's done right.

I couldn't disagree more. Yes, this was kind of political choice, where Python usability has been sold for Mel familiarity, but how controversial this decision was one can see by how quickly native implementation was replaced by power users with PyMEL. The situation was actually a way different, because unlike Houdini, Maya has tones of mel legacy code and mel users, the burden which cannot be ignored. Also, it was much easier to not to design new scripting interface, that is something that took SESI couple of releases. Honesty speaking one obvious reason for that was, that Houdini didn't have decent scripting interface, because hscript (not hscript expressions!), is much too old school. Hscript is mostly obsolete these days, fully replaced by Python. Hscript expressions serve different purpose, serve it well in my opinion, and if they were to be replaced it's more probably with something like CVEX, which adds with every release original expressions functionality.

Now, back to Maya, the familiarity effect last two weeks, and then you end up with usability issues for the rest of the time. Adsk decision for mirroring MEL commands with Python was good only for people using ~15 commands casually. Anyone using scripting intensively curse Adsk. It's ironic you compare the worst Python implementation in business with one of the best saying how good is to actually break Python, lost its object oriented nature and mirror it with ancient and horrible dialect that no one really wants to use these days. Thank god ,the Foundry wasn't doing the same with TCL to Python transition in Nuke…

I do understand that very well but this downstream theory isn't quite correct either.
In a copy SOP you create a variable in the Stamp tab and you then use this variable on a node that is above the node it was created. So you actually evaluate a variable that isn't created at that point in time. I just thought something similar is possible with a detail attribute.

Well, the truth is, it's all about upstream, not downstream. Node with display/render flag asks for a geometry its input node and so one recursively. Does't matter. The theory is quite correct. CopySOP isn't any exception from that. That's why you have to use stamp(), which the only reason to exists is to ask downstream node for the attribute existing there. It's a mean for reverse flow, but does't change the fact, that attributes are created in a particular place and accessible pretty according to common sense.

MartybNz
All nodes dealing with attributes should have an attribute input, like COP nodes have a mask input on the side.

Any node with more then one input have this kind of attribute input you mention. Because this exactly the reason for multi input nodes, to access others geometry's attributes. Interesting idea though. The problem with compositors approach is that you have well defined geometric domain, that is pixels rows an columns to match elements between inputs. In case of differences you interpolate them. Rather hard to achieve with something like, say, poly grid and nurbs torus…

EDIT:

Unfortunatelly this AttributeCopy doesn't work either since you can only wire it after the line SOP, so it's still not present there.

Sorry, haven't seen your file before. You can actually use AttributeCopy there. Just use the attribute after you have copied it… Leave Line Sop alone, copy your attribute, add PointSOP for example, ad type in TY field the same expression with $PT multiplication:

detail(“../attributecreate1”, “height”, 0) * $PT

This isn't best example for attributes usage at all (easier would be using channel raferenceing), but as I understand this is just an example.

Korny Klown2
Yeah, that's right and in some way I actually am thinking about them like channels in Nuke but there's a slight difference. In Nuke I can shuffle in a channel at any point in the nodetree, which I can't do with attributes in Houdini.

You can, with AttributeCopy, VOPSop or any VEX involved operator for that matter (wranglers).

Is there something like the shuffle node in COP networks? So far I was using this mask input, which I think isn't THAT ugly

Checkout ChannelCopy COP!