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.