10.5.07

Lag ist unser Feind: Prims vs. Texturen

Lislo Mensing: Lag ist unser Feind. Ob er sich nun in langen Ladezeiten oder niedrigen Frames per Second äußert. Bei einem so umfangreichen und dicht bebauten Projekt wie München SL ist er fast nicht zu vermeiden. Tests auf Momentum I haben nun ergeben, dass die wunderschönen und hochauflösenden Texturen, die wir bislang verwenden, leider zu viel Lag verursachen. Zudem sind sie zeitaufwendig zu produzieren.

Harald Nomad: Sounds like we need to investigate this a little further. With version 1.15 (and the downtime/fixes last Friday) performance has been better than in a long time. Besides the fact that over time things change so much in SL, where the cause of "lag" can have a large variety of causes, certain elements will always have an effect. One cause of "lag" in a region is the use of certain scripts. Does not apply to the Muenchen regions at this time. One more recently introduced cause of "lag" is the distribution of databases. This shows every time you're blocked on your path because a prim isn't shown. If retrieving and transmitting textures are an issue, it will show in a large percentage of grey (texture-less) prims. A problem that was introduced to SL between 6 and 12 months ago, is cache management of the client software. When your cache runs full, performance will go way down. Liaisons have been suggesting to clear your cache often, but that doesn't solve the problem, it just makes it go away for a while. I moved the SL cache folder to a newer, less used harddisk and have little problems since. (Okay, I also empty the cache folder manually often.) Defragmentation may result in a huge improvement of performance as well. I understand that SL version 1.14 or 1.15 introduced a problem with (some) laptops. My laptop is slower than my desktop, but other than that has less problems with SL than ever before (at least till next bug is introduced), so the problem must be specific to certain graphic cards or combination of elements. For a while now, SL downsizes textures at upload time. Older textures may or may not still be stored in higher resolution, but the maximum size of textures in Muenchen is 1024x1024. In combination with the low concentration of those textures within draw distance, this results in minimal impact on performance. Most tileable textures in SL are 512x512, meaning that using 3 or 4 of them instead would already have a larger impact. Compare a popular mall with many vendor boxes. Performance will go down with an increased number of avatars (number of clients linked to the region), and with an increased amount of server intensive scripts. On the other side, the items used in the region will be used (shown to client) more often and therefore become more 'popular' in terms of internal database distribution. A known 'lag' factor in Muenchen are the 256x256m prims. These are temporary and don't hurt too much at the moment. Whatever you experience as "lag" would be good to investigate. If it was as simple as textures or prims, it would have been more generic. Others not experiencing any form of lag is a good indication that problems could have other causes.

