Suggestion: Decals & MaterialMask debug

[Amerio.Stephane]

Hello,

Decals and MaterialMask are quite a useful feature, but they can become hell to "debug" and setup. 
(Quick side node: "MaterialMask" is a terrible and confusing name, "DecalMask" would be so much clearer, especially for newcomers)

1/ Default setup of Materials

By default, all materials are created with MaterialMask set to "all bits". This is easy for newcomers, but terrible when adding a new material that will have to interact with others in the world, because suddenly it will be affected by all sort of unexpected decals.

In our case, this happens a lot with decals already set up on runways, taxiways, etc. As the ground is never flat, we can't have very thin decals, and suddenly when a new aircraft is landing it will be affected by the ground decals. This also happens with VR hands/controls, Unigine Aviation assets, vegetation, etc.

I understand why this choice was made (to ease the setup for newcomers), but maybe a solution would be to just use the bit #0 by default (value 1) for MaterialMask, so it would be easy to not use this bit for most of our decals. You get the idea, I guess.

Also, the Unigine market library objects are not consistent with their MaterialMask. Some use 0 (very rare, I love them), but most use "all bits set" (booo).

 

2/ Finding what decal is modifying a surface

This one is tricky, but it's such a pain in large scene... We have tens of decals in the same airport area, and to find which decal is producing some artefact is a pain (disable each one, one by one, until you find the culprit...). My dream is something like "pointing a pixel on screen, show me which decal(s) are affecting this pixel". Surely very hard to implement, but you might have some better idea to help us here.

Thanks!

[silent]

Hi Stephane,

1) Unfortunately, we cannot change the default bit behavior for material masks, as doing so would impact the vast majority of users and make migration quite painful.

Changing this value to 0 would simply mean that whenever you need fff, you would have to modify the material again. While this may be a less frequent case in your particular project, we generally cannot assume that this should be the default behavior at this time.

Typically, artists working on scene building follow their own established rules, such as how materials are named, which base materials are used, and which masks are set, to keep their workflow organized. Since every project is unique, assets from the store do not follow any single set of rules. In most cases, final materials are adjusted to fit the specific requirements of a project.

Additionally, materials usually require a variety of mask values, not just 0 and fff. For this reason, it is often more effective to prepare a set of inherited materials with predefined masks. When a new material is needed, it can then be inherited from an existing one that already has the correct settings.

2) You can try something similar to what you did in your custom Editor plugin - using an intersection-based approach for terrain mask checks.

The main difference is that decals are not Objects (they inherit from the Node class), so intersection checks are limited to bounding boxes. If a probing bounding box intersects a decal’s bounding box, you can record that hit and collect a list of all decal nodes within the intersection volume.

For more details, please refer to the appropriate getIntersection() overload. As for the probing bound, you can make it very thin and tall (like a bar) and run the probe at fairly high precision.

Thank you!

[Amerio.Stephane]

8 hours ago, silent said:

Unfortunately, we cannot change the default bit behavior for material masks, as doing so would impact the vast majority of users and make migration quite painful.

Changing this value to 0 would simply mean

Of course, I wasn't expecting you to change the default bit behavior to 0 (that would have been stupid, as no decal would show up by default), I was more or less hoping for

 

the value 1 (bit 0) to be default (like it is the case for intersection for example). But of course, legacy has an heavy weight and you can't change that at will.

The main consequence we deal with is users instancing XR assets, vegetation and other assets from the store, and reporting to us as a bug that they are now fully grey (because the airport decals are affecting them). As they are your assets from the store and we try not to duplicate/edit them in any way to ease updates/upgrades, them having a MaterialMask with value 0xFFFF is a pain. I do think a one bit only for default should have been selected. Oh well, of course we'll live with it. Just wanted to share my pain with you :)

 

8 hours ago, silent said:

using an intersection-based approach for terrain mask checks

That is an intersecting suggestion! I'll give it a try.

Thanks!

[silent]

Hi Stephane,

Could you please give us a bit more information about your pipeline then? You do not provide fully assembled app to the end-users? How end-users are working with your scenes?

Thanks!

[Amerio.Stephane]

As we are a R&D department, our end-users need to be able to add elements to the scenes with limited help from us. They are not basic customers, as you would say for a game or a even a CAD software. Of course, we don't let them play with the Editor directly (not their job), but they can add and reference existing assets from the store, as all packages from the store are delivered by us to them, or simply do a runtime import of their CAD data. This is so if their specific scenario needs to have, say, a car in the middle of a runway, then they can add it themself (find its path in the assets repo, add it in ig_config.xml, give it a ID, and spawn it). Same with VR: they can either work with their CAD data inside an empty space, or over a taxiway to see their creation in-situ. But then, in all these cases, the airport decals ruin the appearance because every new asset as a MaterialMask 0xFFFF as do the asset-store assets. So we have to manually edit these choices/assets, and redo these every damn SDK upgrade.

Also, we don't deliver fully assembled app but developer-friendly-builds because doing so allows us to do on-site tweaking when needed (and oh boy do they need it) (remember, they are *internal* customers, nothing goes outside).