Jenna Huntsman

JIRA - support will likely just point you to file a JIRA if you've discovered a bug anyway.

"with ease" is definitely not the case. Henri's CoolVL viewer implements a dual rendering pipeline, which means to say, the (older) rendering pipeline from viewer versions 6.x, and the newer pipeline from viewer versions 7.x - Viewers with only the 7.x rendering pipe (The LL viewer and essentially all TPVs of V7 that aren't CoolVL) can't switch off ALM, because the forward renderer is no longer implemented - for many users, the new V7 pipeline should give you the same or more FPS while looking nicer; but CoolVL is the one to use if your hardware is flat out incapable of running the new viewer. As Henri has said previously, the option to revert to the V6 rendering pipe will be implemented for a finite amount of time, so long as it continues to work without major breakage. This also means that the option likely won't be around forever.

The quoted post is somewhat incomplete - while it is not strictly false, you need to meet the following conditions for the room to be completely dark: A manually placed reflection probe MUST be present. The "Reflection Probe Ambiance" value in the EEP settings must be 1 or above. The room that the probe is in must not have an opening to the outside to allow light in. If any those conditions are not met, the room will be lit in some form. It's worth noting that the ambient color doesn't directly contribute to lighting if the EEP's Reflection Probe Ambiance value is set to 1 or above. It will (indirectly) contribute to lighting by affecting other factors (sky color, fog color, fog intensity, etc.).

Midday w/ black ambient (i.e. not Midday - Legacy)

Generally, you'd already know, as the most common way (by far) to make a surface emissive is to make it fullbright. So, if it's not fullbright, it's very unlikely it's emissive.

This is incorrect. For example: this is an empty Linden Home in my region. Linden homes do not (at present) incorporate any reflection probes or lighting by default. These screenshots are taken with the latest PBR viewer (7.1.2) and the new Linden Midday preset: Exterior: Interior (forgive the black walls, can't control a home which isn't mine!): Interior (Back room with no direct sunlight):

Emissive surfaces are surfaces which have variable amounts of unlit parts - i.e. a better (more controllable) fullbright (fullbright essentially makes an entire surface emissive at 100% intensity) - For Blinn-Phong materials, this means the alpha mode is set to "Emissive mask", or for PBR materials, see here: https://wiki.secondlife.com/wiki/PBR_Materials#Emissive_.5B_RGB_.5D The "Glow" setting I refer to is the glow parameter seen in the Texture panel of the build floater (i.e. a property of the prim). Here's an example of a light source with glow: and without:

That bright flare could be the spotlight that's illuminating your avatar - you need to be careful with the light's FOV value to avoid this. (The projector texture isn't always sampled when rendering lights, as this would be much slower than looking at the light's overall parameters). Note that light flares aren't able to be removed (because, the flare is created by the light a lamp emits, not based on if the lamp itself is visible), but careful tuning of light parameters can avoid unwanted flares. If the flare is from the sun (as Arton suggests), then enabling shadows should resolve the issue. In terms of EEP for PBR, I have some pointers on my wiki page for some rules-of-thumb: https://wiki.secondlife.com/wiki/User:Jenna_Huntsman#PBR In addition to what Arton said in regards to glow and fullbright, emissive surfaces (either Blinn-Phong or PBR) will contribute to lighting. As a rule of thumb though, any surface that emits light should also have some amount of glow added (because, glow is an optical effect caused by the emission of light)

That screenshot explains it - The viewer will only accept glTF files with maximum resolutions within SL's resolution limits (currently, 1024px or 1K) - Change the resolution of the glTF on the download options on the site, and you should be able to import the downloaded glTF straight into SL.

The maps that glTF 2.0 uses are the following: Base color (Sometimes called albedo) but NEVER diffuse - diffuse is something different entirely. Normal (Same as Blinn-Phong) ORM (Viewer and glTF call this Metallic-Roughness, however to avoid confusion many users say ORM to refer to the compiled map - this consists 3 greyscale maps of the Occlusion in the red channel, Roughness in the green channel and Metallic in the blue channel). Emissive (Which parts of the texture should be unaffected by lighting (e.g. light sources)) If you see maps like: Ambient Occlusion (aka AO) Roughness (aka Rough) Metalness (aka Metal) Then SL won't take these as-is, because they need to be compiled into an ORM map first. AiAi's glTF packer can do this for you. If you see a Diffuse map, this item is not a glTF compliant material and should not be used. (Diffuse maps contain baked lighting, which the base color map should not) If you see a Specular map, this item should not be used (Either the item was made using the PBR Spec-Gloss workflow, which is not present in SL, or was made with another shader model in mind). If you see an Alpha map, this should be merged into the alpha channel of the base color map. Again, AiAi's glTF packer can do this for you. If you see a Displacement map, this can be ignored. SL does not implement this feature. As with the above, including the separate textures is optional for creators. Applying a base color map as a diffuse map does not achieve what you may think it will, as the base color lacks information that is needed for a Blinn-Phong diffuse map; hence why creators may opt to not include the textures. The need to apply a Blinn-Phong and PBR material to objects is temporary during the transition period to PBR viewers, so will not be needed indefinitely.

