Shadows and lighting update

And for those average users SL is currently tweaked to maximize the full potential of those average systems. There is no more room for improvement. There is only so much those systems will do. This should not prevent LL from developing for newer systems. SL will not stop functioning for those average systems, they just won't be able to run the newer eye candy. The tools are provided in preferences to switch off or lower settings so that SL will run on old systems, even systems not described as supported.

I just got around to testing Vittorio's build of the Shadow client and I spotted something very fancy indeed!. It supports real bump mapping!!. To test it, set shininess to medium and set bumpiness to brightness, then apply a nice bumpy texture to your prim too. I found the SpanishTile texture works great.

Oh and some nearby point lights really bring out the effect too!

That's what brightness bumpmap does, even in the current production client. (Darkness too) Sadly it's not adjustable, I think the default is too bumpy for my taste.

I would love if they added support for bump mapping with actual bump maps which are seperate from the texture.

Since someone bumped the thread anyway .

A friend who compiled the latest iteration of the viewer managed to get it working with shadows on a nVidia 7600 although she said it looked "weird" so no idea if it's acting up or showing different than what you'd see on a 8xxx.

you know, I compiled the latest last night, and it was acting 'wierd', even on my 8xxx. It seemed like the shadows were reversed or something, I would see phantom shadows following my camera around as if there was some object always behind it. very frustrating. So it may be the revision itself has some issues, rather than your friend's card.

Since it's very much a work in progress I'm suprised it's as functional as it is .

I haven't caught up with the last two revisions yet . I'll let her know to try and grab an earlier revision from SVN and try again, thankies .

No wai!!

The bump mapping in the Shadow client is *real* bump mapping. It's like on a totally different level!. Go look!

The rest of the bump maps don't work at all. Only Brightness or Darkness. Also, what's weird is that when you enable bump mapping on a prim then it no longer casts a shadow. Still, early days yet!.

But seriously, to compare the standard client's pseudo bump mapping to the Shadow client's is like comparing night and day. What shows off the bump mapping best is to enable bump mapping on a prim, place a point light in front of the prim and then drop the texture anim script into it. I tried to recreate SL's water with the new bump mapping, but the bump mapping effect is lost when I enable transparency.

Just go look!. It's like really cool and stuff!

Edit:

and don't forget to enable shininess!

I bought the 7600 and it was "ok" with SL, but being the geek that I tend to be, I turned right around and bought the 8800, and now looking to ebay my 7600. Honestly, I couldn't see any difference between the two.

I have posted on this thread and many times before how much I look forward to seeing proper shadows in SL.

However, I just thought of a possible problem - shadow griefing - like if somebody builds a huge ugly megaprim wall next to your home, the whole place might be in darkness for half the day.

Exactly.

I have a GeForce 7-based graphics card, which still runs everything I need fine. It wouldn't run Crysis, but I don't have any interest in playing Crysis.

Seeing as SL still has a worse framerate than the Glide demo for the 3DFX Voodoo chipset released in 1996, I find it difficult to believe that the existing SL graphics are the maximum a GeForce 7 can handle.

I've joked about that already .

There's a problem with local lights as well: you might not notice it in the regular viewer but quite a lot of places (or avies for that matter) have far too many lights, others have far too few lights or lights that are just far too bright. Bay City is a prime example... zoom out, set to midnight and you'll see all the light pollution. Most will be dark except from some spots that are entirely bright white.

When and if this ever makes first look, people who don't have the hardware for it (or don't use the new viewer) will be at a disadvantage. What looks good in the shadow draft viewer does tend to look good under WindLight, but the opposite not so much. I've had to turn it deferred rendering in quite a few stores because the lights there turned the entire store into one washed out shade of white, others because I couldn't try on a demo and actually see much of it.

Same with people who use facelights. It might look pretty in WindLight but your face/body/anyone near you ends up looking bright white with anything but a subtle one and that halo of light you have around yourself is definitely unnatural even when it's a subtle one.

I can't help but belabor this point (which by now is somewhat like beating a dead horse). The reason console games, and the Glide Demo, and Half-Life, etc run so very well is because EVERYTHING - the positioning of the geometry, the lighting data, reflections, visibility - everything is computed beforehand, and stored within the map data.