Lislo Mensing: Harald, you are right. I use the word "lag" pretty wide as a synonym for "bad performance". (Here four types of lag are discussed http://wastelands.wikidot.com/lag). And, yes, I use a notebook that (despite the fact that it was bought just 2 months ago) is at its limits when I am using it for Second Life. But maybe that's a good indicator for what to avoid. What I realized on Munich and on Momentum is that when i look in the direction of our lovely built and textured buildings the performance goes down from 40 fps to 3(!) fps. And no matter how long i wait it does not go away, before I turn around and look to the direction. I was able to reproduce the effect on Momentum I (without the giant prim on ground and sky). That makes walking the street of Munich a pain already in this early state. I assume that this "lag" is caused by the high number of high resolution textures we use. I am afraid that this will even get worse if we continue building and texturing in the way we do it today. I talked to Ham Rambler (DublinSL) and he said prims cause more lag than textures. Unless the textures are very big. I think he refers to the fact that when you walk through DublinSL these days many buildings in mid distance and far away take up to two minutes to res. They're not just gray or badly textured. They are just "not there". That is awkward as well - maybe more than blurred texture. Mental suggests that we change the way we build and texture our buildings a little bit. Not only to to get a more consistent look (Parbie's buildings are excellent but sometimes too realistic) but to reduce the number of unique high resolution textures. Mental, please explain what exactly is on your mind. Do it here so everyone can read and comment. Please keep in mind that we already agreed on many aspects. In particular on sizes and proportions. What we have to figure out now and fast is a way to reduce the "lag" by heavy graphics while not exceeding the current prim limits. In the meantime we should continue building. But that's another discussion thread.

Mental Raymaker: lag, lag, lag nag, nag, nag Here my five pence to the subject: As we all know there is not one kind of lag but several! Reducing the lag makes sense! We want a great user experience for Munich! But reducing the quality and making it boring, but fast makes no sense!

lag 1) loading time The smaller the textures and the more they are used in different places reduces the download time and time to rez! I hate waiting! Prims take almost no time to download! My guesstimate is 1k = several Prims! A texture in 1024 x 1024 as jp2 can have several 100k (at 80% about 300k this also depends on the actual picture a pure blue picture is probably just 1 k)! 512 x 512 should be a quarter in size but that is not really true as sl compresses 1024 x 1024 heavier then 512 x 512. I tested that myself! If there are about 200 buildings with lets say 3-4 unique detailed textures we get: 200 x 4 x 200k = 160000k = 160mb! Ok sl will only download the textures that are close to your avatar. But this is almost 1 mb per building! Even if you have a fast connection the server load is massive if 50 people are in Munich the server has to deliver 60 x lets say 15 buildings = 700mb! The key is priorities: Lets say you have a house with 16 windows a door and a shop window. The 16 windows can be a tiled texture reducing the size to 12.5 - 25 % without loosing anything! The door can be used on several (lets say 3-5 buildings!) again reducing the overall load by 66-80%)! One or several prims more will not increase the download time! The texture will already be in the cache! The house has some special features like the window or a sign! Cool make that a unique texture! So if you are looking at the street you will see nice houses with a little detail missing that you can examine when you get closer! I will look at every house together with Parbie and we will decide what makes this house special. Is it the structure we might use more prims. Is it a special sign or wall feature we will have a unique texture for that. But the windows and door might be the ones of a different building! Allways keeping in mind the experience of the user! We want details! We want diversity! We want hidden messages! We might sometime want readable signs! We dont need 200 x 16 = 3200 or more different windows so! We dont need loads of different wall textures! We need loads of different Shop Windows! And our stonemason has to produce nice details!

lag 2) local display issues If you have a 512mb graphicscard this is all no issue! Displaying 20000 prims with a total 200mb in textures is no problem at all! sl reduces the tessellation of prims the further you go away! But if you have a 128mb card half of that is taken by windows! And a jpeg of 1024 x 1024 is not compressed the same way any more and takes up much more space The card also has to process all the stuff! The more the smaller the framerate when you move! I would not call this lag it is perfomance... conclusion: Be clever! Reduce without loosing important artistic detail! Five prims more don't hurt especially if you are under the set prim limit for a building anyway! Either tile or use a lower resolution for generic stuff like windows. If there is a special Detail make a special Texture for the Detail. The house will display fast, the detail has the resolution it needs and we still save a lot of total pixesl! So signs and some stonemason work will need an extra prim and a extra texture... I have just talked about this with Parbie and have decided to build the ground floor one prim high. The rest of the house hight will be another prim. This way we can have medium 0.5 pxl per cm for the groud floor and sml 0.25 pxl per cm for the upper floors. If there is a detail in the upper floors like a special stonepicture or a gargoyle or so, that will get an extra prim in high resolution 1pxl per cm which is still a small texture as it is a small detail. The same goes for the ground floor if there is a special sign that needs to be high res for readability we use an extra prim for that and dont increase the resolution of the rest. We have talked about the buildings she had done and found out that we could save this way about 70% of texture size without loosing any artistic feeling or important details! Parbie is doing a house the way i discussed with her right now. Its No 311. Lets see how this will look!

Labels: , , , , ,

0 Kommentare:

Kommentar veröffentlichen

Abonnieren Kommentare zum Post [Atom]

<< Startseite