Vote for Sunlight / Prim shadow issue

Just having the lights not cast through solid objects would help all kinds of ambient lighting (clubs, malls, resturants, offices, homes, fantasy woodlands, etc.) and would be much more visually pleasing than the current "prim light" w/texture fade as if beaming through smoke.

Thing is, a lot of people walk into this issue with a ton of ignorance. I'm not exactly a graphical programer myself, however, I've got a basic idea of how these things work.

Most games are using some sort of soft shadowing these days and run great on what are now mid-range cards, while SL has a far more varied userbase with old and newer video cards alike, that's what detail settings are for. SL doesn't need realtime shadows calculated every frame, the reason games run so harsh is that they have to be updated all the time on every object. What we need is some extra tickboxes and simple shaders. We should be able to select what casts a shadow, and what doesn't, what occludes, and what doesn't.

Shadows, really, wouldn't have to be updated that often clientside. One pass every couple of seconds would be fine, even less often than that. I'm not really concerned with avatars having shadows on the enviroment. Just buildings casting light and shadows on terrain. If games like SWG and other MMORPGs can handle basic stencil shadows, I don't see why SL can't on better video cards really.

One other thing that would be nice is if we could apply the water shader to prims, people like making bodies of water on fountains and whatnot, things above sea level. It makes making any sort of sim that doesn't fit into the traditional idea of a house above sealevel somewhat difficult especially now that traditional SL water looks better with windlight. It's about time we got some better bumpmapping that factors in cubemaps and more detailed specularity settings, High, medium, and low shiny just isn't cutting it, rendering is far more varied than that.

The original windlight viewer had a very different shiny effect if everyone remembers, it only reflected the sun giving it a rather phong-shading like appearance which is a far more appropriate reflection for fleshy things or wet fabric material. Now, if you put shiny on any prims in windlight, it gets coated in that pure-sky reflection along with the sun making anything look like chrome.

The abbility to upload our own normal maps (bumpmaps) for prim textures, and normal mapping for clothes would be utterly lovely as well. The shaders are already there for the most part, (the water makes use of normal mapping, I think.) it's just a matter of letting the users control it. It'd be nice if we could place cubemaps in areas for objects to reference. SL already has a somewhat experimental dynamic shiny (generates a cubemap for an object and reflects its enviroment) yet it's kind of got a hit on performance when you walk into a new area. It'd be better if we could just place a single entity / object that generated cubemaps then handed those off to users as they passed through it.



A slightly better particle engine would be awfully nice, just for doing weather effects. Right now doing any sort of weather in a big area is consuming of prims and scripting resources, particles don't render beyond a certain way and there's no getting around that.

Decals are a must, too, I have no idea why we don't have those yet, or sprites at least. We're forced to use hacky particle methods, or using an entire prim for a simple decal effect. The abbility to decide terrain rendering distance seperate from object rendering distance would be great. With a ticker for prims so we can select what prims should be rendered at what distances, anyone familiar with the source engine would know this by Detail brushes where you select how far until the brush dissapears, as it's unaffected by the occlusion / portal compiler when the map is made. This way large building outer shells could be displayed without killing framerate, yet not rendering every little thing in it. The whole buildings appearing out of nowhere thing should kind of be a bit of the past.

hm in my experience computing the shadows for a well furnished level can take a good hour in the sourc engine. Some objects do have real time shadows but they are used sparingly.

How about a compromise? Obviously computing realistic shadows without slowing us down to one or two frames per second is asking a bit much for current hardware, but what if we enabled landowners to set the lighting environment on a *per meter* basis? Then, folks outdoors could enjoy bright, noon sunshine, but when they step across the threshold of their favorite pub or girlie bar, they also step into a different lighting environment ... darker tones, different colors. Combined with using a few well-placed lights, I think you'd be able to get some nice effects this way.

The interface would probably be tied to "edit land" and work like the bull-dozer. It would also be nice to have something on the mini-map that shows how land is lit graphically.

That's the thing though. That's just ambient occlusion, which we do want, yet we can have shadows as well. The reason it lags is because it's having to calculate it each frame in a second. So if you're going 60FPS, that's 60 full shadow calculations a second...

You can imagine how that kills the framerate. If you did it /once/ every once in a while, it'd be fine.

Raw shadows aren't that hard to calculate comparatively, SL could do that when it calculates the geometry for a prim, then either every 10 minutes (as the sun updates) or when the object changes (within a minimum time of every X seconds).

But the difficulty with shadows comes when you try to calculate how those shadows apply to other objects, imagine a single prim casting a shadow onto a linked set of 50 prims, how do you go about applying those shadows to the objects properly, and in a timely manner? It gets complicated quite quickly. The problem with LL's original attempt at this was things like shadows bleeding through walls (and you complain when light does, hah! =) it looked pretty horrible when it went wrong.

One idea I had which is inspired actually by Duke Nukem 3D (a 10+ year old first-person-shooter for those that don't know). Basically, that game is divided into sectors, essentially 2D areas for space that have a floor and ceiling height, allowing it to appear 3D. In order to do lighting you sub-divide a sector into smaller part-sectors, each of which has a different tint. Anyway, to shade objects in game, the game simply changes the tint of an object to match the sector they're in, so objects in "dark" sectors go dark.

Anyway, what we can do using the sun direction and an object's rough geometric shape is create a shadow "sector", or in our case a "volume", it doesn't have to be very precise, just an approximation of the shape stretched in the direction a shadow would go. Now, simply take every object that falls into this volume, and reduce it's tint (like making the texture colour darker but a separate value). You can do some extra stuff like reduce the tint based on the size of the object being shaded, and the transparency of the object casting the "shadow" to fine-tune this a bit.
The result is that an object in shade would go darker, while the contents of a closed box would become pretty dark.
Now, this method is still quite a bit of work, but not nearly as much as some other lighting systems, however the effect is fairly basic so take of it what you will.

And the client is supposed to also evaluate every texture the light is falling on (from sun or other "outdoor source" and determine if that texture has any alpha channel transparency, and let light in through those transparent sections?

Good god, yeah, would be lovely, but I'm also not going to hold my breath. My children might see such a virtual world, but I won't. *laughs*