[sldev] possible rendering improvement
alpha.zaius at gmail.com
Tue Jan 16 06:54:25 PST 2007
Im not a 3D programmer of any kind (I tried playing with openGL once) so if
I sound absolutely stupid.. sorry. You can skip over my message.
Stef, you have a great point. But doesn't the client already go through each
prim for viewing frustum culling and occlusion culling? (or is that done
through the GPU :X) If it is done through the CPU, and you already have a
loop going through the objects.. why not put one more statement into the mix
saying that if its alpha is 0 when it is rendered, then don't render the
vertices at all..
Its a great idea, although it can be a double-edged sword. If there are no
invisible prims, unnecessary checking takes place. But if there are 300 or
so, then it can deeply improve performance.
Now remember, Im no 3D programmer, and I didn't go through the rendering
code for primitives yet. Here's an idea though. If each primitive is stored
into some form of an array - can we not add an extra LLBOOL that determines
if the prim is completely invisible or not on all faces. When the prim first
comes into the array, check for this (checking the textured faces) and
change this LLBOOL accordingly. This way during the rendering process, you
can save some extra CPU time by checking this flag instead of checking all
of the faces in each frame. During an object update, this flag has to be
invalidated and checked again in the case the object was turned invisible.
On 1/16/07, Stef Wade <Stef.Wade at stots.de> wrote:
> die_angel schrieb:
> > [...]
> > A lot of attachments use llSetAlpha to show/hide accessories, and the
> > way it work currently make it so even of somzething is fully "invisible"
> > it is still rendered. (or am i wrong?)
> Without looking at the code, it is probably a question about what's more
> expensive: Checking _every_ surface's alpha-setting or rendering
> invisible surfaces. (Maybe we should take a walk through the grid with a
> modified client that counts surfaces...)
> Checking for Alpha would put load on the CPU, unneccessary rendering put
> load on the GPU.
> http://LinuxBasics.org http://Krone-Neuenburg.com
> http://Stefan.Waidele.info http://sl.stots.de/blog
> Click here to unsubscribe or manage your list subscription:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SLDev