[sldev] Improving rendering sequence

[Dave Parks]

The client sends camera frustum information to the server, and the
server sends the client information about objects that are "interesting"
based on that information. Internally, we refer to this logic as the
"interest list," and it's unfortunately implemented entirely server
side. The gist of our streaming is "stream objects, ask for textures."
Since the network load of a prim is much less than a texture, occlusion
culling saves bandwidth by never requesting texture data for occluded
objects. Unfortunately, since the interest list is based solely on size
vs. distance for sending prims, occluders are often not sent first, so
every texture is visible for at least one frame. It's usually OK,
because the requested amount of a texture to download atrophies quickly
when the texture is not being rendered, lowering its priority as soon as
it is occluded. There may be optimization opportunities in the texture
download prioritizing code.


As far as front-to-back rendering goes to reduce overdraw, work has been
done to this end in windlight, but has more to do with changing the
order of specific types of geometry rather than reordering prims. In
windlight, terrain is rendered after prims, sky is rendered last, etc.
Occlusion culling was also rewritten in windlight to use fewer triangles
and fewer "guess" queries, getting rid of the "guess" queue and making
sure that if something is not visible, it's never rendered.


The biggest issue with occlusion culling performance is that very few
builds have any significant occluders due to overuse of transparencies
and walls that leak (have cracks between prims). I'd encourage any
builders to take a good look at how professional level designers layout
environments in video games. In "World of Warcraft," for example, there
are no windows, and you can never see the complex items inside a
building from the outside. In "Call of Duty 4," there are plenty of
windows, but you can never see into a window on one side of the building
and out the window on the other side, effectively making every building
an occluder. Compare this to Second Life, where every building has floor
to ceiling windows and no inside walls. Some simple tricks to keep your
windows and not kill performance are to make your windows opaque from
the outside. This is the perception people have of windows in real life,
so doing this will often make a build look "cleaner" or less cluttered.


Some builds that play really well with occlusion culling are the
cyberpunk city in Suffugium and the giant cube maze in Q. Let me know if
you know of others.


The other major limiting factor for performance in SL is the small batch
size. On average, SL draws about 70 triangles per drawing call. In
theory, increasing that number to 200 triangles per drawing call could
improve rendering performance by 200%. The primary reason the draw size
is so small is because we have to break batches to switch textures and
to sort transparent objects to be rendered in depth order. This is why
people in the graphics world are making such a fuss over "megatexturing"
and similar techniques. These techniques combine all visible textures
into a single large texture so all your geometry can be rendered with a
single draw call. These techniques require artist intervention from the
get go, however, so most are not applicable to SL. The technique that is
applicable is good ol' fashioned texture atlasing, which is merely
combining several textures into a single texture and modifying object
texture coordinates to reference the part of that larger texture that
contains the texture the object was originally referencing. Since
textures in SL are streaming, though, generating atlases for your builds
will result in ugly artifacts as textures load, so the correct solution
is probably something between megatexturing and atlasing, where atlases
are generated on-the-fly by the viewer and tailored to align texture
borders within the atlas along mip borders according to the amount of
the texture that's been downloaded so far.


We've (somewhat intentionally) done a very poor job at Linden Lab of
educating builders on how to be performance conscious, which I think
plays a large part in the overall sluggishness of the viewer. This is
part of a philosophy that says it should be possible to build a content
authoring system where artists don't need to care about performance
implications, as the software should just deal with whatever comes its
way appropriately. What we've seen, however, is that people (even
technically minded people) consume as many resources as are available to
them until performance reaches a level they deem is unacceptable, so the
more efficient your renderer becomes, the more ludicrous the demands
become. In SL, this usually means the performance becomes that of the
lowest common denominator in terms of what is acceptable. That is, if
you think performance is important and build a nice house with opaque
window exteriors and few textures, you'll still have a bad experience if
your neighbor thinks a flexi-prim bamboo forest is the bees knees.


The free market is winning out here (Otherland sims and similar, managed
estates do better than private estates with no building standards), but
it's slow going, and an initiative to document the best ways to build
beautifully and efficiently is probably in order.


Jason Giglio wrote:
> Qian Hao ~ wrote:
>   
>> Then my next question is, how does the server know what to send to
>> the client? The server execute a raytracing algorithm? So the client
>> is not the one requesting for object information?
>>     
>
> There's a subscription system, I believe controlled by both the client
> and the server.
>
> -Jason
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>