UIX has rendering issues when snapped onto in desktop mode

[epicEaston197]

Describe the bug?

When you're in desktop mode and you control click onto a UIX canvas a behavior close to Z fighting can be observed this can obscure text and vital information for the UI to be used properly

To Reproduce

This happens commonly in the desync lounge

snap your viewpoint onto a canvas with some graphical detail and you can observe Z fighting like behavior

Expected behavior

I should be able to observe all the information on the canvas unobscured by Z fighting like behavior when my viewpoint is snapped onto it

Screenshots

it can be as benign as this or it could be obscured like this

Resonite Version Number

2024.2.2.1015

What Platforms does this occur on?

Windows

What headset if any do you use?

Desktop

Log Files

I don't think log files would help in this situation

Additional Context

No response

Reporters

@epicEaston197

[shiftyscales]

Looked into this a bit. I don't know if it's the proper solution for this- but it appears that increasing the OffsetFactor for the default UI_UnlitMaterial in the world improves things. I don't know if it's just masking the underlying issue however.

Seeking input from @Frooxius, @ProbablePrime, or @Geenz.

Of note- the issue is most prevalent when UI-focused onto the canvas. If the canvas is rotated slightly away from the camera, the issue lessens.

As noted at the top- the issue starts to rear its head from relatively small distances- while testing in the local home, I found that being only 50 units away from the origin was enough to start to cause a disruptive amount of Z-fighting.

OffsetFactor: 1

OffsetFactor: 100

[Lexevolution]

As mentioned in my issue, #494, I was seeing artifacts like this starting around 32m from origin. And that a possibility to try to mitigate these issues is to change the unitScale parameter on the Canvas component. This parameter was intentionally added so that the scale of the panels would not have to be so small. I am not sure whether this actually fixes the issue or not, as I have not tested yet.

[Banane9]

When taking pictures of protoflux with a camera in orthographic projection that's exactly normal to the nodes, this becomes especially problematic: some connectors will just not show up in the rendered image, even very close to spawn. We noticed this while working on "FluxShot" (https://discord.com/channels/1040316820650991766/1204087901239906395/1204087901239906395).

Adding a quite small angle (.1) on the x-axis, making the camera point ever so slightly up/down, seemed to stop that from happening.

[Lexevolution]

After testing with multiple scale and unitScale values on the Canvas component, the rendering issues remained throughout. So it seems unlikely that changing this field will fix this issue in anyway.

[epicEaston197]

After testing with multiple scale and unitScale values on the Canvas component, the rendering issues remained throughout. So it seems unlikely that changing this field will fix this issue in anyway.

Even if it did fix the issue it's only masking a bigger issue with UIX rendering

[Frooxius]

We can increase the OffsetFactor & OffsetUnits, but it might cause other artifacts in other cases. It'd be worth to test this in different scenarios and see how well it behaves.

[epicEaston197]

We can increase the OffsetFactor & OffsetUnits

again as I said above that isn't fixing the core issue there is something wrong with the UIX rendering that's causing this to happen please correct me if I'm wrong

something to note is the scale of the inspectors are extremely tiny the inspectors on the previous platform definitely had this issue but there's definitely a difference here the old inspectors were parented to physical UI scaled at 1, 1, 1

while the inspectors and Resonite are standalone UIX canvases and they're scaled at 0.0005, 0.0005, 0.0005 which is extremely small and could cause issues with rendering although I doubt this is the problem

[BlueCyro]

We can increase the OffsetFactor & OffsetUnits, but it might cause other artifacts in other cases. It'd be worth to test this in different scenarios and see how well it behaves.

I've been doing this for a good while in just about any world I make at this point, I haven't noticed any egregious rendering issues. Even when the inspectors and UIs are in close-quarters with geometry or other unlit/transparent materials, the appearance seems sound and doesn't clip or look glitchy. I also haven't heard any reports from users in sessions I do this for regarding any weirdness with the materials. In this case, I'm changing the offset from 100 to 1000.

