[sldev] Improving rendering sequence

John Hurliman jhurliman at wsu.edu
Mon Jan 7 12:02:27 PST 2008


Dave Parks wrote:
> 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.
>   

I'm working on a UV mapping program for prims
(http://wiki.secondlife.com/wiki/Prim_Mapper)
(http://www.jhurliman.org/images/primpreview-04.png) that should make it
easier for content creators to map full linksets to a single texture as
well as do texture editing in Maya, Deep Paint 3D, etc. In theory, a
linkset that has no alpha and all shares the same texture should be
processed in a single batch correct?

John


More information about the SLDev mailing list