Proxy 5 - Visibility Overrides

[CrustedInk]

Hello,
I recently started using the new proxy and there are some really great new features.
was hoping to utilize the Visibility Overrides to switch different variation of the same asset in the render scene. in our case, we are building a city. each house has 3 different roofs and 3 different backsides. main goal is to remove maya references from the workflow but still be flexible. so just one vrayproxy with all the variations instead of creating a vrayproxy for all the elements (1 front, 3 roofs and 3 backsides) or a proxy for every combination (9 per building).

so the idea was to only show one version each with the help of the wild cards.
at the moment i have 6 items in the visibilty overrides: *roofA*.*roofB* and so. that works quite well.

but now i am struggling to understand the logic.

the hierarchy of my file looks like this (there is also a screenshot attached):

GEO
----HIGHRES
--------Back
-----------BackA
-----------BackB
-----------BackC
--------Front
--------Roof
-----------RoofA
-----------RoofB
-----------RoofC
----PROXY
--------Back
-----------BackA
-----------BackB
-----------BackC
--------Front
--------Roof
-----------RoofA
-----------RoofB
-----------RoofC

.

So in my case i turned on visible for *HIGHRES* and disabled it for *PROXY*, to just show the highres version. as soon as i make *RoofA* visible i see both RoofA-objects (the one in highres and in proxy), so its ignoring the visibility flag of the folder above. So i have the feeling that even though the vrayproxy is showing a hierarchy its not really working with one. i already tried to move the proxy and highres wildcard to the end of the chain, but this will overwrite everything else.

is there any way to avoid this behavior ?


cheers

[hermit.crab]

It's not a hierarchy issue, it's how the wildcards work. Consider a different naming system or manually override the visibility through the default Override Visibility option. I'll ask the developers if we can improve the wildcard overrides to obey the hierarchy of the VRayProxy.

[CrustedInk]

It's not a hierarchy issue, it's how the wildcards work. Consider a different naming system or manually override the visibility through the default Override Visibility option. I'll ask the developers if we can improve the wildcard overrides to obey the hierarchy of the VRayProxy.

thanks for the reply, can you maybe elaborate this a bit further ?

even with the long names i am not really understanding the issue.
___GEO___root3/PROXY/
------___GEO___root3/PROXY/roof/roofA

so *PROXY* will hide both objects because of the "PROXY" in the name.

HIDDEN ___GEO___root3/PROXY/
HIDDEN ------___GEO___root3/PROXY/roof/roofA

with the next wild card *oofA*, the second object will be visible and i am expecting:

HIDDEN ___GEO___root3/PROXY/
VISIBLE ------___GEO___root3/PROXY/roof/roofA

so the roofA should still be hidden, because its a sub object of the HIDDEN folder "___GEO___root3/PROXY/"
but instead roofA is visible in the viewport and is ignoring the visibilty of the parent object

[yolov]

Hi there,

The advanced overrides are executed in a top-down order. This means that a rule that's lower in the stack is executed later and if it affects an object that's already been overriden by a previous rule - it will override it once more and the whatever is lowest in the stack will have effect in the end.

There's objects with identical names (RoofA) in two paths of the hierarchy and a rule that targets *oofA* will capture them both. You need to capture the one you target with a more precise rule.
In your case, the PROXY groups is first made invisible and afterwards the *oofA* rule affects both /PROXY/Roof/RoofA and /HIGHRES/Roof/RoofA.
When the rule is first added, the default override is 'invisible' (the "visible" checkbox is Off) - this is why you're first seeing the *oofA* rule make /HIGHRES/Roof/RoofA invisible, and later when you toggle it again, it affects both paths.

I hope this makes more sense.

To target /HIGHRES/Roof/RoofA specifically, you can use the the full path like this: /GEO/HIGHRES/Roof/RoofA/* (and btw, if you middle-mouse-drag an object from the hierarchy onto a rule - it copes the path to the object as a string).
Alternatively, you can use wildcards to make the entry shorter like this: *HIGHRES/Roof/RoofA/*

In this way, toggling the override for this rule will only affect this specific group and all its contents.

I've tried reproducing the same setup here and here's how it should look like:

[CrustedInk]

thanks alex, that makes perfect sense. was hoping to reduce the wildcards but probably have to go with full names. having two objects with the same name but different pathes was on purpose, idea was to utilize the top-down order here, but seems like the wild cards below are so powerful, that they are overwriting the parent. is it possible, that the wild car override is not working on groups, but just on shapes? because "/___GEO___/PROXY" is not doing anything but "/___GEO___root3/PROXY/*" is hiding all the objects below

but thats fine, jsut have to add a few more lines of code to our tool and and create a more "complex" hierarchy for our asset department, but thats not a big issue

[yolov]

The correct pattern should be "/___GEO___root3/PROXY/*", because we do the overrides onto the objects. The file itself stores the full path to each object and we 'extract' the groups from the path to display them in the hierarchy. However, the proxy has no concept of 'groups', it knows of objects only.

[CrustedInk]

The correct pattern should be "/___GEO___root3/PROXY/*", because we do the overrides onto the objects. The file itself stores the full path to each object and we 'extract' the groups from the path to display them in the hierarchy. However, the proxy has no concept of 'groups', it knows of objects only.

perfect, thats the easiest explanation why my approach is not working. thank you