|
|
|
There are various ways of implementing. A feature that creates a shadow (on the terrain at least) based on the various x,y,z parameters in relation to the distance from the terrain. An object's transparency value can be taken into account.
Of course this would render all transparent textures useless in terms of lighting. As far as the dungeon / light room example goes, I was refering to any space that you would expect to be dark at any given time, versus a space that would be affected by light on some level. 1. I agree with the toggleable property, since this would allow you to set the prim as non light blocking, thus allowing prims that have transparent textures to not act as opaque. 2. This is also a good idea, it could help simulate shadows or other relevant situations. 3. This should become a must at some point, but only if it is combined with the ability to view local lights from larger distances. Otherwise it will only affect small scale things (in terms of size) I have another idea as to how lighting can be implemented to simulate internal environments. A new feature can be added to the texture tab of the edit menu that allows you to select for example % darker (or lighter) than normal (of course this can be "faked" by adding gray to the existing textures). That way you can manually make textures darker to simulate darker environments. The only downside to that is that unless you have mod rights to furniture and such it will end up looking odd. Unless it is implemented as an editable property that is irrelevant to object rights. I think the best way to implement shadows would be a mixture of all this... 1) Allow the option for a prim / object to block light or not. 2) Create a shadow on objects / terrain / avatars behind it that is based on xyz parameters and transparency (for shape and darkness calculations) as well as distance (for shadow size):
Let me know what you think... NOTE: I am not very well versed in 3-D, rendering and such that are used to create environments such as SL. So if this idea of a 2d polygon based on the 3d polygon is non-implementable perhaps ideas can be taken from other 3d engines that create dynamic shadows (such as the ones used in FPS or RPG's). Shadows may actually happen with the new stuff from Windward Mark, LL is already talking about implimenting light blossoms. But yes, local lights need 1. to be visible from a longer range, 2. need to be more stabile (to avoid the strange shimmer effects in the light cast as the view angle changes), and 3. need to be directable in a beam, with a spot of light on surfaces on which the beam is cast, like a reverse shadow. (example of this implimented can be seen in Halo)
I was amazed and very disappointed to learn that prims cannot cast shadows. It's impossible to have a dark room/building unless you play with settings for the entire sim. You can't even fake it with dark, transparent phantom prims or dark/negative light sources.
Shadows are the way to goto to be honest. And a ambient light setting. With hardware lighting producing proper light responses too.
It would make indoor enviroment darker (but only as dark as the ambient light setting) and lit properly. I know this is an effort in Rasterization engines, and isn't hard at all in Ray-Tracing engines. However Raytracing enignes are too expenisive on CPU / GPU cycles to do it properly in real time. And unfortunatly, I don't know what the limitations of vertex and pixel shaders are. Perhaps you can cast simple shadow rays on a scene with a vertex shaders? Perhaps see if it can see a light source or not, and how many etc..? Real basic raytracing, applied on top of the scene? I dunno. I'm not even sure how it would be implemented. I'm just chucking eggs into the basket. There are two well known and nowadays widely implemented methods to achieve real time shadows:
http://en.wikipedia.org/wiki/Shadow_volume Seems to me, you could render a shadow map as an additional terrain layer and light things according to that. Would be a great improvement over what we get now. There's a NeHe tutorial that shows how to do shadow volumes: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=27 It will work with hardware as far back as a TNT2. You just need a stencil buffer. I just compiled it and it works on my Intel 830M laptop just fine. We eventually want to add shadows in a future phase, including clouds casting shadows on terrain (some of you may recall seeing this in early WindLight demos before it was integrated into SL)
WindLight's such a double-edged sword in that (1) it brings out more beauty inworld but (2) also exposes flaws more glaringly. So, for now, let's consider this a "someday, eventually" – it won't be done soon, but we do want to get to it for the very good reasons described above. (And yes, we're continually reminded of how much shadows add to popular environments like Crysis and other hot games.) I fully support this feature and agree. Made a topic about it here http://forums.secondlife.com/showthread.php?p=1787902#post1787902
 where someone pointed me to this entry. Just hope Windlight won't become the normal client until one way or another, Linden will find a way to add working shadows, both for prims and avatars. Also, this http://img231.imageshack.us/img231/554/ideamu1.jpg would be something interesting to try... A possible temporary solution, which sounds quite easy to implement is to allow scripts to set sky settings, so if the scripted object is owned by the parcel owner, using llsensor or llvolumedetect could define "sky settings zones", simulating a shadow map. this could solve the uglyness of some indoor ambients, and add to builders more stuff to play with. Probably I should make a new Jira feature post for this.. dunno.
