High Range Dynamic Lighting

This isn't about a High Dynamic Range feature request.

Right now there is ambient light that keeps most prims visible. This is nice when there is no lights, but it kills one of the most visible eyecandy that SL could ever achieve.

Most people request that people set their viewers to midnight to get all the light effects.

I know daytime only without local lights is supported for performance reasons.

Simply, if we could just turn off the ambient light besides the sun and moon, that would be one step to nice lighting.

What my question is aimed at is the ability to not just turn off ambient light but to oclude light and ambient light. This would allow us to give a higher range light control. A prim that oclude lights basically casts a shadow. Also the ability to set an anti-light in the same way one sets light is desireable for fake shadows. The question being asked is on the technicality of these two possibilities.

It seems like this can be done. Has Linden Lab considered to upgrade lighting like this? Is this something Linden Lab could support database wise and allow a third-party viewer to take advantage of to implement client-side?

Well, I did say it already appears possible, so it wasn't just a feasibility question. (and not about gamma)

It was an insight question on SL direction. I'm not even going to bother with a feature suggestion and waste my time to promote it if I don't hear anything about it. From what I have read about SL, there hasn't been one word on light improvements among all the other features and bug requests and implementation. Practically nothing can be found to study this subject.

We can only assume that SL will follow basic lighting that OpenGL itself offers.

And i think you are complitely wrong. I strongly believe there is a lot of people interested in much better "gfx feel". While i was building in world i was wandering, why everytning looks so flat...why... And i realised that not only lightning isn't best what could be done, but even more...after all those years there are no casted shadows on the ground.
And i'm not talking about more complicated "local lightining" where direction vary for every prim and avie..but about simple "natural lightning" where every ray is paralel to other. It would be great feature...to see alll the shadows in world. Just imagine them changing while sunset.

In todays world we have shadows in every game...why it cant be in SL? For a time i'm in SL i havent seen any larger improvment of gfx. Maby its time for more advanced lightning?

P.S.Sorry for my english, its my second language...and unfortunately still not well learned

We have shadows in every game, but most (if any, up until PS3) were DYNAMIC lights. That is, that every lightsource was subject to change at any moment (look at the sun, it moves ever 6 seconds, or something like that). Raytracing every object for shadows from the sun is costly (even shadow mapping is costly at that rate, esspecially given the size of a sim).

Raytracing is possible with todays hardware. I've tested a fast raytracer on my 1.8mhz machine and it is smooth. The graphics are far better than the cartoon flatness the SL has right now. Even the very basic raytrace would be a big improvement. With quadcores around the corner, it is very practical for a home solution. However, that is a custom idea. We need to know what LL will plan. We need that transparency on LL. =)

Actually i cant argue what cases shadows to exist in games (algorythm) because i have no idea what kind of sollution supports it.
I'm just digital artist, who knows where shadows should occur. I also know that i can see them in many games.

Hm.. i dont think it is so costly. After all that shoudnt be great improvment for server side. If all rendering is holded by client, we could have another option near shiny and bumpy and local lights. That way people with modern hardware could see great improvment on their screens.

What i'm trying to say is SL graphics just looks ugly. And i believe that is not case of low prims, but case of poor lightning. If you look for some RTS probably most of it isn't using more prims than SL. But it always look better.

It's really good, we have here people like you, who can uderstand how all this stuff works. Its really great, coz that way we could suggest some features more precisely.

Can you elaborate? Your code, or someone else's? Is this demo available anywhere? What resolution, framerate? How many secondary rays per intercept?

Or are you talking about raycasting and dynamically baking shadows?

I have thought that raytracing would make a *nice* embarassingly parallelizable problem for a "lots of dumb fast cores" design. With the amount of resources that go into a typical CPU or GPU it should be possible to get a decent raytracer with a decent frame rate. The hardest bit would be memory fan-out to all the cores from the texture and mesh.

Hmmm. You could probably just pass a stream of <face,texture,scale> tuples to the dumb cores, let them return a list of <texture,u,v> tuples for each pixel and do the compositing in the primary core. That way you'd only have to broadcast the mesh for each frame.

I want a simulator just for the ability to change the sun to always midnight so that I can create my vision for an environment using very carefully positioned lights.

It would be nice to be able to switch off ambient lights in a simulator and free these up as extra light sources, that way even people who have 'sun and moon only' selected for lights would at least be able to enjoy such environments, as two should be plenty if my planned set-up works as I hope. Also, the ability to restrict the lightsources a user can render would be even better, now I think about it having only two active lights in my environment may actually provide a much better visual effect.
Imagine a large corridor which has lights spaced evenly alternating between each side, if you only renderered two of these at once, you'd have one awesome effect as you walk down a corridor that is pitch black ahead of you until you 'get in range' of the next light.

So yes, more light control for simulators would be nice, I won't go into ray-traced lights and such, I don't think the main SL client is nearly efficient enough to go into that yet. Simple directional lights (e.g spotlights) would be nice, full dynamic shadows etc aren't a big priority for me.

