shadow texture layer

most games today have something called lightmaps, they are textures that contain shadow informations and that are applied on top of the bas textures as an overlay.

What would bring a lot to secondlife is a special texture layer dedicated to applying lightmaps.

Some creators in sl are making theyr own lightmaps in second life, the problem is to apply them, there is two solutions:

-add the shadow to the texture before uploading it
-use a thin primitive that will hold the shadow map as a transparent texture

the first solution pose a problem of cost and a problem of size, it force the texturer to make a new variation of the texture of the wall each time the shadow change in the same room (wall corner, middle of wall, doorway, etc)

the second solution make the primcount increase dramatically, the advantage, we can have the shadow on a much smaller texture and it will load fast, HOWEVER, it makes more prims to load by the client and a LOT of alpha textures, wich make it quite laggy too.

what i am suggesting is a new texture tab: the first one would not change, but the second one would take a grayscale picture (or an alpha, depend what the programmers prefere to work with) that can be limited in size if we are concerned with textures downloading, and has its own allignment parameters.

You would use the first texture slot for your base texture, wall, stone bricks, anything, and then add your shadow map to it:

here are a few example, the first one is how sl is doing, the second and third have more or less marked lightmaps applied:

picture here :
http://ethernia.net/shadowing.jpg

That is a simple cube. To create shadows on much more complex prims would, most likely, grind SL to even more of a halt that it does now with local lighting on and SL's LOD. While I agree it'd be nice, SL just needs better optimization of its EXISTING technology first--not MORE things to drag down its framerate.

you didn't understood it would be a simple texture overlay, of low resolution 64x64 pixels or less, it would be like putting an alphaed prim in front of your face, without the strain of one more alpha and without the strain of a new object geometry

wouldn't be really that heavier

Ah, yes the ability to put several textures on a single surface like we put clothes on our avatars. That is what ( i guess) you meant.

One would think there would be double more textures to load but what is that compared to having a second prim ontop of the surface with a shadow texture?

Oh, I understand shadow maps, but they ain't 64x64! Go play Oblivion and see their shadow maps--they're MUCH higher-res than 64x64. They also lag like a sumbitch on my fairly decent system (Pentium D 2.8GHz, 2GB PC4200 dual-channel DDR2 RAM, GeForce 6600GT 128MB) and I'm JUST below the RECOMMENDED (not minimum) system requirements.

SL'd probably choke and die with more complex shadows since it doesn't have occlusion culling, although it could have a shadow map distance setting like it does for bumpmaps, but it'd still be laggy compared to SL's current shadow system (which is pretty crude as it is) and I'd rather see the MANY bugs fixed BEFORE new features are added!

Shadows are 'render expensive' in any 3d system.

What I'd like to try is a texture that changes during the day by script to accord with the movement of the SL sun. You'd bake the shadow gradient into about 8 maps, and the script would rez them onto the floor, for example, as SL sun angle changed. You could even script a cat that always moves so that it lays in the warm sunbeam of a window, or cathedral prim-volumetric-haze lights whose angle changes based on where the sun is at that moment. Or, geez, a Chichen Itza, where shadows tell the story at certain times of year.

But this has surely already been tried...

eep lightmaps, even old engines like half life used them, its SIMPLY a second texture applied on the original texture, the interest is that shadow maps can be very low resolution compared to the texture behind it (unless you want to have razor cutted shadow)

sorry for the wrong word, use, correcting on all posts

Aww, they're not so bad... you can do one level of raycasting and fake the blur, and even refraction is doable in limited cases without full raytracing. Simulating indirect light glow, pinhole effects, chromatic abberation, and diffraction... now those are a stone bitch.

This is quite a nice idea actually. Especially as it allows the builders to ignore the position/settings of the SL sun. Currently I use a really basic form of shading in 'full bright' rooms by just using a darker colour for one half of the room. Quick, dirty, but it works and it doesn't require extra load.

The shadow map idea would be nice, especially if you can do some of the same things as textures such as flipping/rotating them.

I think that before SL re-does it's lighting, it needs a better method of removing geometry that you can't actually see. While it's improved a bit recently, I still find that I can lag in a room by facing a wall behind which there is a prim-heavy build. e.g I built a bath-house extension for a larger house, if I go in, do a 180º turn and look back in the direction of the house, then my FPS plummets even though none of the main house is actually visible, the walls of the bath-house are seamless. As such proper lightning should be steered clear of, can you imagine rendering all those objects AND the lighting required for them? That's why local lightning kills babies at the moment I think.

But then, the original poster is raising an interesting question, do we actually need any of the more 'advanced' methods of lighting? People in SL are building with an exact idea in mind, placing your shadows precisely is a better way of doing things if you know exactly what you want, but want to cut down texture download all the same.

it seems the SL engine draw a few stuffs even behind you, out of your field of view, you wich i am not sure why...

textures loaded in the shadow channel would get a lower priority, so the main texture would load and then the shadow would slowly unblur itself

