Linden Request: Updated Info: Impact of Shear,Hollow,etc.

Linden devs, could you please provide an update on the impact of the following in terms of lag? An order of precedence would be cool. Reason I'm asking is that I'm not noticing lag as I have in the past from, for example, a hollowed and cut sphere. Would be nice with the new prim limits to be able to use these more liberally to add interest to builds without fear of the lag monster.

- Shear
- Twist
- Hollow
- Cut
- Top Size

- Is the impact greater on objects that are rounded such as spheres?

- Are torii still instruments of the devil?

- Also, should rotation be avoided? or does it have no impact? i.e., it's easier to copy and rotate, but does this make the system 'work harder' in a perceptible manner?

Thanks!
Candie

I'm not Linden-esque in any way, shape, or form, but I'm pretty sure about how to answer this.

Network lag is unaffected by any of these. All prims are sent over the network as a packed and compressed handful of numbers. The same numbers you see in the edit window. The slowdowns are on our computers and in our video cards where those numbers are turned into a slew of 3d points and the triangles they form to make surfaces. The more triangles it takes to make the prim, the slower it will make your framerate.

For example, one face of a cube takes two triangles. With six faces, that's only 12 triangles for the whole thing. While a sphere takes many triangles to simulte a curved surface. But there is a "level of detail" (LOD) system that uses fewer triangles when an object is small on the screen, since if it isn't smoothly curved when it's small it's hard to tell because it's... small.

Shear and top size have no effect on the number of triangles, they just move and resize them. Hollow will add more triangles, more than doubling the number. Twist can add even more triangles. Cuts both add and remove triangles, so a small cut might total up to more than no cut at all, and a large cut may make it less than normal.

So the worst shape you can make is a torus, hollowed, twisted, and slightly cut. A lot of these, large on the screen, will drop your framerate low. Spreading them out so that they aren't all large on the screen will help, because LOD will take away some of the triangles you can't see.

Oh, and if any part of a triangle is visible, then the whole thing is rendered, even if it is behind other objects. If it is completely hidden, it is "culled" or removed from the scene for that frame to make the rendering faster.

I hope that helps.

Oh, and Havok physics uses the triangles to detect collisions, so the more triangles in a physical object, the more work the SERVER has to do to move it around.

Great info Tiger =D

Is LOD done in the CPU or GPU these days?

I suspect it's probably still a CPU-task... =/

i think *most* of the old style lag was the physics engine.. and its not that it HAS to work on triangles... exactly... the idea of a sphere is that the physics engine can react to the sphere as a single 'point' with a radius rather than as a collective series of triangles.

thats why cut or hollow spheres were so lag inducing... the physics engine couldn't use 'sphere' shortcuts and then did have to fall back on per triangle calculations...

im not sure what the status of the game would be in regards to that though.. i suppose you could do some testing on things but unmodified prims will *ALWAYS* be faster running than geometrically modified ones... thats why they're prims, the physics engine can deal with them in a shortcutted sort of way, until you make them more complex by adding/removing various cuts and hollows etc

on the same note, for video rendering... making complex prims transparent is VERY VERY video intensive.... a single semi-transparent curved window can drop framerate noticably if its large /complex enough, and unfortunately i see them being used all too often, by people who then complain how slow SL runs, without realizin they're really addin to that problem :/

That would be a CPU thing. It's too specific to the task at hand for the render hardware to to do it automatically.

"Lag" is a general term that can refer to several distinct forms. However, in an attempt to answer the question in the face of ambiguity:

Collisions with concave shapes can increase the work that the physics engine needs to do. When the physics engine starts to work hard then the whole physics engine will slow down, causing objects to fall and move slowly.

So, walking your avatar inside a big hollow box is actually more expensive for the physics engine than walking it inside a box made of several boxes scaled to be walls. However the effect is slight, and would probably only be even measurable if you were to compare 20 or 30 avatars bouncing around in the two different houses. Also, this discrepancy will essentially vanish when we move to Havok-2.

Just because the object looks concave doesn't necessarily mean it is concave to the physics engine. Sufficiently small concave objects are replaced with convex proxies, which reduces "deep thinks" and helps save the physics engine for collisions that don't necessarily "need" concavity. We'll be able to get much smarter about this when we start using Havok-2.

Concave shapes tend to use more triangles than their convex counterparts, which, in theory, affects render FPS. That is, a pile of hollow, cut, torii will render slower than an equal number of cubes. However, this will only be noticable if the GPU and the triangle count are your bottleneck. Usually the bottleneck will be something else, like texture fill-rate, the available RAM, or the CPU itself.

Transparent objects in view definitely slow down the render FPS.

Rotating objects does not have a measurable effect on the system. The identity rotation is equivalent (for computation purposes) to all non-trivial rotations.

Render LOD stuff is done on the CPU to spare the GPU.

Reducing the number of distinct textures in view can help increase FPS, and will also reduce the amount of data that must be streamed to the user when they first arrive. Excessive network traffic can contribute to "lag" on both the server and the client. This is a technique used to great advantage in most commercial games with carefully created levels (to speed up render rates and reduce load times).

Which would cause less lag, one large 512x512 texture or 16 smaller 128x128 textures whose area equals that of the larger texture? Does it make a difference? Lets assume we're talking about 16 prims all with the same 512x512 texture on them versus 16 prims each with their own 128x128 texture.

Not sure how the rendering works in SL.. I am familair with raytracing, scanline and triangle filling.

I had assumed that SL rendered polygons from teh farthest to the closest, and if you stood behind a wall you are still being rendered, but the wall gets rendered later to cover you up.

If SL is doing true triangle occlusion than a nice checkbox to have would be one marked INVISIBLE that would stop it from showing at all. be good for windows and other things that need to be there, but do not ned to be seen.

Like.. my HEAD! Damnit.

Thank you, Andrew

Candie