There are a few solutions.
1) Shadowmapping
Pro: Fast
Con: grainy
How it works: the scene is rendered from the lightsource's point of view and the rersulting image is textured over the shadowed objects (not sure how, but I think it involves a depth map)
2) Ray tracing
Pro: looks shweet
Con: takes a long time relatively (longer if you have raytraced reflective or refractive surfaces for obvious reasons)
How it works: rays (lines) are drawn from lightsource to object causing luminencence. Where rays don't hit (or don't hit often (think those long tube bulbs)) the surface is darker. Increasing the acuracy of the rays increases the quality, but exponentially increases the time.
3) Pre-calculated lighting (photon mapping)
Pro: only needs to be calculated once
Pro: looks VERY accurate
--because it's a raytraced effect, you get ambiant reflected light and crisp shadows
Con: takes a LONG time (on a scale of 10 frames of raytracing)
Con: not good for dynamic lighted scenes
Con: Only good from one camera location
How it's done: I'm not really sure. It's essentially a tracing of where every photon from a light scource travels to, creating a kind of particle cloud of lumincence which is baked onto the texured objects. Only saw a demo of this once.



I think it'd depend on what method was used. If you used shadowmapping it'd be possible for the server to do that and just send it out as another texture instead of making 14 clients render it all. Raytraced? I think it'd be too much for the client. Get a hold of a 3D modeling software (Maya, 3D Studio) and poke around with the different lights. A simple shadowmap (512x512 pixels) is ussually enough for a scene and each frame takes <1 second to render. Do the same scene with low-quality rays and the time jumps to 5 seconds or more (and with possibly little change in shadow quality).



SL uses more polys than entire Quake levels (and Quake, BTW, bakes it's shadows onto the objects. It's done once on level initialization of the Quake Engine designer (if you change the light sources the shadows don't change until you tell the engine to essentiall reset). The game itself never does any lighting.
How do I know? I got to see a demo. The level designer looks like a modified game client. You do all your level creation in real time while the level runs its course. Very useful, actually. See how well the AI handles your map, watch scripted events trigger...

Remember one of the biggest issues with any kind of mapping/pre-rendering in SL is that the sun MOVES. A shadow-map you generate may start looking odd only a few minutes later. As well as for the moving lights.

Meaning the only real option is still ray-tracing or some kind of 'dirty shading' where you take the basic shape and make a fuzzy shadow, essentially a sprite that gets moved around based on the sun's position, increasing in size and fading with distance from the object (e.g a cube 20m above terrain would cast a large square shadow onto the terrain when the sun is directly above).
iirc SL added that kind of shading along with vertex shaders in 1.10? Mac still doesn't have it, not a big surprise there, do LL even have Mac devs?

Here is a demo of a quick raytracer. You'll notice it leaves out most of the depth that professional raytracers do. However, even if SL was able to look half this good, it would be a major step forward!!

Try the demo:
http://www.pouet.net/prod.php?which=9461

It was stated that a quadcore PC with today's technology would be able to do a full raytrace at over 60fps.

With SL today, the problem I see is that the OpenGL interface forces a GLX scope. Most implementations of GLX are done at the GPU driver level. I haven't found a free GLX implementation over X11, for instance. Not even Mesa does GLX over X. Since SL uses GLX, it forces the user and the program to be located on the same local machine.

I'm one step into the future at home. I don't just have single internet PC. I have a home network with a server, router, and many connections. If I'm able to run a portion of SL on the server and the rest on my portable connections - awesome. Obviously, the current SL client design needs a major revamp to support the full horsepower I have here at home.

My argument here isn't just "raytracing is best" and "lets put up a raytrace feature request". My argument is the knowledge, or the transparency, on the LL side of these graphics.


What's the first thing people see when they experience SL? ... eyecandy!

...You obviously havn't done any 3D animation. The program knows the light moves, and gasp, does a new shadowmap. The real problem with using a shadowmap for SL is the sheer size. a 512x512 shadow map* would give you 4 shadow 'pixels' per sq. m. of land (which is a 256x256 texture). A good shadowmap for a SL sim would be 2048 to 4096 pixels in size (16x16 to 32x32 px per sq m).

The sun's shadowmap would be regenerated when it mores (every 6 seconds? I forget how long it is), other lights could update ever 1 or 2 seconds. Sure, not the best looking moving shadows, but it wouldn't be render intensive (other option is that the client renders shadowmaps for the local lights it has on and does so as often as the user wishes (Graphics. advanced -> "Render local light shadowmaps every [X] frames").

*In 3D animation, a 512x512 shadow map is ussually good enough for a final render that's 800x600 or smaller. A good gauge is your shadow map is to be as big as the final render size. Larger is unnessessary as the differences are smaller than a pixel in the final render and smaller (by less than 75%) starts making it look blocky.

Um...exactly my point, a pre-rendered shadow map is no good, a constantly re-rendered one will become performance intensive anyway. Therefore shadow maps are no good at all for a dynamic environment.
You don't render a shadow map for the entire simulator, it'd have to be re-rendered every time the sun moves, and every time the objects move, getting it hi-res enough to handle the entire simulator will end up with either a horrifyingly slow shadow map, or a really craptastic looking one.
Shadow maps would then have to be done per object, each object then has it's own 'shadow' which can be applied to the surface of other objects and/or the terrain, but even then, moving objects would have to have their shadow maps regenerated all the time. It quickly reaches the point where ray-tracing uses the same or even less processor resources.

Shadows also have to take into account objects with transparent sides, or alpha mapped textures, not as easily processed for shading, and which SL already handles very poorly. If an object's transparency changes then a an otherwise unmoving scene needs to have parts recalculated.

Yes raytracing can look good, but that is an internal scene. Raytracing an outdoor scene is something completely different.

With raytracers, an internal scene and external scene use the same amount of process time. Raytracers are burdened with sheer number of prims and memory speed to sort them.

I'm sure it would be harder to show the full effects of shadows in the demo if it used an external scene.

Did you notice how you can turn the view around in the demo. You can't control the path of the camera, but you can turn the camera around and look out the stained window -- nothing much to see except outside light.

GPUs don't usually ray-trace. An external scene is harder for a GPU to process because of its occlusion process and other tidbits.

Given the same number of polys, yes. BUT...

The difference in the number of prims (and thus polys) between an indoor and an outdoor scene is enormous, and now we have object occlusion you can really feel that effect on your frame rate. Go to a big shoppng area like Plush and hover over a region with draw distance around 256, and compare the scene complexity to that inside one of the stores.

I found one comment in that demo interesting - "no triangles".

I wonder if they're getting the speed from doing algorithmic intersection (like the early raytracing work used) rather than generating a mesh from the primitives. That would be one way to significantly improve raytracing in SL.

[edit: Yes, that's exactly what they're doing. Many more details at Realstorm]

It all comes down to "SL doesn't have the power to do shadows" at this point in time. Either the client is doing if, forcing most users to turn it off in favor of FPS or the sim is doing it, thereby increasing bandwith we can't spare and sim CPU cycles we don't have.



1) I don't think I was getting 60 fps. I was getting some major chopyness
2) I have no indication that it was real time.
3) Take a look at the resolution. 512x384 (half the resolution of my screen) or 640x480--a screen resolution long since abandoned for 800x600 and higher. Of course it'll look good; the resolution is shit. Try getting the same engine to render that at 1024x768, bet you it slows down to less than 30 FPS (12 to 18 is my bet--4 times the rays, 4 times the render time, 1/4 the speed).

