I’ve created a custom shader with only two parameters(color and emission), that looks exactly like URP Lit shader in the Editor. But, when I launch my app in VisionPro Simulator, it looks much darker then URP Lit. I attached screenshots with Editor view, simulator and shader graph.
The first thing that comes to mind is that there’s an occasional bug in the simulator where things appear darker until you reset. It’s mentioned in the FAQ.
However, if URP/Lit works, then that’s unlikely to be the issue, and I would have to know more about your project to be sure of what’s happening. If you submit a repro case and let me know the incident number (IN-#####), I can take a look.
I think I read tone mapping is disabled in vision OS now. There is an HDR color in shader graph. The darker cube looks like there was no tone mapper applied to its emission HDR color. But still, why URP/Lit looks well is a good question. And again, I’m not sure tone mapping is really disabled.
That would be interesting! We explicitly disable tone mapping for Unlit materials, but there’s no way (that I’m aware of) to disable it for Lit materials. I noticed the HDR color as well, and it’s worth noting that we don’t support HDR colors for color properties: they’re clamped to [0, 1] and sent as Color32s. If the emissive color has an intensity greater than one, then that might be the issue.
I’m not a guru of HDR colors handling in terms of low-level staff and exact displaying on a screen, but fix me if I’m wrong.
- Device screen needs LDR color data to display it with RGB pixels. So every HDR color value have to be translated to LDR.
- Tone mapping is a common way to translate HDR to LDR. In my world tone mapping is similar to gamma conversion with gamma-value between 0 and 1 in some sense, but it has asymptote at 1(more like atan or something). By the way, as I can observe in unity, if I convert color from gamma to linear color space it will look exactly the same as if just used HDR color, that makes me thing that Unity just uses reversed gamma as tone mapping function.
- This tone mapping is applied to HDR even when it less then 1. I can clearly see it, because colors in unity editor inspector color picker is much brighter, then LDR color, event when I select HDR in range [0;1]
So, if you just clamp an HDR color, you, of corse, will have an LDR in range [0;1] but this is not HDR supposed to work in my world(again, maybe I’m wrong). I attach a rough graph of how I see the points, I’ve described above. Blue one is a tone mapping, green is a clamp. And, as you can see, in the range [0;1] the tone mapping value is higher then simple clamp. That could be a reason, why materials looks darker in visionOS.
Interesting theory! AFAIK, tone mapping is typically applied at the end of the render process, so I don’t think it would apply to how we transfer color values. However, I did discover that HDR colors are interpreted as being in linear space, rather than sRGB (as default colors are). This becomes very obvious if you switch a shader graph color property with values (0.5, 0.5, 0.5) between normal and HDR mode: the color becomes brighter when you switch to HDR mode. We are currently interpreting all colors as being in sRGB space, which explains why the initial example is darker. I think we can detect and fix this, although it still won’t allow colors outside the range of [0, 1].
Actually, it looks like we can support this as well.
Yeah, thats what I meant. If you will have an estimate about when it will be fixed, I will appreciate if you share with your plans in this topic. Thank you!
It will be fixed in the next release, which should be soon.