[sldev] Improving rendering sequence

[Qian Hao ~]

Hi,
 
Just a question.
"since the interest list is based solely on size vs. distance for sending prims, occluders are often not sent first"
 
The sieze mentioned in the above statment is file size? Or is it the
size of the object or is it the size that prim occupy on the screen?
 
Thanks,
Qian Hao> Date: Mon, 7 Jan 2008 09:30:46 -0800> From: davep at lindenlab.com> To: gigstaggart at gmail.com> CC: ts_ryuzo at hotmail.com; sldev at lists.secondlife.com> Subject: Re: [sldev] Improving rendering sequence> > 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> > > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080126/2169c2c9/attachment-0001.htm