...add quadcore and you get a times 4 bandwidth and a 8 times parallelism.

Quadcore technology has only proven that it is practical. However, when we started to add much more than just visual processes, we need the process power to do all the other tasks also. The cell processor is the first major parallel processor on the consumer level. We can expect to see something between Intel's quadcore and IBM's cell processor together with added subprocessors for a future desktop model. GPU makers are fighting this big time right now. Look at the latest GPU design and you'll see basically the same model for future CPU models. GPU's can stay ahead of the game because they don't have to support all the drivers that the mainboards has attached. However soon... GPU makers won't be able to lower their production cost to beat the newer CPU models. At this point, ray-tracers will be a very competitive graphics package. And consumers will ask, why upgrade the GPU when you can get more power overall on the CPU?

It's a known trend -- to go from centralized processors to decentralized back to centralized... and back again to decentralized... and so on...

Then what was the point?
"If we can do it with a quadcore, lets implement it before everyone has quadcores"
I don't even have a DUAL core machine yet.
It's not about what the technology of the day is cabable of, it's about what the technology people currently own is capable of (which, as we all know, is anywhere between 3 months and 5 years out of date--my own machines are over 2 years old).

Besides, the cell CPU is a whiz at rendering, but I'd never play any games that need AI on it. AI is damned near impossible to code on a cell processor--at least if you want it to be intelligent.

Transparency in design as it regards to lighting. Shadows is one topic to pick first. Even if you don't have the hardware yet, the software still needs to be able to support it. There are machines out there that can do it. As I stated from the start, this isn't a feature request.

Since LL has approved of custom clients, I'd imagine such lighting data could be found from some external source other than LL's dataservers. A Custom client can search both the LL asset server and another external assest server to get the full data for a scene. *wink*

This seems backwards to me. The way I understand computers and "game" quality is that game makers find ways to use harware abilities to do the best it can, then the hardware gets better so that it makes the games faster which only causes the games to do more.
Not the other way around where a game is capable of something that the hardware it's being designed to run on can't do such that when the hardware gets better the game is already there.

And why would you need an external source to do lighting data? Everything you need should already be there from LL servers.

If the product is made as a specific closed box consumer end unit, you'll find that may be true. However, it is not true for products that use open standards. With open standards, neither the hardware nor the software drives the other.

In the past, software was customized for the hardware because the limits of the available resources required it for the unit to be useable. Today, electronic computers have lots of resources available to spare, and the software can be made free in design without any specific hardware limitation. Of course, it is not perfect like that.

When software is correctly programmed, its performance will scale as the hardware scales in performance.



Note how you say "everything you needs should already be there". In the realm of the metaverse ideas, LL will not be the only asset databank.