Hello All,

After working with Houdini for about a year I have come to the conclusion that SideFx does not have any ‘official’ naming convention in place for the naming of parameters. This would be my wish for Houdini 16.

Consider material parameters. In H14 we have a Mantra shader with an emission intensity parameter called “emit_int”. In H15 we have a principled shader with an emission intensity called “emitint”.

Some times there is an underscore between two words and sometimes not. Sometimes there is camel case or not. Sometimes the parameter is pronounceable in English, sometimes not. Sometimes there is a mix of camel case and underscore such as “diff_colorTexture”. Then there is “dispTexTexuture”

It seems developers can just make up parameter names however they see fit. :?:

IMHO all parameters should be pronounceable in English without any additional explanation in a conversational manner. And by that I ask you to image a scenario where two people are discussing how to change a parameter at the company picnic. Person one says “Lets increase the diffuse intensity by a factor of two”. The second person would be able to derive from that statement that the parameter that person #1 was referring to was indeed “diffuse_intensity”, not “diff_int”.

I know, I know it will upset people if you change those old tried and true names but quite frankly every release of Houdini, even the sub releases within a version, always break something. I'll open up a project I just worked on a day ago and the new version claims some value has changed or is no longer available.

Remember, no shortcuts for words, then you have to explain the shortcut. So yes, sub surface scattering will be named “sub_surface_scattering” not “sss” or “subsrfscat” or anything else. it should be spelled like it is said. Spaces are implied to be underscores.

I say bite the bullet SideFX! Write up a document that proposes a naming convention and stick to it.

It may be a good idea but the irony :twisted:

Enivob
IMHO all parameters should be pronounceable in English without any additional explanation in a conversational manner.

Google 'english language history'
What is the English language made up of?
So, English is made of Old English (closely related to German and Dutch), Danish, Norse, and French, and has been changed by Latin, Greek, Chinese, Hindi, Japanese, and Spanish, and more words from even more languages

I agree that it would be good to have a naming convention for parameters and functions. I thought SESI would have one and this would be caught in the code reviews.

There are some VEX functions that are very shortened and hard to understand what they do. There are some that uses underscores, some don't. hedge functions and sensor VEX functions have underscores for example.

Geometry functions are hard to memorize also because they are just very short and confusing. IMO it would be better if they were more descriptive: getvertexfrompoint instead of pointvertex.

These kind of stuff should be discussed internally by SESI under the supervision of a software architect.

I don't think SESI will rename existing things because of backwards compatibility. Though there were cases of trivial function renames that broke backwards compatibility i.e. neighbour(s) instead of getneighbour(s) that existed before so I don't know what the criteria to make such breaking changes is.

For me I don't mind breaking changes as much if it's for the better.

i agree that sometimes yes they are confusing because of truncation or abbreviation

however, when using them in a procedural manner in code or as attributes driving a shader from particles, points etc I dont want to be typing 32 character long names with tons of underscores in them

imagine looking at the spreadsheet of particle attributes with this_is_the_speed_of_the_current_particle, diffuse_color, blending_value_from_shader_a_to_shader_b, ramp_driving_attribute_for_color_mixing

sometimes it is better to leave a shortcut name as the attribute and leave the description to a help doc or mouse hover over the parameter itself.

that being said, SESI should at least unify the names when possible.

Yeah, kinda confusing sometimes.

My thoughts if I am allowed to:

Doing it “the right way” with the python hom would be a great idea. As that has still many “not yet implemented” ‘n’ like.

And if I do not like to type in particlesystem(“x”).forces.Blah, I'd use

p=particlesystem(“x”).forces and then p.Blah…

And I would really love it, if the docs get more exhaustive at some point. More examples. Clear structure. Class/Object reference. Hint: let a “noob” do a specific task, and watch how the challenge is being approached, where needed information is expected, and also ask why…

Sometimes for an expert of a field things seem to be logical, where a not so much professional/educated one sees no sense at all…

Took me hours to get to a point where I was able to build a polygon with python. Do not ask me where the problems were, just got over it…


BTW:
Have I overseen, how to compile python nodes to *.pyc ? Not really needing it now, but nice to know.




THX for your time

Does code completion could be helpful ?

Believe me: imposing something like this for Houdini 16, or really any Houdini version in the near future would probably result in all major customers demanding that we undo it immediately.

Why? We can't rename existing parameters. We just can't. We *very* much wish that we could, but even parameters with completely meaningless, misspelled, or even misleading names are stuck forever, because no matter how esoteric the parameter may seem, some unimaginably complicated asset written by someone who no longer works somewhere uses it by name, but not with an explicit path, for complicated reasons, or it's in some external VEX file or Python script or render farm script, and that asset/script will be broken in some non-obvious, difficult-to-track-down way when the parameter is renamed. We know this, because it's happened when people thought it was safe to change a bad parameter name before.

