Lighting Fixes and Implemention of Global Illumination

Hawk1992 Resident
It is now more crucial than ever to address the default point lighting and spotlights in Second Life, given the introduction of PBR materials.
The point lights will always pass through walls, regardless of the presence of reflection probes. This has been the case and has not been rectified to this day.
The number of spot lights is restricted to two. Once that limit is reached, they cease to cast shadows or function correctly, they will behave as point lights and will also pass through walls. This impedes the ability of both creators and consumers to accurately illuminate a scene in a manner that is both consistent and visually appealing.
Furthermore, I recommend that the lighting and render engine of Second Life undergo a comprehensive overhaul before the inclusion of features such as Displacement maps. This will ensure that the lighting in scenes is consistent and provides a more realistic experience than it currently does. Additionally, global illumination should be incorporated into the rendering process. This is similar to the default setting in the majority of contemporary games, which ensures that any object, from the most basic cube to the most extravagant home available on the marketplace, appears visually appealing. And it ultimately grants us creators more autonomy and eliminates the necessity of baking textures to replicate the global illumination effect, which we still have to do, if we want a realistic looking scene, even with PBR materials and reflection probes. And also is the reason why creators chose to advertise their objects using Renders, instead of Ingame screenshots, which is deceptive, and should be unnecessary.
The following images illustrate the information I have provided.
I created a simple scene that consisted solely of white walls and a white ceiling, with a blue floor and default PBR materials. However, the blue reflectivity of the surfaces is unappealing when a light is introduced.
In contrast to the second image, which illustrates the same scene in Blender with global illumination and accurate rendering, the light is distributed more evenly and realistically, thereby enhancing the efficiency of the materials. This is the proper approach, as it eliminates the need to bake scenes. And as simple as this structure is, it looks visually appealing.
I am concerned that the displacement maps will present the same issue, or even worse, in the current engine. This is not an appealing appearance. The first image with the rocks is what i am expecting. The latter image, which depicts the building, demonstrates the appropriate rendering of a displacement map.
Before incorporating any additional features, such as displacement, parallax, HDRI, or any other feature, first, please enhance the lighting engine to ensure that any scene, regardless of its creation, is rendered in a visually appealing manner by default. This will give Second Life a more contemporary appearance and make it more user-friendly. I am confident that the playerbase would be extremely grateful. And likely people would return returning from competitors, such as VRchat. Which has a modern engine, being that it uses unity.
In conclusion:
Modern texture mapping methods necessitate a modern engine that is capable of rendering them accurately; otherwise, they are merely a form of deception that will not cause any significant changes.
Log In

Geenz Linden
Hey there! So there's a lot to unpack here. And let me say up front: none of these features are free. No big overhauls are necessary either - these features can also just be added. And before it comes up again - Vulkan is not a necessity for any of this.
Let's start with Global Illumination. We technically have that with reflection probes as-is, although it could be better broken out into their own probes. Scaling that would be problematic for a few reasons - and would take a bit of R&D to make a solution that works well with SL at the scale we'd need for "good" GI. I wouldn't point at most engines either here - they all require some sort of preprocessing to work which is problematic on SL.
Better lighting is on the list of things to do, and there's some easy wins we can achieve. Making the sun and moon function in physical units would be a good start, and making point and spot lights function similarly and finally make the jump to a linear lighting model. The main caveat is legacy content. No one here at the lab (including myself) cares how much better your lights will be if we just made all lights physically based - if it breaks 22 years worth of content, then that's going to be an instant no. However, a flag is fine that changes behavior from legacy to PBR. How I intend to add support for physically based lights is just to follow GLTF's extension on this, which can be found here: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_lights_punctual/README.md
For shadows, which is really what you're talking about on that 2 light limit, I've already started some work to enable a more arbitrary number of lights. There are caveats to this however - notably going back to no features are free, and I want to emphasize this. Shadows are not free. They are never free. They never will be free. At least not for SL. Static lighting does not really apply to SL either - so I don't want to see people pointing at how other games have fancy static lighting. More is not off the table though.
Regarding displacement maps - there's no way we can add those right now. It would be of very limited benefit for most people by virtue of their hardware. Even parallax maps are a big maybe. I'd say if you're going to ask for any additional maps, it's better to request things that add more diversity in SL's shading model.
Activity Feed
Sort by

Beatrice Voxel
One of the things that drives me bonkers in SL is how opaque objects (ones with zero alpha channel) don't actually block most light sources, not just environmentals like sun/moon, but lights in the immediate space.
This is a very basic concept of all lighting, be it real world, procedural, whatever. Everything solid should cast a shadow.
Yet if I place a light under a slab of rock, say to provide valance lighting in a pool, while I do get that light diffused across surfaces that could be illuminated by it, I also get that same lighting on things ABOVE the rock slab, such as people standing on it, or furniture. These things are out of LOS of the light itself, how is it they are lit by that light? And I think it speaks to Hawk1992 Resident's point, that in SL, point light sources have always been "entire scene" lights, there is no calculation made for intervening solids.
And before we get in deep with raytracing and displacement maps and all of the other fun jazz, this glaring (ha!) problem needs to be addressed. And yes, I am aware that this could potentially 'break' legacy builds. So, I suggest that we add a flag to an object's properties, much like we have now for physical, phantom, temporary... "opaque". if it's set, then lights on one side of it simply do not penetrate to the other side, it casts a shadow. People can either edit this flag as they wish for legacy stuff (which would by default be un-set) or only incorporate it into new builds, but either way, there's a method to address the "shining through walls" problem.