FYI, this version of Blender has major issues with glTF. The wiki has a big warning regarding this: https://wiki.secondlife.com/wiki/PBR_Materials#Blender

As noted in that JIRA, this problem has been fixed upstream and will be included in the glTF Maintenance viewer.

As an example, here's a room in my Belli home which is lit by a single projector source (the ceiling light) facing the floor, and the rest of the lighting in the room (the walls and ceiling) lit by the reflection probe.

They very much do act as a light source for reflection probes. Emissive surfaces also act as a light source for probes too.

That link I provided was mainly meant to refer to the gamut mapping chart, wherein you can see that Rec. 709 (which isn't the same as sRGB, but very very close) has a considerably lower gamut coverage than that of BT. 2020 - reasoning being that HDR support is also tied in with support for wide-gamut colour. For some technical reading on the subject (100% not required, but if you're nerdy and want to), then these offer some further reading: https://en.wikipedia.org/wiki/Rec._2020 https://en.wikipedia.org/wiki/Rec._2100

This is likely because the autoprobe for the area you're standing in is in the wrong position. Autoprobes are placed approximately, and placement isn't always correct (hence, why manual probes are recommended). This is not quite true - the reason why ACES was implemented is the requirement for HDR lighting by the glTF standard - tonemapping is a de-facto requirement in order to display HDR lighting on SDR displays, as otherwise colours would end up out-of-gamut. See the gamut difference here (Rec. 709 (sRGB) and BT. 2020): https://www.benq.com/en-us/business/resource/trends/understanding-color-gamut.html Other tonemappers are available, but ACES is the current industry standard choice, hence why it was chosen.

No. The water texture isn't a diffuse, it's a normal map, which is a different thing - see here: https://en.wikipedia.org/wiki/Normal_mapping

Intel hardware of this age will have issues running SL (and any other modern program) due to hardware and software bugs which were never fixed (generally, Intel products from before 2017 have critical, unpatched hardware and / or software bugs). That said, you may find running Windows on your machine may have more success due to the more modern version of OpenGL supported (MacOS will limit you to OpenGL 3.x, Windows allows you to run OpenGL 4.3).

To my knowledge, there isn't a technical reason why point lights don't cast shadows - I think this is just a carryover from legacy code wherein shadow casting was never implemented for point lights

If you're having issues with the viewer freezing up and stalling, submit a JIRA - https://jira.secondlife.com/ The engineers who can fix this don't read these forum threads - but submitting a JIRA will bring these kinds of issues to their attention, so they can be fixed.

There's one that I made, which is about as close as you can get without breaking anything: https://marketplace.secondlife.com/p/Eye-Roll-Stuck-Animation-Fix-for-mesh-heads/21060074 This will attempt to reset all bones to their neutral positions... BUT - It won't reset the positions of bones affected by shape sliders, which in the face... is a lot. This is because, if an animation sets a position value for one of these bones, the shape slider will stop working. The real answer is, that if a certain non-humanoid head needs to shift bones in the face, they should always be using a rigged mesh deformer not an animation. This is because rigged mesh deformers don't apply persistent deformations (i.e. will reset when unattached), and don't prevent the shape sliders from working. See: https://wiki.secondlife.com/wiki/Avatar_deformation

Figure I'd have a tinker around with the new Noel head - this is what I achieved (pictured wearing the Stealthic gift hair)

That's what the "Improve Graphics speed..." button is meant to do. If it achieves this or not is a different matter, but generally if it's not doing what it's supposed to, then submit a JIRA. I believe Henri has essentially reimplemented the viewer 6.x renderer alongside the viewer 7.x renderer, which may work, for now, but I remember Henri has also mentioned that this option won't be around forever, and will only be maintained as long as it makes sense to do so. It does also mean that any object using PBR materials either won't render (will use the Blinn-Phong texture underneath) or will not use the entire material (i.e. rendering base color only - this will mean that any object that uses PBR will look broken).

This isn't actually possible with the new rendering code in the PBR viewer - the old (pre-ALM) rendering code was stripped out as it's incapable (or, just plain too expensive) of some of the features required by the new viewer. If you're struggling with framerate, follow these recommendations: https://wiki.secondlife.com/wiki/PBR_Materials#Removal_of_Advanced_Lighting_Model_.28_ALM_.29_Graphics_Option

Does this data include all the people that use third-party viewers? It does. All TPVs listed in the TPV Directory collect telemetry data and submit it to LL.