[Frooxius]

Thanks for the info, I'll try to get the value updated when I can.

[ohzee00]

I've been doing this for a good while in just about any world I make at this point, I haven't noticed any egregious rendering issues. Even when the inspectors and UIs are in close-quarters with geometry or other unlit/transparent materials, the appearance seems sound and doesn't clip or look glitchy. I also haven't heard any reports from users in sessions I do this for regarding any weirdness with the materials. In this case, I'm changing the offset from 100 to 1000.

Late on this but just to say I also been doing this in a world where there is a lot of inspector/general UI work, sadly it means doing it every time due to it being a generated material on root but I haven't had any issues myself. The value I use is the same, offset from 100 to 1000. Without the temp fix in any semi-large world it becomes really annoying on VR but semi-workable, on desktop as the issue shows, is really difficult if not impossible to use certain UI elements while snapped.

[Frooxius]

I've made the tweak in 2024.5.29.27, hopefully this helps!

[ohzee00]

I think this might of been under tweaked in the latest patch.

In the world I made here the issue happens again, granted slightly less so (After you change the Offset Factor to 10 and Offset Units to 100 to match the new defaults): https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2141#issuecomment-2138244387

My suggestion, and with some testing that I did in the previous issue, I think a Offset Factor of 10 and a Offset Units of 1000 can be a really good middle ground of helping z-fighting and https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2141. Of course, others can try their own values and see too.

So overall my suggestion is keeping the current factor but increasing the Offset Units to 1000.

(I had both issues in my tabs and incorrectly put my comment of this issue on https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2141 and not here)

[epicEaston197]

I don't think this issue will ever really be solved there's still some underlying rendering issue that's causing the clipping and Z fighting to happen

[ColinTimBarndt]

What would be the performance difference if UIX was instead rendered onto a separate texture when they change where UIX displays are just quads rendering that texture? Given that most UIs aren't constantly changing, I think this could even improve performance. It would at least fix the Z-Fighting.

[Banane9]

rendering that texture

That would be beneficial in other places too, like making it easier to embed UIX as a UI in other creations or just plain placing it on other meshes - like the curved dash.

[Frooxius]

I don't think this issue will ever really be solved there's still some underlying rendering issue that's causing the clipping and Z fighting to happen

Please don't say stuff like that. Most things can be resolved, it's just question of time and priority.

We can look into more robust solutions. We've only pushed a fix for this one because of community recommendations for values that were supposed to help, but didn't pan out when rolled out more broadly, but we haven't ha an in depth look yet.

What would be the performance difference if UIX was instead rendered onto a separate texture when they change where UIX displays are just quads rendering that texture? Given that most UIs aren't constantly changing, I think this could even improve performance. It would at least fix the Z-Fighting.

This would likely tank the performance actually. There's a few reasons:

• Your assumption that most UI's aren't constantly changing is incorrect - most UI's in fact do change very frequently - it can be small changes, but they do change
• It can be difficult to determine when they actually change - some changes some outside of the UIX panel, e.g. animated materials
• Textures with decent resolution to keep text readable are going to be pretty large, which means with a lot of UI's in world (like inspectors) you'd need to render a lot of pixels and use a lot of VRAM - they would also still suffer from quality issues when you look up close
• This would break a number of features - e.g. materials that respond to lights or that interact with the scene (e.g. blending, refracting) which can be used within the scene - all of those usecases would break

Rendering them to a texture is something you do only when you specifically need it (e.g. dash does this in order to project it on a curved surface), but it's not suitable as a default for all UI.

[epicEaston197]

Please don't say stuff like that. Most things can be resolved, it's just question of time and priority.

We can look into more robust solutions. We've only pushed a fix for this one because of community recommendations for values that were supposed to help, but didn't pan out when rolled out more broadly, but we haven't ha an in depth look yet.

Sorry about that I understand

[ColinTimBarndt]

