小林信行 Nobuyuki Kobayashi:

There are two main issues with UCTS that are problematic for VRC...

1) The final output lighting is clamped. Many worlds in VRC are made for HDR lighting and tonemapping and it's recommended by the developers to do so. But UCTS applies a saturate() function to the final lighting before output so characters in bright environments will appear greyed out due to their shader being clamped to 0-1 range while the rendering is in HDR space.

This could be fixed by removing the clamp functions and testing that the lighting appears properly under HDR conditions.

2) UCTS uses many keywords. This seems like a hard problem to solve. Keywords are very useful outside of VRC, because splitting the shader up into different variants increases performance. However, as the global limit in Unity is 255 and all loaded shaders in a single session will count towards it, having so many keywords in UCTS is a big problem. When VRC runs out of keywords, subsequent shaders trying to use keywords will break and appear incorrectly. VRC by default already has many keywords reserved by the default Unity operations.

This could be fixed by removing keywords. But some keywords are obviously useful to have. One solution that shader developers in the community have began to use is to reuse keywords used by Unity's shaders and Post-Processing Stack v2 (i.e. https://vrchat.canny.io/feature-requests/p/add-basic-keywords-to-loading-screen-so-no-shaders-break-ever-again) which works around the issue. Though it's a hack, it is necessary to avoid shaders being broken. Even so, the number of keywords available is limited. Then these can be aliased to more specific ones in the code as #defines.

i.e. #define _IS_ANGELRING_ON _SMOOTHNESS_TEXTURE_ALBEDO_CHANNEL_A

But I feel like working around this problem might be outside the scope of the project.

Hi, Silent. Thank you for your opinion.

There is my reply to you below.

1: I don't think you are right in every situation.

Firstly, the HDR scene-setting needs proper use of Tonemapping in the post-processings, but many worlds in VRChat seems to lack such ideas in their scene-settings.

It causes the whiteout problems of avatars' look, and many users feel a difficulty to fix them.

Secondly, the color clamp that you say is not a core problem of the way to remap SDR color space into HDR space. There are many problems, such as the vast difference between the top of the white range and so on.

Finally, I think it takes more time for many users to learn how to use the HDR scene-settings in their world.

From those points of view, I've made the specification of UTS2. Of course, it never means your opinion is wrong.

2: If you have a fear of the Shader Keywords trouble for UTS2, please use the button "Remove Unused Keywords/Properties from Material" from the UTS2 custom inspector.

Finally, your opinion is your own, especially concerning the specification of UTS2.

I feel there is almost no relation to this request.

小林信行 Nobuyuki Kobayashi:

Hello, first of all thank you for showing interest in vrchat and responding.

My worry is that people will make content/worlds with HDR lights that are whiting out true HDR shaders because they test it with UTS2 shader and will not see the HDR range on their avatars when they test.

This happened in the past with the popular CubedParadox Toon Shader, a lot of worlds had terrible lighting because CubedParadox shader didn't alert the creators during testing.

UTS2 is very nice looking and popular for good reason, and the concerns are only about the proposed official vrchat recommendations mentioned above in the canny ticket.

1001: Hi, 1001. Thank you for your opinion.

I think you have a little wrong understanding of UTS2.

UTS2 uses the HDR space in mixing emission and GI lighting.

Color clamping is only used for the setting of the composition of primary character colors between base colors and MatCaps in the final stage.

That is because primary character colors should be defined within the SDR color range for designers.

If you try to set primary character colors in HDR space, you could not decide any colors for your characters. That is why you should find the proper LUT between HDR and SDR color mapping.

In NPR, especially Anime like Cel-shaded rendering, every color should be treated not as albedo but as pure color information.

That is why UTS2 has high confidence especially within Pro users in Japan.

By the way, our conversation has no relation to this request.

If you want to continue to talk about the specification of UTS2, please move to issues of the UTS2 repository.

小林信行 Nobuyuki Kobayashi: this ticket is about whitelisting the mobile version for vrchat, and my concerns are about only that.

The mobile version of UTS2 is simply not performant enough for Quest hardware, and the keywords and lighting problems are serious issues that need to be adressed on the PC version aswell.

1001: Thank you for your reply.

If you have a fear for the Shader Keyword problem, please check the link below.

Concerning the performance of UTS2 mobile, it is almost the same as the mobile bumped specular shader.

In Japan, there are many contents made with UTS2 mobile, especially for iOS and Android. The basic spec of Oculus Quest is quite near such smartphones. Indeed many Oculus Quest and even Oculus Go contents are made with UTS2, like below.

UTS2 has a proven track record as a mobile toon shader for Unity.

小林信行 Nobuyuki Kobayashi: I am not certain why some think that uts2 performace is low. Actually, the main reason why I made this request was because of it's performance compared to other shaders on mobile gpu, in the hope that pure quest content can have more shader features.

Is it possible to show a performance graph comparison with vrchat standard lite and vrchat toon with uts2 mobile?

Lhun: It is difficult to check the precise performance of each shaders on GPU, especially for users.

I know the almost top performance of Mobile GPUs from my experience of game development. However, usually, it isn’t.

There are a lot of ways to make the performance of shader improve better.

However, such improvements should be made after VRChat HQ has decided to take UTS2 mobile into their whitelist, I think.

To do that, we need a lot of supporters of this vote for the beginning.

小林信行 Nobuyuki Kobayashi: This is a late response, but because I ended up discussing it with Lhun a lot, I think I should add some notes here.

The main problem is with standardisation. VRC is a shared environment. On the one hand, there is no need for a scene to be designed with full physical accuracy in mind to say it's HDR compatible. But UTS2 covers over issues and breaks in other specific scenarios. If someone tests their content with UTS2, they assume their lighting is correct, even if materials using

are blown into white. This causes confusion and irritation among those users. In implementing these adjustments and limitations, you've caused segregation within the community.

It's possible to say that there's no wrong way to set up a scene, but I think it's reasonable to say that for VRC, the best thing to do is to cause the least amount of trouble for the fewest number of people. VRCs userbase is mostly people learning about Unity from scratch, and as a "live service" game it's normal for people to update their content as they learn and grow. Conversely, while many places in VRC have improved their lighting over time, UTS2 will prevent people from noticing these issues in their scene:

Subsequently, there is less chance for them to improve.

To help with these issues in a broader context, I'm helping work on in-editor tools that will notify users of problems with their scene lighting.

Now, this issue is irrelevant for anywhere VRC. A game developer can modify and optimise the shader, just as they can control the lighting and postprocessing parameters. However, when it comes to designing for a multi-user environment, the best solution is the one that causes the least amount of trouble for the fewest number of people. In other words, this is specifically an issue with , not with UTS2 itself.