Realtime Shadows on Linux = coolness

'render-pipeline' branch has Shadows (and native Spacenavigator) support!
http://svn.secondlife.com/trac/linden/browser/branches/render-pipeline

The viewers I could build from this code in the last days seem to be stable enough and I'm using them as my default client. No need to say that SHADOWS ARE COOL (links to video and photos below).

Note that Shadows are OFF by default and you obviously can let them disabled - two new Hardware options in Preferences>Graphics let you disable and enable them at runtime. So there's no need to upgrade your hardware unless you want shadows. I'm using a Nvidia GeForce 9600GT video card.

Here's a demonstration video with some annotations:
http://www.youtube.com/watch?v=cps7xYyEF7U&fmt=18

A couple of photos:
http://www.flickr.com/photos/opensourceobscure/3355337786
http://www.flickr.com/photos/opensourceobscure/3355338970


I'd be glad to share my builds with anyone asking for them.

Do you think it's acceptable to publish viewer binaries this way?
http://drop.io/linuxshadows

What should I do to publish my builds to the public while complying with all legal requirements? I don't have sources to share - those would be unmodified builds from Linden Lab code.
By the way this won't be necessary anymore in the future, as CG Linden is working on a system to give us automated builds on a nearly daily basis.

--
my English may be broken - please report bugs!

That's interesting but I don't think I could live with a frame rate drop like that.

(P.S. Thanks for the video.)

@Opensource

Thanks for pointing to that branch, I will have a look too. Great if shadows come to a state of stability that can be used.

If you provide or distribute binaries you have to provide sources on the same media or on written request according to GPL. As you are using unmodified LL sources a link to the corresponding SVN changeset should be sufficient. If you make modifications you need to provide them along with the binary.

I myself put always a complete patched sourcetree up, its only about 7MB in size and does not need to include any libraries.

....what kind of graphics card would that need?

my laptop runs SL at graphics settings "ultimate" with somewhere 25-30 frames per second, with the shadow client it drops to around 1-2 fps.

and dont get me started about how weird most "3 prim trees" look when they actually cast raytraced shadows.

You might want to make sure you're not linking against any of the non-redistributable libraries.

See http://wiki.secondlife.com/wiki/Third_Party_Libraries (the GPL compatible ones aren't a problem)

For any doubts concerning GPL compliance in regards to the viewer code, ask licensing@lindenlab.com, 'cause LL would be the ones to enforce their own copyright.

here's another video - this one focuses on Multiple Light Sources and ... Projections!
(that is, you can assign a texture to the prim light, and have that image projected from the prim)
http://www.youtube.com/watch?v=c5VCcO7NFpo

Why would that be an issue as long as you don't redistribute those libs itself?

Because the resulting binary would be a derivative work of not only the viewer source code, but also those libs. (Obvious for static linking, as parts of the libs' code are being incorporated into the binary. For dynamic linking the case is less clear and even copyright experts tend to disagree, there.)

Should not be any issue as these libraries are only *non-redistributable*. This has nothing to do with derivative work and linking does not represent anything in this regard. It simply means the binary may use external functions provided by a different piece of software that can carry any license. In GPL in general you do *not* need to publish libraries together with the sources.

I'm not talking about GPL compliance, but compliance to the third party libraries' licenses. Off course, some of them might allow distribution of derived works created by linking, but I don't know which of them do. If someone knows, it would be a good idea to add this information to http://wiki.secondlife.com/wiki/Third_Party_Libraries

If someone can tell (I can't) of which libraries the binary would become a derived work of, if linking against them, that information would be useful, too, of course.

As far as I know the concerned libraries are fmod.dll, llkdu.dll and vivoxsdk.dll. All of them are linked dynamically, meaning nothing of the work in these libs is derived out of the libs which would be the case with static linking. One still needs to have the original libs, that were distributed in some form. Most likely as part of LL's official Secondlife distribution.

I myself simply avoid to get into any issues by providing an installer that runs on top of a SL installation and does not include any of "distribution-critical" components. It's not only the libs, also some executables (SLVoice) and fonts. There is a lot of good development in 3rd party viewers that try to get rid of all proprietary / not freely licensed components (Imprudence, Meerkat, OMV etc.) as well as the trademarked SL branding itself. Unfortunately it's still not up to the same performance level as the official viewer (JPEG2000, FMOD) but things do improve.