Today I also had this bug when playing regularly. This probably happened because my avatar scale whas relatively small.

[BlueCyro]

This issue plagues the dash in desktop quite often. I was at [-325, 119, 265] when I took the following screenshot: Ignore the modded dashboard items, this happens regardless of mods.

That's not extremely far from the origin point, and I'd say is quite a reasonable distance to expect things to look mostly how they should.

The backing UI unlit material just needs an OffsetFactor of 10 and an OffsetUnits of 1000 to mitigate this issue significantly. I do this in pretty much every world I go to and it mitigates the Z fighting at any reasonable distance (<1000 or so) from origin without noticeable visual artifacts that I can see.

[epicEaston197]

The backing UI unlit material just needs an OffsetFactor of 10 and an OffsetUnits of 1000 to mitigate this issue significantly.

If I'm not wrong this is something that the content team can fix as the settings menu is a facet

[BlueCyro]

The backing UI unlit material just needs an OffsetFactor of 10 and an OffsetUnits of 1000 to mitigate this issue significantly.

If I'm not wrong this is something that the content team can fix as the settings menu is a facet

This needs to be applied the default UI backing material so that all UIs inherit it.

[JackTheFoxOtter]

This issue plagues the dash in desktop quite often. I was at [-325, 119, 265] when I took the following screenshot: Ignore the modded dashboard items, this happens regardless of mods.

That's not extremely far from the origin point, and I'd say is quite a reasonable distance to expect things to look mostly how they should.

The backing UI unlit material just needs an OffsetFactor of 10 and an OffsetUnits of 1000 to mitigate this issue significantly. I do this in pretty much every world I go to and it mitigates the Z fighting at any reasonable distance (<1000 or so) from origin without noticeable visual artifacts that I can see.

I noticed that sometimes UI panels start looking a bit strange when the offset factor / units are too large and they intersect other object / you look at them from a steep angle. When the offset of the ProtoFlux node materials was adjusted it caused different artifacts to appear, most notably the nodes now Z-Fighting with other things, like snappable surfaces such as the RedPrint.

I have a bit more of a fundamental question. Wouldn't it be possible to eliminate Z-fighting altogether? I would think that the draw order of UIX elements are pretty much directly defined by the hierarchy of the elements. Wouldn't it be possible to just always draw them in that order to completely eliminate this without causing other artifacts to appear?

[BlueCyro]

This issue plagues the dash in desktop quite often. I was at [-325, 119, 265] when I took the following screenshot: Ignore the modded dashboard items, this happens regardless of mods. That's not extremely far from the origin point, and I'd say is quite a reasonable distance to expect things to look mostly how they should. The backing UI unlit material just needs an OffsetFactor of 10 and an OffsetUnits of 1000 to mitigate this issue significantly. I do this in pretty much every world I go to and it mitigates the Z fighting at any reasonable distance (<1000 or so) from origin without noticeable visual artifacts that I can see.

I noticed that sometimes UI panels start looking a bit strange when the offset factor / units are too large and they intersect other object / you look at them from a steep angle. When the offset of the ProtoFlux node materials was adjusted it caused different artifacts to appear, most notably the nodes now Z-Fighting with other things, like snappable surfaces such as the RedPrint.

I have a bit more of a fundamental question. Wouldn't it be possible to eliminate Z-fighting altogether? I would think that the draw order of UIX elements are pretty much directly defined by the hierarchy of the elements. Wouldn't it be possible to just always draw them in that order to completely eliminate this without causing other artifacts to appear?

Since the UI elements are in 3D space, they need a backing that has a depth buffer. They can't solely rely on draw order, and incrementing the render queue doesn't always necessarily mean something will draw over something else. Perhaps someone else can correct me, but I think we'd need some fancier shader goofing to accomplish that.

I've tested an OffsetFactor of 10 and an OffsetUnits of 1000 and in pretty much every case the Z-fighting was stopped without introducing major artifacts. I am talking solely about the UI backing material.