Let me give you an example. I used to make levels for Half-Life 2. My pride and joy was a complete recreation of the castle from the old AD&D module I-6, "Ravenloft" - a fantastic module, that came with complete maps and blueprints (albeit not without a few minor errors) for the castle, elevations from all angles, everything you need to build a 3D representation. I managed to squeeze it all into a single Half-Life 2 map, so you could explore the entire castle without a level transition. However, building this required very careful alignment of the structural elements to minimize the number of faces, it also required "back-face culling" - essentially, marking any face that would never been seen so it wouldn't be drawn. It required careful consideration of lighting, cubemaps (reflections), and visibility breaks - to prevent the entire castle from being rendered no matter where you were.

Once the drawing of the map was complete, it had to be run through three special compilers: one to break down everything into CSG (Constructive Soild Geometry), basically turning it into prims and calculating collision boxes (ie, where you can move); one to determine visibility, meaning breaking down the map into small regions and scanning each and every player-accessible spot to see what other "regions" are visible from said spot (to cut what's drawn to a minimum for any location); and lastly, the lighting - the longest computation by far - to determine how the static lights would affect the look of each and every face.

This process, for my Ravenloft map - called compiling a map - would take approximately 48 hours for a finished-quality render on my old Athlon XP 2800. A test compile, done without quality lighting, would take about 8 hours. Cut out the lighting altogether, and get only ambient lighting, 2 hours.

(After the compilation, an additional process would be required to build the cubemaps into the level, and to determine "paths" for AI-controlled NPCs to wander. However, since SL doesn't have reflection or AIs, we'll leave this aside.)

Secondlife is doing all of this work IN REAL TIME.

Let me say that again, since it really bears repeating.

Secondlife is doing this entire, 2 to 48 hour render, IN REAL TIME.

So yeah. Don't expect SL to give you 120fps like you might get in HL2 or GTA on the same hardware.

That all being said, there are things that you as a content creator can do to improve the experience for everyone. Keep textures to a minimum. Keep prims to a minimum. Line up your faces. Anything that doesn't HAVE to stop a player's movement should be phantom, so they physics calculations can ignore it.

An example of a way to make it easy on the physics engine, that I hope will give you an idea - if you have a railing across a ledge, and you don't want players to jump over it (ceiling height or something prevents it, say) - you're better off building a solid, invisible wall reaching all the way from the floor to the ceiling, and a phantom railing. Why? If you have a non-phantom railing, the physics calculations have to consider the space /under/ the railing, and /over/ the railing, and between the stiles, all separately. If you do it the way I've described, you end up with "inside the railing and outside the railing" - otherwise, you get "inside, outside, above, below", etc - with many permutations if your stiles are wider (or narrower) than the railing itself.

That's just one tiny example of the myriad of calculations that have to go into presenting you with even a simple SL scene. Imagine how it escalates with complexity.

I think this is the longest post I've ever made on the SL forums. I hope it has been... enlightening...

-Buckaroo

I do know that well. But you've essentially made my point for me - if the bit of SL's code that does all the things you've described (or at least does the best it can) was better, then SL could run much better without needing an upgrade to the graphics hardware.

Another point is that - what you suggest is unnecessary too. Many, many, MANY parcels in SL are now set to no build for everyone other than the owner(s). So why not a Tools -> Bake This Parcel option which sends your PC off for a couple of hours doing the rendering, and then every visitor gets the prerendered version, and they can all see it at Ultra-equivalent quality on even a GeForce 2?

Well, that's the problem - it's not the code that needs to be improved, it's the builds. Well, yes, the code could probably use improving, I'm sure - but something like that would be massive. And you'd reach a point of diminishing returns - one cannot make a filet mingion from ground beef. It does the best it can. There are certainly things that can use improvement - the occlusion culling in the client now is positively rancid (meaning, not drawing stuff that you can't see from where you are) - but without extensive calculation, it's a very difficult job to do - especially when you start throwing in alpha textures. Do you count the whole face as transparent? Or just the part that is less than opaque? What would really improve this area is ray-tracing - which is just way to processor-intensive to be done in real time, given current hardware. It's coming - but it's not here yet, and I'm not holding my breath.