FWIW, http://wiki.secondlife.com/wiki/LlSetPrimitiveParams
lists PRIM_CAST_SHADOWS as a property; doesn't currently do anything, but seems that was the intent at some point. Another suggestion: what about image-space ambient occlusion?
It works purely using the depth buffer, purely in image space (so it is independent of scene complexity and won't require any scene management/hierarchy changes nor preprocessing), and produces fairly believable real-time shadows for general use (prims will look less "floaty" and much more solid, but the technique won't do things like generate silhouette shadows which are dependent on directional lighting). The implementation would just add two passes to the rendering pipeline so it ought to be easy to integrate. A simple explanation of the technique can be found here: More examples, variations, and discussion: That's actually an incredible looking solution! An extra one or two rendering passes isn't really the end of the world for the kinds of results shown in those links!
Is there an example shader that does this anywhere? If it's fairly easy to plug-in then we could quickly see what it can do for SL, and what issues are likely to arise (for example, will it play nice with Windlight?) There's an example shader which attempts to reproduce the Crytek approach here:
http://rgba.scenesp.org/iq/computer/articles/ssao/ssao.htm
I've played around with trying to mock up the cheap-and-dirty Z-buffer blurring approach mentioned in the other link (http://meshula.net/wordpress/?p=145 SSAO is now work in progress by Celierra Darling as a Google Summer of Code project, VWR-6975.
...though, I'm working off the shadow-draft branches, so you'll get real shadows too when that comes out. But it might not be in the main viewer for a while.
Thanks a lot Celierra, it's good to know this is being worked on. I kept noticing the missing shadows thing and I must say that lack of shadows is one of the things that makes SL different from most other 3D applications I know of, and in a bad way sadly. Anyway maybe you can release us beta client addons with time if it's possible until its fully ready? If not we'll just wait though... hope it will work out good and LL will also add it in
 Hmm... interestingly enough, I found things such as this http://www.youtube.com/watch?v=-dLgZcoBsu0
or this http://www.youtube.com/watch?v=fHjibHylkkU&feature=related around Youtube. I'd be very interested who made them and how they obtained this effect which is exactly what we want. They don't appear to be custom clients either I think... may a setting be possibly hidden around somewhere and possible to enable? It would be really interesting indeed...
[EDIT] Apologies, that's actually the shadow draft client so yes it is a custom viewer. Any installable version (non-svn, a setup) that we can download? Many people seem to have it already. From what I know. The Shadow Draft client is code being worked on by LL. However it's highly experimental, so theres no official build of it anywhere, yet.
You'll have to ask an open source friend to create a build for you Yes, Shadow Draft is nothing but an LL internal branch of the standard client, where folks like Rutani Linden are testing and programming the new features. I've tested it before. It's still unstable, but a great preview of what they are working on.
It uses so-called Deferred Rendering. Avatar Shadows, Prim shadows, affected by light sources and daylight. Oh, and hundreds of light sources at once on display instead of the 6 + daylight that the client currently is limited to. Good things are coming. Good things are coming indeed. Anyway, someone told me on the forums where I can get the packed source from is anyone is interested. http://forums.secondlife.com/showthread.php?p=2073875#post2073875
. I didn't get it working yet but maybe others can have fun with it already Just hope it won't eat more FPS then the current first look... To Summarize WarKirby's intitial points:
1. light reactive prims. A toggleable property., in the features tab, for example, could cause the object to cast a dynamic shadown depeinding on the position of the sun, and nearby local lights. Shadows would obviously be an option in the preferences menu to turn off. Prims with this setting would also block light, so that objects in their shadow would be shaded. Existing localights should not cast shadows. However, new local lights created should cast shadows as well as have the option of using standard, non-shadow local lights. Dynamic lighting which casts shadows should be, and is, a separate feature from local lights in the deferred pipeline, so this is fine. 2. Negative lights. Essentially, light sources that would create darkness, rather than light. That would be highly useful. This hasn't been implemented yet in projected textures, but could be done using them. 3. Directed lights. The ability to create lights with angled cones. Dimple start/end. Lights which would illuminate only the specified cone, rather than a sphere. This has already been implemented: See Projected Textures. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Prims casting shadows
And how do you define the difference between a dungeon, and a light airy room. For that matter, how do you define a room at all.
Here are my thoughts on the matter.
1. light reactive prims. A toggleable property., in the features tab, for example, could cause the object to cast a dynamic shadown depeinding on the position of the sun, and nearby local lights. Shadows would obviously be an option in the preferences menu to turn off. Prims with this setting would also block light, so that objects in their shadow would be shaded.
2. Negative lights. Essentially, light sources that would create darkness, rather than light. That would be highly useful.
3. Directed lights. The ability to create lights with angled cones. Dimple start/end. Lights which would illuminate only the specified cone, rather than a sphere.