Lindens Runitai Linden Posted June 12, 2011 Lindens Share Posted June 12, 2011 There's been a lot of discussion lately about prim equivalence, so I thought I'd post some of the principles that have been guiding the implementation of the streaming cost metric. There's a lot of text here, but please read the whole thing before responding, as it starts off with some statements that seem bald face whacko without further explanation. First and foremost, the current implementation is far from final. This is evidenced by the fact that the number in the upload floater, the number in the streaming cost debug display, and the number in the build floater all disagree with one another. The last few months have been spent getting accounting code and asset formats into a place where we can fine tune the cost metrics. We've only just begun fine tuning the cost equations. To help, please build as much as you can. I can't stress this enough. The more content we have to examine and analyze, the better the final cost formula will serve us all. Second, meshes are not prims. They LoD differently, transmit differently, tend to be different sizes, etc. There is no analog between meshes and prims as far as triangle count or streaming cost. They are completely different types of content. The argument of "prim X has this many triangles so mesh Y should cost this many prims" has no merit. Don't even get me started on sculpts. The argument that some people will continue to use sculpts and prims instead of meshes specifically for an increase in triangle count at reduced prim cost, while completely true and valid, has no bearing on this discussion. Please read on and I'll explain why. So what does "Prim Equivalence" mean? Well, it means 1/15000th of a region's available resources. Abandon the idea that "Prim Equivalence" means an "equivalent complexity compared to a prim." It's an "equivalent parcel cost" compared to one prim. So what is the "Prim Equivalence" trying to accomplish? It's about budgeting. The task now is to define a realistic resource budget for an entire region and adjust the physics, simulation, and mesh cost equations so that a cost of "15000" equals this budget. Here, I'll talk about "streaming cost." "Streaming cost" more or less translates directly into a "visible triangle cost," given that the number of triangles visible from any given point on a sim is directly proportional to the number of bytes that need to be transferred. The goal of "streaming cost" is to limit the number of visible triangles to a realistic budget at default settings, and that budget is much smaller than you might think compared to overall scene budget. Here are some examples: Abbott's Aerodome: - 3.7 million triangles from prims - 500 thousand triangles visible from any given location Lusk: - 2.8 million triangles from prims - 218 thousand triangles visible from any given location Gibson: - 900 thousand triangles from prims - 150 thousand triangles visible from any given location Now, there are a lot of factors that play into performance other than triangle counts, but for the sake of simplicity, we're ignoring those for now. If you explore built out regions in Second Life, you'll find similar numbers (use the "scene statistics" console to check for yourself). The majority of built out regions seem to fall in the 200-400 thousand triangle range. While it's true that prims are a completely different content type than meshes, this "visible triangles" number gives us a realistic target for predictable performance. Given that Second Life has bad framerates and prims aren't exactly stingy about wasting triangles, it's wise to bias meshes towards the low end of that spectrum, say at 250 thousand triangles give or take 50 thousand. THAT is your visible triangle budget. In order for Second Life to have a prayer of running well in a mesh build, the meshes MUST display no more than that number of triangles per frame. So how does the streaming cost ensure that? To be blunt, it doesn't. No single metric can. Object sizes, placements, and camera position all have a great effect on how many triangles you might see for any given frame. The streaming cost merely provides an approximation for how much of this 15000 budget will be consumed by a single instance of the mesh in question. Put another way, it tries to ensure that if a region were filled to capacity with instances of the mesh in question distributed evenly at ground level, the number of visible triangles per frame would closely match the specified triangle budget. What this means in practice is that triangles added to the high LoD are very cheap, while triangles added to the low LoD are very expensive (except for large meshes where the high lod is displayed over a large area). This is because the low LoD tends to be displayed over a MUCH larger area than the high LoD, and thus this is the triangle count that will deduct from the 250 thousand triangle budget from most vantage points in the sim. So, be very aggressive about removing triangles from lower LoDs, build lots of stuff and focus discussion on concrete examples of mesh assets that are being penalized unfairly against the stated triangle budget, resist the temptation to compare meshes to sculpts and prims, and fret not that we're destroying mesh with high costs. Do this, and two weeks from now we should be in a much better place with respect to prim equivalence. 2 Link to comment Share on other sites More sharing options...
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now