As someone who has had a full 6 months of 3D Modeling behind him (school), shadow maps are the one non-render-time-intensive kind of shadows.
However, you need to have a shadow map that is at least as large as the frame size that you are rendering or the shadows go blocky (causes an interesting effect though).
The problem with shadow maps: they don't look terribly accurate and do requiret the machine to render the scene from each light to create the shadow map (lights are render-time heavy, shadow-casting or not).
Raytracing takes HUGE amounts of time, regardless of LOD. Heck, there was one student who for the final project had to abandon lights and shadows all together of have a render time of 3 days or more. He used a Max Script that simulated lights and shadows and got his render down under 3 hours (and we're talking about a 30 second animation).

Still, for SL I'd like to see the frame rate over 40 consistently (with local light turned on) before we start adding new effects like shadows (I hear our current particle system causes about 10 times the lag it should).

o.0

*Stops modeling 'Stone Bitch' sculpture for his property.*

i already apologised, i talk about lightmaps, wich are rendered one time during the architecture creation, not something dynamically generated, and you talk to someone that has 4 to 5 years of 3D modeling behind her.

a shadow map is just an extra info layer for each walls of a scene that tell to the engine how bright or how dark is this pixel compared to the origin picture. It's like pulling the shadows from a baked object.

Hmm, I don't see why people are so confused about it. But then I'm a map-maker for the Myth series of games, where the map is one giant image, and the shadows are a giant greyscale image applied over the top of it, called a shadow map

It's like taking a texture and then saying to SL "this next image is what the shadows will look like". It's nothing dynamic, nothing involving ray-tracing, fuzzy light projection or light-source of any kind

It would be cool though if SL had the functionality to support shadow-maps, and then the ability to generate them based on local lighting. ie you select a load of prims/surfaces and choose "render shadow maps" and generates some shadow map layers for you. But that's getting extra fanciful

Well it SL does already do baking to some extent, all clothing layers are received as textures by the client then baked down into a single layer once recieved, if you own all the permissions to what your wearing you can even baked down the image from the debug menu. I do like the idea of having sl bake out the lighting information, similar to how engines like the second geration unreal engine baked out a static lighting model before compressing the level data, but I'd say have the users computer do it and re-upload it, the server has enough to worry about without having to think about baking light.

Because SL lacks occlusion culling (though I hear 1.9.1 has it, or something, but haven't seen it in action so dunno how effective it is).

Great, just what SL needs more of: slower-loading textures. Wee...

The problem with "baking" (merging layers) is that it can't happen fast enough in real-time without dragging down framerate. You'll notice how long it can take for av textures to redownload after a "bake". Now multiply that by, oh, say, 1000 prims in an average scene (to visibility range) and you'll see how SL'd grind to a halt waiting for every baked shadowmap to download--and that's just for a STATIC shadow (which is why ground shadows from prims lag so much).

Baking is inefficient and wasteful. A better approach would be to use layered, or procedural, textures. But, really, until hardware gets faster, and more effects can be done in real-time, we're stuck with limitations. See The Elder Scrolls IV: Oblivion for great shadow examples on its vegetation (grass, trees, plants, etc) and characters--though its "self-shadows" look like crap.

Comparing to Oblivion is still a really bad example, try doom 3 or Quake 4, those are atleast on the same windows crippled OpenGL Libraries as SL, trust me it really does huge difference. If possible give SL on linux a shot most peolple report atleast a 4FPS increase since linux has access to the OpenGL 2.0 libraries, windows only has OpenGL 1.5 and a damn crappy version at that.
Anyway your looking at the down side of it, not everyone will not make shadow maps and making it use SL lighting is most likely a bad idea, but it was a suggestion OH NO! god knows those are taboo, it doesn't make sense for smaller objects or to use high res maps, most shadow prims in SL are at most 256x256 at most and it could be applied on a per-surface instance insted of per object(like shine!), it only has to bake 6 textures for a room insted of of 36. There are a lot of ways to optimize this but insted of discussing your dismissing. Of course people will still be morons with it, if you give people a feature by god they will lag with it, I expect to see 250 flexi-prim hairs when 1.9.1 and if there isn't a club full of them well then people aren't trying hard enough to kill my frame rate heck they're alreay doing it with texture changing rotating tori of death. People will always find a way to kill peoples frame rates no matter what features they have till we're all streaming data down our fiber optic lines into our 3d immersive googles that are drawn at 2kx2k resolution. Culling will never be perfect with SL untill hardware evolves as well, the very nature of a more interactive camera system ensures that, the GPU will have to think very quick on it's feet, infact my guess is that it will cause just as much lag as LOD does on the CPU, and people will still complain about it, I know this well it's my job to compalin to software engineers for a living .

Well, why hasn't OpenGL 2 been implemented for Windows yet? But, really, a whole 4 FPS isn't that big a deal... But, if Direct3D is better, it should be used instead of OpenGL. Linux users be damned (especially since they are a VERY minor segment of the market--as are Mac users).

Huh? Prims are at most 256x256 what, pixels? Perhaps you mean shadow textures, but how do YOU know their resolution? Regardless, 256x256 is 4x as much as your aformentioned 64x64... You're also forgetting the objects casting shadows IN the room, so a lot more than just 6 textures per room.

Also, shine (environment mapping) can be applied per side, not just per object.

Because Microsoft as a stick up thier ass who knows, OpenGL 2 won't even make into vista, switching to DirectX isn't an options because of the major cost involved(Direct X is not cheap) or the complexity of switching, OpenGL is built into every nook and cranny of SL, that and I think the point of SL is to have it work for every OS not just one. DirectX is not better the OpenGL, there's just a difference in graphics models, an apple is not better then an orange. I'm personally unsure if DirectX would be able to handle SL simply because I haven't seen it done to an effective level (active worlds only requires directX 7, none of the fancy stuff we enjoy in 9 and doesn't support a lot of things SL does, though this is a discussion for another thread.As a note appearently it supports OpenGL and software as well still, looks the same on all systems.)

For shits and giggles I dump GLintercept or OGLE frames now and agian oooo I'm so evil , most shadows are based off a single 256x256 texture with four shapes, square, two triangles, and circle on it to reduce texture load(atleast the good ones are).

Inline with the statement above, that would be 64x64.
That would be what I ment, you don't always need to bake shadows onto objects like tables, especially if your trying for the global illumination effect, thus you only need the primary aspects of the room to have shadows generated for them, ie walls floor or if designated major surfaces, this could be done on a per surface basis.

Thats what I said isn't it? Maybe I worded that wrong but still , bump, textures, the cube mapped enviroment all can be applied on a per face/side basis.

Er, why can't OpenGL 2 simply be installed as a 3rd-party app like DirectX is? GLIntercept uses its own OpenGL32.dll so why can't SL?

I think that's what's holding SL back. Having to support multiple OSes is a pain in the ass. Mac and Linux users are in the SEVERE minority. Wasting development time on them is just silly. Oh and, last time I checked, DirectX was free...

It is if you prefer apples. I've never understood the whole "apples and oranges" analogy some people insist on rehashing. ANYTHING can be better than ANYTHING else; it's ALL relative (absolute relativity).

DirectX could handle SL just fine.

Well, just because GLIntercept intercepts 256x256 shadow textures some users may use doesn't mean they were 256x256 originally (since SL rescales them to common powers of 2 resolutions like 8x8, 16x16, 32x32, 64x64, 128x128, 256x256, 512x512, 1024x1024, etc).

But if the room is shadowed but the objects aren't, the scene will just look silly and incorrectly lit/shadowed.

epp please could you listen a bit?

room shadowed objects arent has been used by half life during 5 years and nobody scream at it
You seems to not understand what lightmaps are:

http://en.wikipedia.org/wiki/Lightmap

its pretty simply explained
and i talk about USER CREATED lightmaps nothing like automatic generation

you dont wanna use it? don't

but using it isn't gonna cost that much in perfs

and will GREATLY enhance SL's overall look , even if it's just for baking a domelight, it will produce big visual improvements (domelight isn't light source dependant)

as for directX, personally i am not a fan of it , it is proprietary and limited to the windows platform. So you suggest to drop the mac and linux binary?

OpenGL is the result of a trust of several big actors in the domain of 3D, including microsoft, and you wonder why they are progressing so slowly to implement a new version?

OpenGL is simple to use for the programmer, yet powerfull, compared to Direct3D that is rather clumsy (hell even John Karmack, probably one of the best 3D coder suggested Microsoft to drop Direct3D.)

I'm reading (not listening) JUST fine, Kyrah--are you?

You don't seem to understand what shadow mapping is and just how much of a performance impact it would BE in SL.

Using Half-Life (the original) is a bad example since its lighting sucks by today's standards. However, it's real-time shadows are (were) cool (but nothing special these days), but the lightmaps weren't affected by light sources and didn't change when the environment did (since they were PRE-RENDERED AND NOT REAL-TIME).

Since we need multi-layer textures for this feature, why build it at the prim-level? Do it at the texture level: introduce a new kind of texture that is the (client-side) merge of two (or more) existing textures - maybe even with different blending options.

This would both solve the shadowmap problem and the skin/tattoo fight for the image slots on the skin items.

i corrected my posts some time ago, i talk about lightmapping , not shadowmapping

well a genrralised multiutexturing support sound good, however i dont remember how many "passes" of the graph engin are needed to render multitexturing, i remember in unrealed when you where making a multitexture shader it was informing you clearly "this texture will need 2 passes (or more)".

The lightmap idea would have a quite minimal incidence, byt simply alterating the lightness level of the texture

yes eep it is frozen lights, but a domelight shadowing isn"t dependant of the direction of the sun, it is a simulation of the average light reflectd by the sky and the nearby walls, not taking in account any directed lights.

and even with that domelight look better than the basic sl lightning:
this picture i made has just a single domelight:
http://ic1.deviantart.com/fs9/i/2006/059/2/f/WIP_Crystal_hirez_by_KyrahAbattoir.jpg

baking such type of lightmaps in sl would be great and make the buildings feel more in volume

as for lightmap being a cheap thing, well here are some games that use them:

quake
quake2
quake3
return to castle wolfenstein
unreal 1&2
unreal tournament serie