[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