Hi

I'm Maya to Houdini user.
I've been always having problems with attribute names.
Houdini accepts sometimes $ID or id or v ot vel or velocity or v or v etc…
I feel Houdini's interface is so messy. so many it's own rules…

Is there any rule for attribute name about “$” or uppercase or lowercase?

hosok2
Hi

I'm Maya to Houdini user.
I've been always having problems with attribute names.
Houdini accepts sometimes $ID or id or v ot vel or velocity or v or v etc…
I feel Houdini's interface is so messy. so many it's own rules…

Is there any rule for attribute name about “$” or uppercase or lowercase?

hi hosok2!

We all completely understand your feeling - at least I do. After many years there are still some moments that I'm loosing the clue but it's not sooo bad after you get the basics. After all whole this stuff can make you life easier. (specially if properly documented ).

1. There are two ways to get to data saved on geometry or node
(and they slightly differs in what they actually are):

a) attributes:
- they stay on cooked geometry across your scene
- they are most often lowercase: uv, v, vel, life
- you need an expression to get to them: point(), prim(), detail().
- they are SOP's entities. They don't exist in other contexts (+ POP which is somewhat SOP related )

b) local variables:
- they are UPPERCASE,
- they are accessible via $ + name: $PT, $MAPUV
- they are NOT available across the whole network. They exist in context of particular node. Some of build-in variables are quite common, like $PT, $PR, $NPT, some are very specific.
- almost every node in Houdini in every context has its own set of variables. This is not SOPs specific feature.


2. Both local variables and attributes can refer to the same data in SOPs. But they don't have to. You can have local variable that correspond to some feature of particular SOP and has no equivalent attribute. Variable is a shorthand to some info that is useful, while attributes are what you expect: data saved on points, prims etc. So they are not the same thing.

3. Create a Box SOP and append AttributeCreate SOP. See the parameters:
you have a “Name” and “Local Variable” there. Name it somehow and MMB on the node. You will see the info about attributes and local variable mapping (upper cased!) created for you. This is how it works.

4. When you start dealing with some new node (SOP/CHOP/COP whatever), always check in Help what kind of variables it can serve to you. Many useful stuff… . In addition you have a liberty to create any number of your own stuff, both attributes and local variables. If you create it in SOP context, attributes will be saved on geometry file for example, variables most likely not… you get my point…

hope this helps a bit,
sy.

Hello,
just read this and found it very interesting. Would it be possible for someone to copy this post over to the odforce wiki maybe add an ‘Attributes’ entry. I spent quite a bit of time trying to get to attributes and local vars and it all was a bit confusing until now.

Thank you,
Fabian

thanks for very quick and detail answer!

Fabian
Hello,
just read this and found it very interesting. Would it be possible for someone to copy this post over to the odforce wiki maybe add an ‘Attributes’ entry. I spent quite a bit of time trying to get to attributes and local vars and it all was a bit confusing until now.

Thank you,
Fabian

I'm not really sure if this should be myself. I think some Grand Master could take a look first since even I have a feeling that I didn't covered this point correctly and clearly in full extend

sy.

• Here's an alternate version:
  
  Attributes:
  * Attributes are user defined data objects that can be “embedded” in your geometry.
  * RMB on a SOP, and open a “Spreadsheet” to see a full display of your attributes.
  * Attributes can be different types (int, float, float3, vector, string)
  * Any of these types can be applied to different levels of detail in your geometry structure. (vertex, point, primitive, detail). As an example you can have a per-point float attribute, or a detail float attribute that applies to all the geometry.
  * User created attributes are lowercase by common convention. It is possible to have user created mixed case or upper case attribute names, but the code police will generally frown on you. (Exceptions include some SESI factory attributes such as P and N which use an old CG (prman etc) convention for such attribute names to be short and capitalized.)
  * Attributes can be manually user generated in vex/vops (addAttr, Parameter export) or using the attribute create SOP.
  * Attributes can be auto-created by a number of SOPs. As an example, the various “Compute Normals” SOP toggles will add an “N” attribute
  
  Variables
  * Variables are like “pointers” or “aliases” to your attribute data. They are merely a shorthand way to look up a particular attributes value.
  * Technically, (and without getting into python yet) there are 4 types of variables that can be used in parameter expressions in Houdini. 2 are pure geometry variables, and 2 are hscript variables that do not point to geometry attributes. We're mainly talking about geometry here, but it's good to be aware of the 2 hscript variable types:
  - Local hscript variables - Local to a particular hscript .cmd file. These are set in a .cmd file, and die when that .cmd script finishes running. For more information enter “help set” in a textport.
  - Global hscript variables - Things like $F $PI or $HIP. Alt-Shift-A to see more. Do “help setenv” in a textport for more info.
  - Geometry Local variables - Auto-created from attribute data by certain SOPs. Only exist in that SOP and dis-appear in next SOP in chain. The point SOP is a good example of a SOP that has these.
  - Geometry Detail Defined Variables - These user defined variables are created by users in atrribCreate SOPs, addattr VOP etc. These variable mappings are stored in a “varmap” detail attribute, and thereby persist across multiple SOPs. These are uppercase by convention, but as with the attribute names variants can be used at the cost of system legibility.
  
  Python
  In a python scripting context, everything is a variable pointing to some hidden data object. There's data in there somewhere, but python handles that automagically. There's a case to be made for Houdini managing all attribute data in the same way (automagically creating variables and managing attributes under the hood), and some Production Houses have built tools that kind of work this way (Pointastic anyone?). There's also an argument to be made for Houdini not second guessing or being smart for the user/TD though, and probably thats part of the reason why Houdini is widely preferred over some of it's competitors.
  
  Thats it for SOPs as far as I know. Someone should add caveats for POPs.
  
  Cheers