Forums Technical Discussion geometry attribute naming: are hierarchical names possible?

geometry attribute naming: are hierarchical names possible?

   1334   3   1
User Avatar
shaegler
Member
4 posts
Joined: Aug. 2017
Offline
 
hi houdini users,

we have a custom C++ SOP which creates a large number of geometry attributes (mostly on primitives). we are looking for the best way to name these so that they are convenient to use in VEX builders or other nodes. is there a way to structure attribute names? a simple two-level hierarchy would already be enough.

some examples: our internal names use a dot “.” to semantically group attributes, e.g. we have “color.r”, “color.g”, “color.b”. these naturally translate to color, color, color. but we also have “opacitymap.{su,sv,tu,tv,rw}” (tex coord xform) or non-material attributes like “groundfloor.{area,volume}” where simple indexing is not satisfactory. we've noticed that the dot “.” itself is not allowed in houdini attribute names.

TIA & best,
simon
 Report
User Avatar
neil_math_comp
Member
1743 posts
Joined: March 2012
Offline
 
If you're creating something like colour, it'd be best to make it a 3-float attribute named Cd, so that most things in Houdini will recognize it as the colour. As far as I know, VEX should support @Cd.r, @Cd.g, and @Cd.b, as well as things like vector colour = @Cd;or @Cd[0], @Cd[1], and @Cd[2]. It has special handling that guesses that @Cdis a vector type; if you name it something else, you'll need to do something like v@color.

For more general sets of attributes that aren't naturally tuples, I'd recommend using underscore in place of dot.
Writing code for fun and profit since... 2005? Wow, I'm getting old.
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
 Report
User Avatar
shaegler
Member
4 posts
Joined: Aug. 2017
Offline
 
thanks, that's the way we're going to handle it.

on a related note: is there HDK documentation about the exact attribute name syntax, e.g. about the allowed character set? i failed to find that… background is that we do “communication” between two custom SOPs via (primitive) attributes and need to escape the attribute names to/from houdini.

best,
simon
Edited by shaegler - Dec. 14, 2017 10:15:59
 Report
User Avatar
neil_math_comp
Member
1743 posts
Joined: March 2012
Offline
 
Good question. You can call GA_AttributeSet::isValidName()with a prospective name to check if it's allowed. It mostly just calls UT_StringWrap(name).isValidVariableName()(calling the isValidVariableName function in UT_String). I think UT_String::forceValidVariableName()called on a UT_Stringwould take any characters in it that aren't allowed and replace them with characters that are allowed. You'll just have to be careful not to provide an empty string, since I think it won't change that to a valid name.

From UT_String.h:
// This will change the string into a valid C style variable name.
// All non-alpha numerics will be converted to _.
// If the first letter is a digit, it is prefixed with an _.
// This returns 0 if no changes occurred, 1 if something had to
// be adjusted.
// Note that this does NOT force the name to be non-zero in length.
// The safechars parameter is a string containing extra characters
// that should be considered safe. These characters are not
// converted to underscores.
int forceValidVariableName(const char *safechars = NULL);
// Returns true if the string matches a C-style varaible name.
// The safechars are not allowed to be the start.
// Matching forceValid, empty strings are considered valid!
bool isValidVariableName(const char *safechars = NULL) const;
Writing code for fun and profit since... 2005? Wow, I'm getting old.
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
 Report
  • Quick Links