LL Blog: Avatar Rendering Cost

Script-based lag is the source of a lot of confusion and misconceptions. For the most part, scripts cause lag *in other scripts*, not slow frame rate. That is, unless the scripts are moving prims, they tend not to cause lag to other people (scanners being a notable exception).

Oh please, I think they need to change this tool so you can only see your own ARC score. Pointing fingers and threatening to burn the witch isn't a healthy environment.

Oh please, I think they need to change this tool so you can only see your own ARC score. Pointing fingers and threatening to burn the witch isn't a healthy environment.

It sure would be nice to have a magic red arrow pointing to the culprits whenever there is lag, but that's not likely to happen.

Reading the context of this quote, it was clearly *not* limited (nor especially targeted) to ARC numbers, but rather to isolating what in the whole system causes a user's experience of lag: could be scripts, could be physics, could be network--could even be avatar rendering costs. Pinpointing the culprit in that space *would* be useful for everybody.

And--you ain't gonna like this--it is pretty critical that we be able to see as much of that information as we can, to help figure out what's going on. And for a platform so dependent on user-generated content, SL really doesn't give us many clues about why, say, frame rate in a venue drops dramatically over a certain interval every day. Maybe after a month or two of sleuthing, the hostess with the 500-prim spiked boots will take a day off and somebody will make the connection.

It's fiendishly difficult, given the current tools, to isolate rendering lag. It would be selfish and short-sighted to ask for removal of a rare tool that can help others improve your in-world experience.

It also only points to character rendering... it doesn't address the prims and textures used in the sim. You can be the only person in a sim and have rendering lag due to the construction in the sim.

Exactly. That's the whole point. That's why the tool can be so useful for isolating what's due to avatars and what's not.

Yeah, it would be nice if it could be more accurate without itself lagging the measurement device. But any research is subject to the limits of instrumentation.

It causes lag in the client
It doesn't give consistent results

It is possible for someone in the green to actually lag out a sim or client if they wanted to.

The tool doesn't work, it just creates finger pointing.

If it had firm metrics that considered everything on the client's settings and told them how to adjust the graphics and tweak the client then it would be good.

But set up in such a manor that you can finger point, causes community issues with witch hunt style concerns.

And--you ain't gonna like this--it is pretty critical that we be able to see as much of that information as we can, to help figure out what's going on. And for a platform so dependent on user-generated content, SL really doesn't give us many clues about why, say, frame rate in a venue drops dramatically over a certain interval every day. Maybe after a month or two of sleuthing, the hostess with the 500-prim spiked boots will take a day off and somebody will make the connection.

it still is magic voodoo superstitions till the tool is refined enough to give fixed and consistent readings.

If you turn your camera and it changes, or they port out and port back in and sit on the same stool (same lighting and all other environmental conditions) and you get different readings... then the tool is not working right and should not be released for use till it is finished

Heck I'd rather see them shelve it for a bit and fix the core memory leaks that lag out people's machine first

And the finger-pointing was there all along--remember all the fuss about bling causing lag? Except--hah!--it mostly doesn't.

- A base avatar begins with a score of 1

- 5 points added for each unique texture on the avatar (not counting the base skin). Rationale: Unique textures break batches, create CPU overhead for decoding, and consume GPU memory bandwidth. However, note that this is across the avatar- so two unique textures across 10 prims only count as two unique textures!

- All attachments are then looked at on a per-prim level. The prims are weighted as follows:

- 10 base points for having the prim.

- 1 point added if prim is invisible, shiny, or glowing (each counts). Rationale: Invisiprims/shiny/glow create a small amount of overhead by breaking batches or requiring an extra render pass.

- 1 point added for each planar-mapped face of the prim. Rationale: Planar mapping creates a small amount of CPU overhead that gets worse with flexible objects.

- 1 point added per meter, per axis, of the prim’s size. Rationale: Bigger prims are higher LOD and create more fill.

- 4 points added if prim has bump applied. Rationale: Bump mapping breaks batches and requires a register combiner, and creates a lot of CPU overhead when coupled with a flexible object.

- 4 points added for each transparent face of the prim. Rationale: Alpha creates a lot of overhead by needing to be sorted every frame AND by breaking batches.

- 4 points added for each animated textured face of the prim. Rationale: Animated textures break batches and require the use of a texture matrix.


- 8 points added if prim is flexi. Rationale: Flexible objects create a lot of CPU overhead and consume graphics bus bandwidth.

- 16 points added if prim is a particle emitter. Rationale: Particles create even MORE CPU overhead and consume graphics bus bandwidth.

Hey Qie, check out the last paragraph here: doesn't that apply to bling?

it still is magic voodoo superstitions till the tool is refined enough to give fixed and consistent readings.

If you turn your camera and it changes, or they port out and port back in and sit on the same stool (same lighting and all other environmental conditions) and you get different readings... then the tool is not working right and should not be released for use till it is finished

I am not so sure why it is pretty "critical" that we see as much of that info as possible, as it seems it will only be comprehended and correctly interpreted by a small percentage of the people in SL, who will then have a limited way to respond to it anyway. Rather I think it is pretty critical that they come up with some kind of performance management controls within a group effort at their development of the hardware and software if they intend this to move on to greater things.

Maybe after a month or two of sleuthing, the hostess with the 500-prim spiked boots will take a day off and somebody will make the connection.

Bad example though . Prim count is irrelevant for ARC (*insert usual >1m disclaimer*).

Wearing 6,000 "twisted hollow cut tapered torus"' prims across all 30 attach points would earn you an ARC of:
1 (base) + 5 (texture) + 30 x 10 (attach points) = 306

I can't be bothered trying, but something tells me that wouldn't be "low lag" .

Modern software development processes emphasize not biting off more than you can chew. In other words, insisting that they only solve the complete problem is a sure way to plan a failed software project.

This is one more step towards the solution you want. It's only a step, so stop judging it because it doesn't solve everything. As this step proves, it's not easy to come up with something that could be used by that small percentage of people, so how do you expect them to come up with something that everyone could use? Or that solves the problem without human intervention?