[sldev] Reviving a lost First Look feature - water reflections?

Dave Parks davep at lindenlab.com
Tue Mar 6 15:58:11 PST 2007


Actually, I just (about 5 minutes ago) committed the re-introduction of 
a prim's light color effecting its ambient value.  I went with an extra 
render pass to avoid thrashing the pipeline with glLightModel calls, and 
I called the pass PASS_GLOW because I'm planning on adding a bloom to 
them as a debug option.  Step 2 is rendering the bloom sources into the 
dynamic reflection map so shiny things will pick up that bloom in their 
reflections.  Step 3, of course, is adding control over the bloom effect 
to face texture parameters and letting things bloom based on diffuse 
lighting.

I dig how you guys are RIGHT THERE with where we want to take the 
viewer.  It's going to be challenging coming up with a viewer 
architecture that facilitates the addition of rendering effects from the 
community without sacrificing consistency, stability, or speed, which 
brings me to my next point:

SPEED

Average frame rates in Second Life suck.  We know it, you know it, and 
the cause is pretty clear: the viewer just wasn't built to handle what 
residents throw at it.  I believe it's possible to achieve 60 fps in 
Second Life without sacrificing visual quality, and I think that would 
happen a lot faster if the open source community rallied around that 
cause.  Profile against your hardware, let us know where the bottlenecks 
are specifically in the code, or better yet, diagnose the problems and 
submit a patch that fixes them.  I know for a fact that there is plenty 
of low hanging fruit in the viewer performance wise, and I know you guys 
can help find it.

More importantly, though, STABILITY

Crash rates in Second Life suck.  Internally, we have a very hard time 
diagnosing many of the crashes that we see.  I really appreciate the 
crash fixes that have come in, and I want to see more of that.  Bottom 
line: the viewer should never crash on capable hardware.  If you're 
running the viewer under a debugger and it crashes, chances are pretty 
good that you're looking at a stack trace that we haven't seen 
internally.  Believe it or not, when I'm running the viewer under visual 
studio and it crashes, I tend to fix that crash.  If you get a crash 
that's deep in the GL drivers, all that shows up in the crash report we 
get is something like "atioglx.dll+0xF00BAR".  If you've got a debugger 
on at the time of the crash, your chances of diagnosing and fixing that 
crash are a lot better than ours from reading the report.

I'm not too proud to say it: if we're going to get crash rates to an 
acceptable level, we NEED your help.  If you've submitted a crash fix 
and you feel like it's being ignored, SEND ME AN E-MAIL DIRECTLY and 
I'll get back to you.  I'll be thrilled if that responsibility eats up a 
significant part of my day.

Thanks so much for making this work as an open source project.  I can't 
tell you guys how thrilled I am to have such a strong development 
community crop up after such a short amount of time.  Keep it up!

Oh, and if you're at GDC tonight and looking to break out of the games 
industry, stop by our recruiting party.  It's at 7 PM at 111 Minna St, 
San Francisco.



Callum Lerwick wrote:
> So who's going to be the first to hack in shiny happy fake HDR effects?
>
> http://harkal.sylphis3d.com/2006/05/20/how-to-do-good-bloom-for-hdr-rendering/
>
> Or perhaps actually implement full HDR...
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>   



More information about the SLDev mailing list