Documentation: Questions regarding usage and implementation of Geometry Name Expressions

[hybridherbst]

Hi, I have some understanding and implementation questions for Geometry Name Expressions. I'm numbering them so that it's hopefully easier to answer specific ones, and ideally some clarifying language can be added to the spec.

1. The spec mentions that a/b/c matches matches a/b/c and a/b/c/d, but fails to mention if it should also match a/b/cd and if not, why not. (I would assume it does not match the latter, but I can't derive that from the spec.)

2. Is it correct to assume that //My Node Name is supposed to match My Node Name at any depth?

3. How would a runtime differentiate between a string that's supposed to be a geom expression, and a string that just happens to be a fancy node name? E.g. I can easily have nodes named Hello * World [4] in a glTF file (and have seen that in the wild), but it looks to me like that would be interpreted as an expression, not a node name. Is there a way missing in the spec to escape characters?

4. Same as the last question, it's not clear to me if forward slashes in node names / can be escaped somehow. I understand some formats like OpenUSD don't allow slashes in node names, but others (glTF, FBX, ...) allow it.

5. A comment in Geom.h mentions // @todo Geometry name expressions are not yet supported. – so which parts are supposed to work, e.g. can I assume prepending  // or using * should work, or should I assume nothing but exact name matches works?

6. From an implementation perspective, since materialassign "falls through" and later ones override earlier ones, it seems that a naive implementation will easily be of quadratic complexity (each node needs to be checked against each materialassign). Thus, it's probably a reasonable strategy to match in reverse (starting with the last item) and removing matches from the set of nodes to check. Is that a valid assumption?

7. For the [a-z]syntax, is the assumption that "character preceding" and "character following" mean: in ASCII? Or is it meant more strict? I assume that's the intention but it could probably be spelled out... e.g. right now it's not clear to me if [A..z] or [Y..b] (which includes Y,Z,a,b) are allowed, and if [7..A] also matches the characters ? and @, besides others, because they're in-between 7 and A in ASCII.

8. These two sections in the spec are confusing to me:

   1. Geometry Name Expressions:

      the name /a/b/c//*// will match all geometries at any level below /a/b/c

   2. Assignment Elements:

      an assignment to /a/b/c will effectively apply to /a/b/c/d and /a/b/c/foo/bar (and anything else whose full path name begins with /a/b/c/)

   3. My understanding is the following – is that correct?

      1.  /a/b/c//*// does not match /a/b/c, but matches all geometries below it.
      2. /a/b/c/ does not match /a/b/c, but matches all geometries below it (equivalent to (1)).
      3. /a/b/c does match  /a/b/c and /a/b/c/d, but not /a/b/cd (segment-wise matching).
      4. /a/*/c does match a/b/c/d as well, and so do /*/* or /*/b/*.
      5. there's no way to exactly match /a/b/c and not match any childs like /a/b/c/d.

9. Is the leading slash optional? In other words: are /a/b/c and a/b/c equivalent? It seems e.g. the chess set uses just "nodename" and not "/nodename" for assignments.

[hybridherbst]

I played around with implementing the currently specified logic a bit, here's what I came up with. I'm very much not sure about some of these rules and if patterns are actually valid or not.

MaterialX Geometry Expressions Tester: https://materialxgeomexpressions-z23hmxb1jernx.needle.run/