Jenna Huntsman

Double check the bit depth of the exported images. SL only allows 8 bit color in textures, but Substance will often export at 16 bit, which the viewer will crunch down (badly) to 8 bit. See: https://wiki.secondlife.com/wiki/PBR_Materials#Adobe_Substance_3D_Painter

Hmm, okay, seems like I made a mistake. The points I have are, 2 vectors (A and B) representing arbitrary points on the surface of a hypothetical shape, and vector of the center point of that shape, and a float representing the interpolation amount. If it helps, I also know the 2 rotations of those points A and B. Looking at the output, I wonder if the results being outside what I'm expecting is maybe because it'd be better to interpolate along an ellipsoid rather than a sphere? How could that be done? I (somewhat shamefully) asked an AI model about this but as far as I could tell the math it was able to output was garbage.

Just revisiting this problem after a little while! I've figured out that I also need to provide a plane normal so that the interpolation path follows along a defined plane between points A and B, and having the appropriate curvature for that path along the sphere. How could that be added? (many thanks for this code! I'm not a great mathematician and I can't seem to find the info I need elsewhere!)

sRGB should be enough for content creation in SL. While SL is likely to be able to support HDR output in future, the content standards used in SL actually require textures to be in sRGB space anyway. It's also worth noting that DCI-P3 isn't really a color space that's used in computing - it's a standard designed for cinemas. Monitor manufacturers like to quote it because it's a smaller color space than the actual color space used in HDR (BT. 2020), so gives a higher % coverage. In computing, the 2 major color spaces are sRGB and BT. 2020 (also known as Rec. 2020 ).

I think these images demonstrate that the Catwa head in question is using a nonstandard (or at least, not SL Neck) neck, as the Logo heads and Reborn use SL Neck by default (Not sure about Legacy, although I'd guess they are using SL Neck). Bonus with SL Neck is that it also resolves the seam issues caused by misaligned material maps, which is even more important with the introduction of the PBR viewer as the easy ""fix"" (not a fix at all actually, but one people keep reiterating) to turn ALM off is no longer available.

You may also want to compare your body with a LeLutka head, as they originated the standard that most bodies and heads use now, called the "SL Neck". Not sure if there's a standard document or anything, but if you contact the LeLutka devs they might be able to point you in the right direction.

Go back to basics for a second - Redeliver your body and head. Unpack the fresh copies, and wear them. Is the seam still visible? For example, my partner wearing the latest version of Jake and his head (LeLutka Quinn)

Apologies, I misread what you said. It is indeed true that if all criteria are met, that it is possible for the sun to be at a 90 degree (or extremely close to it) elevation. However, the criteria are extremely specific and fall outside what most people would expect. For example: as you highlighted, the time of midday may not equate to the exact midday point of a given point on the Earth due to the use of timezones. I'd argue, however that most people would think of midday as the time of midday, rather than the solar midday. I'd also argue that the majority of people wouldn't assume that the midday preset was deliberately made to represent a point on the equator on the day of the spring / autumn equinox. The San Francisco example shows what someone from North America might expect to see at midday.

Not quite. For example, the meteorological data for San Francisco on the Spring Equinox 2023 at midday places the sun distinctly not at a 90 degree elevation. https://www.suncalc.org/#/37.7771,-122.4197,12/2023.03.20/12:00/1/3 This is closer to being true, although, again, not quite 90 degrees. Today's date, for example: https://www.suncalc.org/#/-0.0201,109.337,14/2024.03.01/12:00/1/3

It is actually relevant as the midday preset was updated in the PBR viewer, and this complaint is one which was addressed. The new default midday no longer places the sun directly overhead (because, that doesn't really happen in the real world anyway).

This is actually coming as part of the glTF stage 2 (mesh and scene import) project. Lights will be able to be defined in physical units, as opposed to the arbitrary 0-1 scale that is currently used.

That issue in particular is likely down to the user's preferences, namely shadows being disabled. Switching EEPs is a hack around the issue, as Nam's (the EEP mentioned as the "fix") uses a high level of ambient light to eliminate areas which would otherwise be shaded - not really a PBR issue per-se. (You could reproduce this on the 6.x viewer)

If the clothing creator packages a specific EEP that they require you to use in order for the clothing to display correctly, that's a sign of faulty content. PBR enabled clothing does not and should not require the use of a specific EEP preset.

Yes. An avatar stood within a reflection probe will have it's reflections and lighting influenced by it. Reflection probes always work based on the EEP currently applied in the user's viewer, so any manually applied EEP will display the correct lighting within that probe for that setting, combined with any local lights (if any are present).

This intentionally doesn't work, so that's a non-issue. https://wiki.secondlife.com/wiki/PBR_Materials#Unsupported_use-cases