The problem with this is that if you move a single prim - you've got to start all over. The slightest change in geometry means recalculating everything. However, I get your idea - and again, it's a matter of coding for it. SL was designed to be a dynamic world, not fixed - modifying it to support both would be ungodly complex, and would be a maintainability nightmare for the coders. In a perfect world, sure - but don't expect it before SL v9.0

-Buckaroo

No, I think it's more contempt for people who expect the world on an outdated video card. Sure, a 3 year old card isn't really that old, but in the video card market, due to continuously upgraded features, it's virtually ancient. Believe me, I totally understand, I myself have a 7600GS and it's only about a year and a half old, but if residents want the new bells and whistles, the only way to get them is to keep up with the video card market, which can be expensive. The problem is that people generally think a video card is a video card, and that LL is being lazy by not coding the client to work the magic with their dated hardware. I think that's where the contempt comes from. What it boils down to is if you want to run with the big dogs (and cast shadows while running), then you're going to have to pony up the cheese for a new video card. If you can't afford it, you can't afford it, but don't hammer on LL for being unable to code their way around your inability to purchase a new video card.


http://secondscripter.com/

gettin kinda snotty for a 1999 graphics engine thats at best total crap for 1999

lets face it, untill the recent clients (starting with ripple water) sl looked worse than a ps2 game, and that thing didnt even have a gpu

ive got a overclocked 6600GT in both computers (agp and pcie cause they were powerful and cheap)

now when i can run doom3, cod4 and need for speed carbon on them, full options @ 1280x1024 ... (yea i know its all pre optimised but still these are things that are 1000000x better looking than SL's client ever hopes to be)

but SL with its "tomb raider" avatars and its really really low poly counts, meh lighting, bad looking water (what the hell happened there) now wants me to have a 8 series just for the same thing i really start to wonder

A) WTF
B) wheres the next gen viewer ive been hearing about since 2005, maby then it wouldnt need a cray to only get half way modern graphics

Nonsense! If that is true, how come I've seen an editor ("Garry's Mod", I think) where you can place random objects, move them around however you like, and all the shadows and lighting update dynamically with no problems?

Now, ok, the objects in Garry's Mod are fixed. But if it's possible to pre-render an *object* and store all the data for it in memory, and then use that data to keep it looking good and running fast even when it's being moved around randomly, then why doesn't SL just do that for each object on the assest server? Probably 60% of SL users don't build with prims, and even the prims themselves could be precalculated in the same way.

Wouldn't that work for SL?

I'd be much more inclined to buy a new graphics card if they could show some proof that "Second Life: Source" couldn't be done

i am sure there will be a checkbox in the gfx settings to enable/disable shadows if they implement it in 2010. so whats the problem? just turn it off ^^

Guys, stop being cheap and upgrade to use windlight.

Windlight is great, makes avatar meshes 5 times uglier than before. A real bonus if you ask me.

reading this thread, ive wondered:
has anyone checked wireframe mode in the shadow client? given how they dont employ vertex lighting anymore, they could optimize the tesselation on planar faces a LOT, thus cutting out a nice wad of unused triangles which were only there so vertex light looked good enough.

that along with some adaptive tesselation of other primitive meshes (like long, thin cylinders receiving less circumferential sections compared to thicker cylinders) could be a respecteable performance boost, since mostly, what makes SL graphics chug isnt only the textures, but also the sheer amount of triangles the engine needs to process. and if they can save there, that can only be good.

ontop of it, I would love to see better handling of resource heavy scenes. right now, the engine seems to unload all textures and meshes outside of the view frustum, making it stutter and lag whenever you turn. in the day and age of 2gb+ ram and 512mb+ of video ram, wouldnt it be possible to let SL actually handle these resources a little better rather than caching from disk EVERY time I turn the camera?
if you cant help it, at least load in LODs and mipmaps first, so you get a smooth rezing-in effect, rather than the entire application freezing for up to 10 seconds before all data was loaded into memory at LOD 0 detail


edit: and I agree, the avatar meshes in windlight look horrible in 70% of all lighting conditions. the vertex lighting makes any crease or dent stand out tenfold and make everyone look 30 years older. I hope with the new pixel shading, this issue belongs to the past

could someone recompile the shadows pack for the latest RC, i cannot find RC9 anywhere