Geenz Linden
Hey there! So there's a lot to unpack here. And let me say up front: none of these features are free. No big overhauls are necessary either - these features can also just be added. And before it comes up again - Vulkan is not a necessity for any of this.
Let's start with Global Illumination. We technically have that with reflection probes as-is, although it could be better broken out into their own probes. Scaling that would be problematic for a few reasons - and would take a bit of R&D to make a solution that works well with SL at the scale we'd need for "good" GI. I wouldn't point at most engines either here - they all require some sort of preprocessing to work which is problematic on SL.
Better lighting is on the list of things to do, and there's some easy wins we can achieve. Making the sun and moon function in physical units would be a good start, and making point and spot lights function similarly and finally make the jump to a linear lighting model. The main caveat is legacy content. No one here at the lab (including myself) cares how much better your lights will be if we just made all lights physically based - if it breaks 22 years worth of content, then that's going to be an instant no. However, a flag is fine that changes behavior from legacy to PBR. How I intend to add support for physically based lights is just to follow GLTF's extension on this, which can be found here: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_lights_punctual/README.md
For shadows, which is really what you're talking about on that 2 light limit, I've already started some work to enable a more arbitrary number of lights. There are caveats to this however - notably going back to no features are free, and I want to emphasize this. Shadows are not free. They are never free. They never will be free. At least not for SL. Static lighting does not really apply to SL either - so I don't want to see people pointing at how other games have fancy static lighting. More is not off the table though.
Regarding displacement maps - there's no way we can add those right now. It would be of very limited benefit for most people by virtue of their hardware. Even parallax maps are a big maybe. I'd say if you're going to ask for any additional maps, it's better to request things that add more diversity in SL's shading model.

Pazako Karu
Geenz Linden while I'm here, re: shadows - I've been in plenty of places with shadows on that are difficult to experience because of shadows. The excessive impact of calculations of shadows-on-shadows (there's no light left and yet it's still checking, I imagine) is causing a huge fps cost. No shadows visible because all sun/moon light is blocked indoors, yet it's still being calculated.
You get similar problems with using alpha-masking for faux3d parallaxing, where the shadows aren't even visible under the prior layer and yet they're calculated for all 100+, killing performance (even fullbright!).
Finally, regarding static baked shadows, would it be possible to maybe get those on known-static objects? Like if a sim has most unchanging objects set to locked, could lighting on those be pre-baked and assist in performance and realism gain?
This conversation started by my complaint about builders who prebake shadows into their builds because if I want to edit something, I now have something offputting because they designed a scene for a lighting model that doesn't exist in sl. My suggestion was more to use planar texture mapping often- so everyone who wanted could change textures easily (which would increase its value for more users). But I was met with a strong fervor about how sl lighting doesn't do a lot of things I didn't much care about (I mostly play sl, this is already way better than what we've had! Lol)

Geenz Linden
Pazako Karu What I'm contemplating for "static-ish" shadows is more or less just checking if something changed within the light's influence. This, too, has a cost and is likely to be more of an after the fact optimization down the road. We store a lot of data about the scene in the viewer overall so maybe there's something we can tap there.
What I'm thinking is shadows basically work in two modes:
- Environment only (more or less "static")
- Environment + avatars (more or less "dynamic")
With a viewer setting that controls what gets rendered (none, env only, or env + avatars)
This is somewhat aligned with how we handle reflection probes as well - for example, dynamic reflections is the only setting that will render avatars.

Jaden Nova
Geenz Linden While I agree with much of what you said, I also feel that the tone came across a bit harsh.
Yes, I absolutely agree displacement maps are overkill, especially if better shading is implemented, which, honestly, needs to happen. That alone would bring a huge improvement to the visual experience.
That said, I think we really need to have a broader conversation about legacy content. We all know Second Life needs new users to sustain itself long-term, and the reality is, new users simply don’t care about 22-year-old content. This long standing narrative that “nothing should break” is beginning to feel outdated. At some point, we need to ask: how long can you keep stacking new features on top of 20-year-old code?
Comparisons to other platforms are inevitable especially for first-time users. They won’t know or care what’s been done over the last two decades. What matters to them is what they see today. :)

