Announcement

Collapse
No announcement yet.

Render element naming

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Render element naming

    Hello Chaos people, I thought I'd give you a bit of personal feedback on the current naming procedures for render elements. Currently I find it quite convoluted and confusing. The addition of the "Get name from node" parameter seemed like a good thing, but I'm now finding that it doesn't always mean that the channel is named after the name that appears in the render elements window (what I expected). With extra tex elements, for example, it will output a channel with the name of the input texture, e.g. "SamplerInfo2". So instead of explicitly putting names into the fields in the render elements to control naming, I'm now having to rename utility and texture nodes instead. So, not really much less work.

    It would be much more intuitive if enabling "Get name from node" meant channel names were simply derived from what appears in the render elements window. Also, "Explicit channel name" seems to override "Get name from node", which also seems to be the opposite of what I'd expect -- if you want explicit channel naming, you don't turn on "Get name from node" to begin with.

    And, is it really necessary to prefix every new render element with "Vray_RE"? This simply makes everything harder to read, and I find myself constantly deleting this string for ease of reading what's in the render elements window.

    Finally, the compatibility/functionality with namespaces seems to be very inconsistent, at least with referencing. Without "Get name from node" enabled, some channels take the namespace and others don't. Turning this on forces it, but it would be better if namespaces were prefixed by default, which is the convention with every other node within Maya.
    Last edited by SonyBoy; 04-05-2018, 12:40 PM.

  • #2
    Originally posted by SonyBoy View Post
    With extra tex elements, for example, it will output a channel with the name of the input texture, e.g. "SamplerInfo2". So instead of explicitly putting names into the fields in the render elements to control naming, I'm now having to rename utility and texture nodes instead. So, not really much less work. It would be much more intuitive if enabling "Get name from node" meant channel names were simply derived from what appears in the render elements window.
    This is either a bug or is by design for some reason. I'll check it out more thoroughly. I think it's specific to the extraTex.

    Originally posted by SonyBoy View Post
    Also, "Explicit channel name" seems to override "Get name from node", which also seems to be the opposite of what I'd expect -- if you want explicit channel naming, you don't turn on "Get name from node" to begin with.
    This falls into the same category, I'll make a note to thoroughly investigate it so I know what's going on before making any conclusions.

    Originally posted by SonyBoy View Post
    And, is it really necessary to prefix every new render element with "Vray_RE"? This simply makes everything harder to read, and I find myself constantly deleting this string for ease of reading what's in the render elements window.
    That's a bit specific and it does come with loads of legacy reasons, mainly the way our render elements are implemented in Maya. The node type is VRayRenderElement and Maya automatically assigns node names based off of the node type. Again - I've not looked at the code to be sure, but I would guess that we've 'shortened' it to VRayRE from there. Then an attribute to the node designates the vray channel (diffuse, extraTex) and this is appended to the node name and you get VRayRE_diffuse. It sounds like there could be an easy way to change it, although we'll have to account for compatibility. I'll discuss with the devs whether this is easily doable.

    Originally posted by SonyBoy View Post
    Finally, the compatibility/functionality with namespaces seems to be very inconsistent, at least with referencing. Without "Get name from node" enabled, some channels take the namespace and others don't. Turning this on forces it, but it would be better if namespaces were prefixed by default, which is the convention with every other node within Maya.
    Can you give me an example where this fails? This definitely sounds like a bug and having a reproducible case to debug will help us fix it.

    Alex Yolov
    Product Manager
    V-Ray for Maya, Chaos Player
    www.chaos.com

    Comment


    • #3
      I've logged a bug with a tracking number VMAYA-7721 for the issue with the samplerInfo, extraTex and MaterialSelect (it turns out mtlSelect also has the same problem). The same issue covers the 'get name from node' problem.
      I've also logged VMAYA-7722 to consider dropping the "vrayRE_" prefix from the render elements' node name on creation.
      As for the namespacing issue, it would be appreciated if you can share an example.
      Last edited by yolov; 11-05-2018, 07:40 AM.
      Alex Yolov
      Product Manager
      V-Ray for Maya, Chaos Player
      www.chaos.com

      Comment


      • #4
        Thanks Yolov, and I will try to provide you with an example of the namespacing issue when I can. One more gripe came up yesterday, which is that with standard elements such as reflection, the prefix field comes prepopulated with that name, so the channel will render with that name even with "Get name from node" turned on, until that field is emptied (basically the same issue I mentioned before, but made worse by the fact that it's prepopulated).

        The main things with the naming procedure from a production POV are obviously clarity, predictability and ease. I do currently find I need to test render constantly when setting up RE's to actually verify what the channel is going to be named in the render because of these inconsistencies. Our render team sets up Nuke templates and they get very upset if channel names change between render versions, so it's really important that we get all our naming conventions set up correctly. Thank you for looking into this issue.

        Comment

        Working...
        X