|
Amethyst Rosencrans
Registered User
Join date: 24 Mar 2005
Posts: 87
|
10-15-2005 02:35
I did a build of a glass club (lots of transparency) next to a grove. I have two computers a Mac and a PC. On the PC I experience no lag, but many of my friends (most on PCs) complained of huge amounts of lag and refused to go there. But when I go there on the Mac I too experience the lag they are talking about. So I looked at the Ctrl-Shift-2 statistics and noticed it was spending lots of time in UpdateGeom. After searching the forums I found various posts mentioning this being related to redering toruses. So I spent all night walking around and noting where I am when the lag would occur. What I discovered is all the lag occurs in a strip east and west. Which basically amounts to when both the tree with the toruses and the transparent club are in a line within draw distance. (It's also useful to note that when things are at the edge of your draw distance they don't always seem to load immediately which may explain some of the seemingly randomness of the behavior) My supposition is that rendering toruses takes a lot more than other objects, and when they are in the same "line of sight" with transparent objects they get rendered multiple times causing the load to escalate to the point where the system can't keep up, and having multiple transparent objects on top of each other makes it that much worse. Rendering of the two by themselves seems to work fine but the combination is a disaster. If my observations are correct the moral of the story: Transparency and Toruses are a bad combination and should be avoided as much as possible! Referenced threads: /142/23/45941/1.html/111/ee/31063/1.html/111/f8/59854/1.html
|
|
Torley Linden
Enlightenment!
Join date: 15 Sep 2004
Posts: 16,530
|
10-15-2005 02:39
Well THANKS FOR STARTING THIS UP, AMETHYST! Yar... the problems still plague me time to time... although, as I've mentioned, I've had UpdateGeom lag when there were none of these geometries in my field of view. However, your post is a real refresher and I will be observing this closely again, the next time it happens... and the next... I wonder how 1.7 deals with it? Have you given it a spin in Preview? 
|
|
Amethyst Rosencrans
Registered User
Join date: 24 Mar 2005
Posts: 87
|
10-15-2005 03:00
Well I have noticed that the lag continues even if you leave the draw distance range for some time after (presumably until it has been removed from some sort of cache). But it starts as soon as you are in draw distance and the system loads the object. And it seems to be somewhat progressive so you might not notice immediately unless you are moving really slowly (like i was while testing).
I have not tested with 1.7, but this seems to be pretty low in the rendering system and it isn't likely to be fixed unless they optimize rendering of toruses or transparency (or both).
|
|
Torley Linden
Enlightenment!
Join date: 15 Sep 2004
Posts: 16,530
|
10-15-2005 03:19
I did some dirty experiments with stacks of 200 tori. I did notice additional slowdown when I alpha'ed half of them (50%) and orbited the camera around. Understandable. I used different Object Detail settings too. But unfortunately I didn't find anything that really made such a big difference between transparency vs. tori. What seems particularly striking to me is, true to the name UpdateGeom, whether the tori are translucent or not—when I zoom in and out and the rendered prims get literally redrawn on screen from the lower-detail ones to the higher ones. This paralyzes my system... there may be something inefficient in how it's done. In the past, I noticed UpdateGeom lag with little visual correlation. I could be standing in a skybox for a few minutes and then it'd come, and then cease, and then come again. So I'm not sure if that's related to what's happening here, but thanxies for sharing your experiences and I'll be looking out for it again. And furthermore, I wonder what causes this to happen on certain configurations? (This is a rather fitting post #6,666.)
|
|
Thili Playfair
Registered User
Join date: 18 Aug 2004
Posts: 2,417
|
10-15-2005 06:05
Toruses contain alot of surfaces then any other prims in SL (up with tube/ring), so having loads of them will croak a computer , even if its invis / vis its still rendered, they are not really optimized in SL i been waiting for that since it came. SL changed alot since their arrival, shapes you couldnt do with old without using tons of prims so i really like torus, however put loads of them in a cluster, zoom around and geometric render go ballistic, remember the first 100-300 prim torus hairs?. Something i noticed , the smaller torus in cluster harder it is to render them, why?, could be scaling them when you zoom in out, image what happen when you have someone wearing them and constant moving in and out of your screen, spike geo, down, spike geo ,down.  still love the shape , so much wierdness nice randomness you can do with it.
|