Hawk1992 Resident
Jaden Nova Truth be told already the "22 year old content" is broken, because nobody wants to use pre bento stuff, stuff that is pre mesh, layer clothes (even if now possible with BoM basically nobody does it)
And it already is beginning to get outdated if you do not use PBR materials especially as creator you would find a hard time doing so.
So while the old stuff exists and technically can be used just like back in the day, people do get stigmatized for using it and it gives off a bad look as in "you are poor" "you have bad taste" its like in real life with technology. If you were to buy a CRT monitor old DOS computer from the 1990s now, you could, but, People would look down upon you unless you do it out of nostalgia or as a collector Because for the same price you can get a lot more high end hardware nowadays be it even just from the last 5-10 years.
So truth is, Most of this 22 year old content, nobody buys anymore anyway. Bloggers and artists and other methods of advertisement for the new stuff and what is "in" and "trendy" do their rest for this. the old content is outdated.
And compatibility does not even work wtih the current PBR Model, You can not place lets say non PBR furniture into a PBR scene it breaks the immersion, because that furniture does not react to the lighting properly as does the rest of the scene. Thereby already forcing users to upgrade their objects if they want a proper experience.
And as you stated, most of the userbase is pretty aged already, we have as base age around 28-40 peaking towards 65+ im myself 25 soon 26 so i am already not the youngest anymore. I rarely ever see young people anymore lets say 18 year olds, 20 year olds and so on. Because unfortunately as it is now it is i think not very attractive for younger generations which is a big shame as it has so much potential.
Maybe it would be better to just make a big upgrade and start from new with a solid set of functions and a stable engine, instead of giving small updates year by year or so that forces creators to upgrade their stuff, learn new techniques they previously didnt require in case they were exclusive SL creators, and have consumers due to peer pressure buy the new stuff too. Because if there is something that causes content to be outdated and lost in time, it is exactly that, unfortunately.

Pazako Karu
Jaden Nova I was avoiding saying this myself. Trying to keep everything inter-compatible forever is why Microsoft is a 35GB beast on install nowadays when it used to be 100MB and are the features
that
different? As a good example: I cant remember the last time I tried to rez a sculpty and saw what it used to look like in '08. The shadows are weird, its bumpy where it shouldn't be. If I set any of the classic bump maps + shiny I get something chrome out the wazoo. Many of these features being preserved are already broken.
I suppose this question could be resolved with another ticket Ive seen about the marketplace, that shows listing/updated dates. I can assure you, 99% of the time, if I see < 2020 on there, I probably wouldn't buy it. If nothing else it would give LL a gauging point of how many years back the L$-spending population wants preserved. Add a safety factor since y'all are nice like that, but forever is impossible to maintain for. A lot would give flack about this (in particular that they have to update their 22 year old item, oh no) so clearly it's something that needs mass-user feedback, but it's something that should be considered.

Hawk1992 Resident
Pazako Karu Listing dates is SUCH a important thing, also it would be lovely if you could go back to the actual number of items as back in the day instead of listing it as 10.000+

Hawk1992 Resident
Thank you for all the engagement thus far.
Furthermore, I would like to emphasize that the implementation of such a feature would result in a renaissance of the default construction system in Second Life, (which may also undergo a revision) as well as the creation of Mesh prefabs.
Currently, it is necessary to possess knowledge of software such as Blender in order to create visually appealing objects (such as buildings). This is because the textures must be baked to achieve an appealing appearance. Otherwise, the default method provided by Second Life will result in an incredibly unappealing appearance. And things such as materials that you can buy in the store are pretty much useless.
Another issue is that furniture and other third-party props will never be a perfect match for the scene.
Therefore, if individuals were able to utilize either the prefabricated building elements that mesh creators can offer on the store or the default building system once more, a plethora of individuals could quickly become creators themselves and not be constrained by their lack of proficiency in third-party programs. SL is a creative simulation game; let us repurpose it in this manner and ensure that all individuals have the opportunity to engage with this stunning feature of SL.

Daniele Tatham
You're absolutely right!
Since I'm one of the lucky ones who has modern hardware, which wasn't the case until recently, and which has led to considerable frustration on my part, I now believe that SL should finally switch to more modern software that also supports what modern hardware can handle.
I'm a DJ in SL and often play in busy clubs, and I've noticed that the frame rate often drops, while at the same time the graphics card isn't being fully utilized.
I know this only has an indirect connection to the lighting, but it reveals the weaknesses that still exist in this system that need to be addressed first.

badunicorn Resident
Global Illumination in SL?!?!? Take my money lol

JulsToffy Resident
Oh yes, take my vote. While I've been enjoying PBR, I'm having a very hard time to make good lighting in SL these days, both for my photos and for my SL home as it is. Everything is either flat and too bright or extremely dark. It desperately needs an overhaul. I've been learning to use reflection probes but it's not enough :(

Kalms Resident
I agree that the beautification of SL goes through an overhaul of the lighting system. It is not uncommon to see beautiful sim builds poorly illuminated because of the chance of point light contamination to other rooms, specially PBR ones which require lighting sources to show their true beauty. I am not sure though if manual probes prevent this from happening.