The *only* thing we can do, (apart from changing the labels, which wouldn't address the concern expressed here), is provide *new* nodes with the same name but higher node version and changed parameter names. Of course, everything using the old nodes would eventually need to be ported over to use the new nodes, else we'd forever have two copies of every node to maintain. I'm not saying that's never going to happen, and it's certainly not my place to make that call, but it could be a huge amount of work, and rather risky, (e.g. there are side issues like that all of the help docs for every parameter would need to be correctly updated so that the connections between parameters and their docs aren't lost), so it's a question of whether it'd actually be worth it.

ndickson
Believe me: imposing something like this for Houdini 16, or really any Houdini version in the near future would probably result in all major customers demanding that we undo it immediately.

Why? We can't rename existing parameters. We just can't. We *very* much wish that we could, but even parameters with completely meaningless, misspelled, or even misleading names are stuck forever, because no matter how esoteric the parameter may seem, some unimaginably complicated asset written by someone who no longer works somewhere uses it by name, but not with an explicit path, for complicated reasons, or it's in some external VEX file or Python script or render farm script, and that asset/script will be broken in some non-obvious, difficult-to-track-down way when the parameter is renamed. We know this, because it's happened when people thought it was safe to change a bad parameter name before.

The *only* thing we can do, (apart from changing the labels, which wouldn't address the concern expressed here), is provide *new* nodes with the same name but higher node version and changed parameter names. Of course, everything using the old nodes would eventually need to be ported over to use the new nodes, else we'd forever have two copies of every node to maintain. I'm not saying that's never going to happen, and it's certainly not my place to make that call, but it could be a huge amount of work, and rather risky, (e.g. there are side issues like that all of the help docs for every parameter would need to be correctly updated so that the connections between parameters and their docs aren't lost), so it's a question of whether it'd actually be worth it.

On that note, what's the reasoning to rename getneighbour(s) functions that causes some assets to be broken? I just assumed SESI wants to improve things even if it means breaking things, which is fine by me as I proactively update my stuff.

This new version of nodes/functions make sense. The good thing is the old nodes/codes can warn and also these problematic nodes/functions are still a drop in the sea compared to the good ones.

pusat
what's the reasoning to rename getneighbour(s) functions that causes some assets to be broken?

It looks like that one was done rather hesitantly, though I don't know specifics, apart from that the change broke 4 of our OTLs and 13 of our regression tests, and probably many more for ours users, and that's just one change. Imposing a parameter naming convention all at once would mean changing or deprecating almost every node ever placed, and changing or deprecating almost every asset ever created.

Besides: naming conventions = holy-wars.
There can be as many naming conventions as human brains (that language will permit), so imposing *the one-true naming convention* will require much cracking of otherwise productive skulls.

ndickson

pusat
what's the reasoning to rename getneighbour(s) functions that causes some assets to be broken?

It looks like that one was done rather hesitantly, though I don't know specifics, apart from that the change broke 4 of our OTLs and 13 of our regression tests, and probably many more for ours users, and that's just one change. Imposing a parameter naming convention all at once would mean changing or deprecating almost every node ever placed, and changing or deprecating almost every asset ever created.

Unless Houdini stored parameters not by name but something else

pusat
On that note, what's the reasoning to rename getneighbour(s) functions that causes some assets to be broken? I just assumed SESI wants to improve things even if it means breaking things, which is fine by me as I proactively update my stuff.

We are willing to break things if it is enough of an improvement. But those times we do, we are inevitably swiftly reminded why it should be taking with caution. I still run into getneighbour() problems and it changed in 13.0…

There used to be two getneighbour functions
int getneighbour(filename, ptnum, neighbournum);
int getneighbour(ptnum, neighbournum, input);

Houdini 13 saw a concerted effort to get Attribute VOP, using CVEX, to be as good as the Point VOP, which used SOP VEX. We also wanted it as easy to use as the expression language. One of the things we did was ensure anywhere we had a filename to get geometry you could instead provide an input number. If you look at the signatures above, you will see they are contradictory. If you got used to putting input number first (like all the point() functions…) it would be a bad situation.

We can't just make the signature
int getneighbour(input, ptnum, neighbournum);
because those parameters are all integers so we'd just silently break everyone's code. So I took the scary step of explicitly breaking everyone's code…

As for the too short VEX functions… This is quite a good point. There is tension here between names that are easy to type, and names that are readable. VEX is often used as a quick scripting language, so it is important to have as little baggage as possible. A lot of the function names actually pre-date VEX as they are lifted from our Expression language. This is meant to ensure the maximum transferability. If you know point() in VEX, you can use it in a parameter, or vice-versa. But I do agree it is not the first name that would spring to mind to fetch a point attribute!

Something I noticed today was that the lighting model vop was depreciated in h15. Not a big deal because I could just do opadd lighting to get one.

I was trying to use it as that is the only way I know how to create an isotropic bsdf in vops (not inline code). Is there a newer vop that can create this bsdf?