Revised 1/3/2019 – Hamlet has an interesting article Well-Optimized Alternatives To Resource-Heavy Mesh Bodies For SL touching on the contentious debate going in Second Life as to how much lag mesh bodies are causing. The high polygon count in mesh bodies is the suggested cause of the lag.
Tachinni – Bonnie Dress – @ACCESS Exclusive
We don’t have an obvious resolution to the argument. Nothing the non-techies can grasp. The techies stay out of the argument having learned one cannot argue with the ignorant as it is all opinion for the uneducated.
Recent technology changes have complicated the information on polygon counts and how they may affect your viewer’s performance. One complication is the shift from video card manufacturers bragging about polygons-per-second rendered to frames-per-second and now giga-rays-per-second… Part of the reason for changing metrics is the marketing hype card makers introduce to sell more cards.
Video cards use polygons to calculate what color to make a pixel on your screen. But, the usefulness of the value is questionable. You might zoom in and have only two polygons filling the screen or out and have a billion showing. That has a huge effect on your frames-per-second (FPS). So, frames-per-second is often more meaningful for our purposes in SL.
However, applying more computer power we can shift to ‘ray tracing’. The idea is we calculate the path a ray of light takes from a light source (lamp or sun type things) to an object in the scene then to your screen. In reality, the computation starts at the screen pixel and works back to the light source. It is just easier to think of the computer situation as like RL: light-source to things to screen.
Also, in the calc is light bouncing from objects to other objects and then to your screen. How many bounces do we want to consider? Available computer power and time determine how many.
As more image pixels (think 4k screens – UHD), more and more bounces, and more light sources are considered in the calculations the time for the calculation increases, but the result looks more and more like what we see in RL.
A gigaray is a billion rays of light calculation. A 1920×1080 screen image contains about 2 million pixels. So, a gigaray could have 480 rays contributing to each pixel’s color. If you think that is overkill, …well yeah.
The number of polygons the 10xx and 20xx cards can process is phenomenal. The ‘polygon’ number is hard to find these days because the industry has moved away from counting polygons. Other metrics are more representative and meaningful along with better for selling video cards. But, depending on who to and what one is talking about cards render 5 million to 2+ billion (not a home computer card) polygons per second. That means a scene that renders 60 frames per second can render 83,000 to 33,300,000 polygons for each frame.
There is no debate about whether polygons contribute to lower frame rates. The more polygons the longer the calc and lower the frame rate. The debate is about HOW MUCH of a slowdown is being incurred by mesh bodies. Is it polygons that are the problem?
Where is the Problem?
As animesh becomes popular we will be able to see whether it is the mesh or something else is the major factor lowering frame rates.
I can take my mesh body, all the parts – head, hands, feet, and stick it on an animesh frame and animate it. So, will 20 animesh avatars impact my viewer as much as 20 agent avatars? No. I suspect it won’t even be a close comparison. We have already seen tests with multiple animesh characters and we know it isn’t the mesh and animations that are the heavy a load.
The challenge is in the data communication. Avatars have to communicate what they are doing. For an agent avatar that requires a decent amount of information. The region simulator has to update all avatars present with the information as to what each avatar is doing. The data load expands exponentially.
Avatar DataNumber of Avatars ∼ Xy
An animesh avatar doesn’t care what other avatars are doing. It does not have to be told, updated. Animesh avatars cause a linear increase in the data load. They may be the same exact mesh as an avatar. But, they will cause only a fraction of the data load of agent avatars.
Animesh Data x Number of Animesh Objects
However, better-optimized anything in SL is a good thing. So, Hamlets pointing to well optimized and even some free well-made bodies is a good thing. But, how much reducing polygon count will improve Second Life’s performance is debatable.
The more significant reduction for better performance would be in reducing the amount of Avatar Data. Consider:
210 = 1024
410 = 1,048,576
These numbers should give you an idea of the effect of data load of 10 to 20 avatars in a region… Decreasing the amount of data by half with 10 avatars reduces the data by 1,048,576 ÷ 1024 = 1024 times…
The Lab is not trying to force designers to reduce their polygon count, well they are working toward incentives for that but that is a following project, ARCTan. The current big hope is Bakes On Mesh (BoM). Just as Server-Side Baking (SSB) reduced the texture data needed to render a Classic avatar so too it is hoped BoM will reduce the data needed for mesh avatars.