• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Mysterioeser LAG

@ angelika

Das ist schwer zu sagen, du musst die Top-Script Liste ueber einen laengeren Zeitraum beobachten (5 - 10 Minuten immer wieder aktuallisieren).
Saemtliche Scripte haben kurz nach dem rezzen oder starten immer erst einmal hohe werte und pendeln sich dann erst ein.
Bei gerezzten Objecten kommt es drauf an was die Scripte machen, wenn nun ein Object angezeigt wird das mehr als 0.200ms hat, wuerde ich auf jeden Fall mal nachsehen was das ist und was es macht. Dann kommt es drauf an, wie viele Scripte darin enthalten sind. Bei einem Wert von 0.200ms wuerde ich drauf tippen das entweder 100 Scripte drin sind, oder wenns nur wenige sind, das die sehr viel machen oder gar scheisse gescriptet sind.
Manchmal kann es sogar sein, das ein Script abgestuerzt ist und ein Resetten reicht, damit es wieder normal laeuft. Aber 20.0ms fuer die ganze Sim dauerhaft ist jedenfalls nicht gut und ich wuerde mal einen Region-Neustart empfehlen.

Nachtrag:
Die TopScript-Liste kann dir nur anhaltspunkte geben, aber keine konkrete Aussage ueber die Scritpe.
Je nachdem wie die Sim belastet ist, sei es durch viele Avatare oder viele physische rollende Prims ohne Scripte, beeinflusst das die Topscript-Liste ebenfalls. Die Liste sagt ja nur aus, wie viel Zeit der CPU in dieser Secunde unter der aktuellen Belastung fuer dieses und jenes Script benoetigt, wenn der CPU nun aber schon mit der Physic oder anderem Kram wie einen Teleport oder was weiss ich nicht beschaeftigt ist, beeinflusst das die Anzeige in der Liste.

LG
Dae
 
Zuletzt bearbeitet:
Vielen Dank Dae, das hilft mir schon weiter. Ich muss mal mit der Mieterin sprechen weil sie in ihrer Sky einen Orb hat und ich es mir derzeit nicht in Ruhe anschauen kann. Das eine Teil mit permanent(also bei jeder Aktualisierung) mit über 0,2 ist irgendein bunter Baum. Bei dem anderen Script welches bei jeder Aktualisierung zwischen 0,2 und über 0,8 wechselt ist es ein "Toddler car pink By Snuggle Baby". Was immer das auch ist.
 
...das es halt an meinem popels Notebook liegt und an der Teledumm..denn Vormittags gehts meist ...Abends wenn die Familie auch on will hat Obsi ein *ich ruckel mal so rum Problem*

Schlappes Notebook (jeder schlappe PC) macht schnell Grafik lag. Sieht man auch am Statistik Fenster ganz oben die FPS. Dann bewegt man sich zwar wie im Daumenkino, hat aber weniger Probleme mit der Bewegung. Netzwerklag macht dann eher schonmal, dass man zu weit läuft, auf der Stelle rennt und das umziehen zur Qual wird. Im Statistik Fenster kann man das sehen, dass die Ping Sim hochgeht (über 300ms fängts an) und das Paketloss hoch geht. Und klar, wer nur eine geringe Bandbreite hat und mehr Leute die nutzen wollen, wird es schnell eng für SL. Bei einigen Routern kann man aber auch die zugewiesene Bandbreite einstellen. Und nochwas, je mehr FPS der PC schafft, destomehr upload Bandbreite wird gebraucht. Ich selbst habe das Problem, ich schaffe so 30 FPS im Schnitt, und merke, dass der Upload bei mehr dann schon dicht ist und mein Voice anfängt zu spinnen.
 
Kleiner Tipp für Hintergrundprogramme.

Skype und alle möglichen Clouds wie beispielsweise Dropbox reservieren sich scheinbar Resourcen und Bandbreite die dann dem Sl Viewer nicht zur Verfügung stehen.
 
Scripte an sich machen in SL seit über einem Jahr nun normalerweise keinen Lag mehr, was daran liegt, dass die Scripte auf dem Server nur dann ausgeführt werden, wenn dieser noch in vertretbarem Rahmen Zeit dafür über hat. Braucht der Server viel Rechenzeit für die Scripts und sinkt die Framerate des Server dadurch zu stark (unter 35FPS bis 40 FPS - normalerweise läuft der Server mit 45FPS), dann wird die Ausführung von Scripts verzögert oder ganz angehalten. Bis die Framerates wieder hoch genug sind. Was aber selten vor kommt, da SL auf dem Server nun virtualisiert läuft. So dass sich eben meist 8 Sims die Rechenleistung von 8 CPUs teilen. Und wenn ein Sim keine Leistung braucht, dann kann die von anderen Sims genutzt werden. Das geht sogar so weit, dass Sims, in denen nicht los ist auf eine Art "Standby" gehen. So dass mehr Rechenleistung für die anderen über ist.

Ebenso spielt die Anzahl der Scripts keine Rolle, auch nicht hinsichtlich des Speichers: Zum einen gibt es diese alte Limitation auf "300MB für alle Scripts pro Sim" (= 19200 LSO Scripts bzw. mindestens 4800 Mono Scripts) nicht mehr wirklich. Das läuft nun über virtuelle Maschinen, d.h. da teilen sich 8 Sims eben mind. 8GB RAM. Braucht z.B. ein Sim nur 600MB RAM, dann kann ein anderer die übrigen 400MB mitnutzen.
Dazu kommt noch, dass zwar die alten LSO-Scripts immer 16kB Speicher brauchen - die neuen Mono Scripts brauchen aber nur jeweils den Speicher, den sie auch wirklich belegen, das kann irgendwas sein zwischen 5kB (minimale Größe bei Mono) und 64kB. Zudem kann Mono Bytecode-Sharing. D.h. bei vielen identischen Kopien von Scripts auf einem Sim werden Teile des Mono-Bytecodes nur einmal geladen, und auf das greifen dann auch die anderen Scripts zu. Deswegen kann es gut sein, dass ein Objekt mit z.B. 100 Scripten eben nicht die per "Script-Anzeiger" angezeigten 100 x 64kB = 6,25MB belegen. Es kann gut sein, dass da auf dem Server wirklich nur z.B. 15kB + 99 * 7kB = 708kB belegt sind.

Leider gibts keine echte Möglichkeit die Scriptbelastung auf dem Server wirklich genau zu analysieren. Näherungsweise kann man (wenn man die Rechte hat) das Top-Menu nutzen. Das zeigt mittlerweile zum Glück nicht mehr einen "Momentanzustand" an, sondern die durchschnittliche Scriptlast der letzten 30 Minuten. (Bzw. wenn ein Script länger auf dem Sim war die mittlere Last über der Zeit, in der es auf dem Sim ist.)
Das ist zwar schon wesentlich besser als die alte "Schnappschussmethode" - aber irgendwelche kurzen Spitzenlasten kriegt man damit halt nicht raus. D.h. wenn ein Script für 29min 30s einfach nichts gemacht hat - aber dann 30s lang Terror macht, dann fällt das nun auch nicht wirklich auf.

[ANM: Deswegen kann man hier nur an die Scripter appellieren bitte genau zu überlegen was man da tut, warum man das tut und wie man das dann tut. Und BITTE nicht einfach irgendwelche Scriptteile verwenden, wenn man nicht wirklich weiß und verstanden hat, was da genau passiert, etwa aus irgendwelchen Beispiel-Sammlungen. Man kann nämlich mit einem entsprechend mies geschriebenen Script leider immer noch einen Sim ausbremsen... bis zum Reboot, wenn es sein muss.]


Was die Netzwerk-Probleme angeht:SL braucht mittlerweile massiv Bandbreite! Und mit massiv meine ich wirklich viel.

Früher, vor 6 Jahren gings mit ein paar Abstrichen sogar noch mit ISDN, mit 128 kbits. Es hat gedauert bis alles geladen war - aber es ging.
Heute reicht das dank Meshes und dank Server Side Baking bei weitem nicht mehr - selbst mit UMTS oder DSL-Light (384kBits) ist SL nicht mehr benutzbar. (Bzw. mit DSL-Light nur dann, wenn man massiv am Viewer eingreift und vieeel Geduld hat). Und selbst 1 Mbit oder 2 Mbit sind eigentlich noch viel zu wenig. Das Problem ist, dass SL nun alles per http überträgt (was nicht wirklich gedrosselt werden kann und die Leitungen schnell mal verstopft) - und dass vor allem ziemlich viele Daten übertragen werden müssen. D.h. wer in einen Club kommt, in dem z.B. 20 Avas tanzend zappeln, der muss damit rechnen, dass jetzt nicht nur die 100 Texturen der Avas per http übertragen werden müssen, zusätzlich müssen auch grob geschätzt 2000 bis 4000 weitere Texturen übertragen werden (je nach Club), was für sich gesehen in so einem Club schon mal locker 20M bis 50MB Daten für Texturen ausmacht. Texturen sind eben irgendwo jeweils zwischen 2kB und 512kB groß pro Stück beim Laden. Dazu kommen aber dann noch die Mesh-Daten. Und Meshes können leider auch recht groß werden. D.h. pro Mesh sind 3MB bis 5MB durchaus möglich, auch wenn es natürlich viele kleinere Gibt. So dass am Ende eben locker erst mal 100MB bis 200MB an Daten übers Netz müssen, bis alles dargestellt werden kann. Ist zudem noch viel Los mit Gesten + Sounds + Animationen, dann muss das auch alles noch durchs Netz. Und kommen und gehen immer wieder Leute, dann wird da ständig neues geladen. So dass man durchaus mal 250MB bis 500MB aus dem Netz laden muss, bis alles "da" ist.
(Jup - "SL Mobil" ist wirklich ein Problem damit. Viele haben nicht mal die 500MB bis die Drossel kommt...)

Und solange das nicht alles geladen ist, ist die Netzwerkverbindung eben voll ausgelastet.
Bei einer 16 Mbit Anbindung ist das kein Ding: Selbst 400MB bis 500MB (voller Club, viele Texturen durch viele Vendoren, ständig kommen Leute etc.) brauchen eben mal wenige Minuten. Selbst volle Clubs sind in 3 bis 4 Minuten geladen. Danach lädt der Viewer kaum noch was aus dem Netz (um die 5kByte/s). Und auch der Upload wird kaum benötigt (auch um die 5 kByte/s). Man hat das Netz also recht schnell wieder frei. Mit einer 2 MBit Anbindung dauert das leider ein bisschen länger. Da man oft nur 2000 kiBits = 250 KByte/s hat dauert es eben locker mal weit über 20 Minuten, bis so ein voller Club geladen ist. Hat man gar nur DSL-Llight, dann dauert das möglicherweise bis zu einer Stunde. (Weil dann ja noch andere Probleme wie Timeouts usw. auftreten, so dass man effektiv noch mal länger warten muss.) Und in der Zeit ist die eigene Internetverbindung zu 100% ausgelastet.
Das bedeutet auch, dass man sich zwar schon bewegen kann - aber eben leider nur mit massiven Verzögerungen.

Abhilfe gibt es leider keine. Alles, was da hilft ist vieel Geduld, wer DSL-Light hat kann (eher: muss) bisschen am Viewer schrauben (und Mesh-Downloads limitieren, udp-Texturen mit niedriger Download-Rate nutzen usw.)
Oder schnelleres Internet nutzen.

Wer sehen will, wie viel Bandbreite man so belegt:
Windows 7 hat z.B. im Taskmanager unter dem Tab "Leistung" Zugang zum Ressourcenmonitor. Damit kann man sich Details über den Traffic anzeigen lassen. Z.B. was der Firestorm oder LL Viewer und SLPlugin so übers Netz schaufelt. Allerdings muss man da bisschen raten manchmal.

Einfacher ist es, wenn man Zugriff auf den Router hat. Viele bessere Router zeigen da direkt die Netzwerkauslastung an im Verwaltungsmenu.
Und richtig komfortabel gehts mit einer Fritzbox: Da gibts z.B. das Tool hier: http://www.bawe.eu/cms/Projekte/Fritz!Box Traffic.html
Das ist ein Win7-Gadget, das direkt den aktuellen Internet-Traffic auf der Fritzbox anzeigt. Dazu muss man nur auf der Fritzbox einstellen (unter Heimnetz/Netzwerkeinstellungen z.B.), dass UpnP-Statusinformationen (Netzwerkstatus) ausgelesen werden dürfen. (Ist kein Sicherheitsproblem, da nur aus dem Heimnetz erreichbar und die Box so nur ausgelesen werden kann).

Wenn man da sieht, dass das Netz zu 100% ausgelastet ist, dann braucht man sich auch über Lag oder graue Avas oder nicht geladene Texturen nicht wundern.




TL;DR?
a)Scripts machen keinen lag mehr.
b) SL braucht viele Daten aus dem Netz. Wenn das Netz voll ausgelastet ist hat man dadurch lag.
 
Ergaenzend zu Shirleys Beitrag moechte ich noch erwaehnen, das es Dienstags und Mittwochs waerend der Rolling Restards nicht ungewoehnlich ist, dass beispielsweise Texturen schlecht oder gar nicht geladen werden. Das liegt schlicht und ergreifend daran, das die Asset Server hoffnungslos Ausgelastet sind. Im Klartext bedeutet das, das die User daran schuld sind. Auf Grund dessen das die Lindens ueber mehrere Stunden mehrere Regionen abschalten um Updates aufzuspielen teleportieren ungewoehnlich viele Avatare ueber das Grid um bei einem Restart nicht ausgeloggt zu werden. Dadurch beansprucht jeder teleportierende Avatar automatisch ein erhoehtes Volumen an Bandbreite indem er augenblicklich massenhaft Anfragen an den Asset Server stellt, um die Ziel-Region in den Cache zu laden.

Wenn es nur ein Avatar waere, ginge es ja noch, aber bei den Restarts fluechten tausende auf andere Regionen. Meistens nicht nur einmal, sondern mehrmals, wenn kurz nach dem Teleport eine Meldung im Chat erscheint, das diese Region ebenfalls neugestartet wird. Das sind dann solche Tage, wo Avatare Grau oder Woelkchen bleiben, Texturen Grau oder unscharf bleiben, NCs und Scripte nicht geoeffnet und/oder gespeichert werden koennen und so weiter.

Dadurch das nun ungewoehnlich viele Avatare ploetzlich erheblich mehr Datenvolumen anfordern und Intern mehr Bandbreite im Second Life Netzwerk beanspruchen, kann es auch unabhaengig von der eigenen Bandbreite (meined wegen 50000er DSL) zu verzoegerungen auf den anderen Regionen kommen, was sich dann so bemerkbar macht, das man gegebenenfalls nicht rezzen kann. Aus diesem Grund machten die Lindens regelmaessig entsprechende Warnungen, das man keine no copy Items rezzen soll, eben weil sie unter umstaenden im Nirvana verschwinden koennen.

Von daher kann ich jedem nur ans Herz legen, regelmaessig einen Blick in den Grid-Status zu werfen: http://status.secondlifegrid.net/
Alternativ kann man auch hier im Forum auf die Meldungen des Swapps-Bot achten, die betreffen meistens ebenfalls den Grid-Status.

LG
Dae
 
Scripte an sich machen in SL seit über einem Jahr nun normalerweise keinen Lag mehr, was daran liegt, dass die Scripte auf dem Server nur dann ausgeführt werden, wenn dieser noch in vertretbarem Rahmen Zeit dafür über hat. Braucht der Server viel Rechenzeit für die Scripts und sinkt die Framerate des Server dadurch zu stark (unter 35FPS bis 40 FPS - normalerweise läuft der Server mit 45FPS), dann wird die Ausführung von Scripts verzögert oder ganz angehalten.

Was im allgemeinen ebenfalls als LAG empfunden wird, wenn beispielsweise ein Dialog-Menue erst 5 - 10 secunden spaeter erscheint.

LG
Dae
 
Vielen Dank Dae, das hilft mir schon weiter. Ich muss mal mit der Mieterin sprechen weil sie in ihrer Sky einen Orb hat und ich es mir derzeit nicht in Ruhe anschauen kann. Das eine Teil mit permanent(also bei jeder Aktualisierung) mit über 0,2 ist irgendein bunter Baum. Bei dem anderen Script welches bei jeder Aktualisierung zwischen 0,2 und über 0,8 wechselt ist es ein "Toddler car pink By Snuggle Baby". Was immer das auch ist.

Ich habe noch mal ueber dein Beispiel nachgedacht.
Das eine Object (bunter Baum) was permanent 0.200ms anzeigt ist gegebenenfalls total Harmlos, vielleicht tun die Scripte ueberhaupt nichts und sind einfach nur da und warten auf interaktion, aehnlich wie alte Resize Scripte in Haaren mit 1 Script pro Prim.
Verdaechtiger ist das Object (Toddler car pink By Snuggle Baby), welches permanent zwischen 0.200ms und 0.800ms hin und her pendelt, bei dem ist es eindeutig, das es irgend etwas aufwendiges in einem Timer macht und gegebenenfalls die Region belastet. Ich weiss nicht was im Script steht, aber die ein oder anderen Befehle sind nach wie vor dazu in der Lage die Performance einer ganzen Region in den Keller zu reissen.

LG
Dae
 
(...)
Verdaechtiger ist das Object (Toddler car pink By Snuggle Baby), welches permanent zwischen 0.200ms und 0.800ms hin und her pendelt, bei dem ist es eindeutig, das es irgend etwas aufwendiges in einem Timer macht und gegebenenfalls die Region belastet. Ich weiss nicht was im Script steht, aber die ein oder anderen Befehle sind nach wie vor dazu in der Lage die Performance einer ganzen Region in den Keller zu reissen.

LG
Dae

Jup, leere Timer alleine machen noch keinen Lag. Und timer an sich sind auch unproblematisch und führen höchstens zu Script-Lag, bei dem Scripts halt nicht weiter ausgeführt werden. Aber das Wesentliche ist das, was du im zweiten Satz ansprichst: Das, was in den Scripts passiert.

Ohne zu sehr auf die Details einzugehen (aus mehreren Gründen..), aber im Byte-Code der Scripts wird hin und wieder eine "STOP" Marke eingebaut beim "Speichern" (also Kompilieren auf dem Server nach beim "Speichern".). An diesen Stellen kann ein Script einfach angehalten und auf dem Server auch in ein "Datenpaket" gespeichert werden. Um z.B. auf einen anderen Sim transportiert zu werden beim TP.
Man kann an diesen Stellen auch einfach das Script anhalten um z.B. die weitere Ausführung so lange auszusetzen, bis eben wieder Rechenzeit auf dem Server frei ist. Das Problem ist nur, dass manche "Konstrukte" im Scriptcode eben dazu führen, dass z.B. in einem loop (for, if, while...) eben viel Rechenzeit verbraten wird ohne dass es dazwischen einen STOP Code gibt. So dass durch den Loop/die Loops eben die Script-Engine übermäßig viel Zeit auf der CPU belegt.

Das Problem sind dann z.B. einfach Leute, die nicht bedenken, dass mehrfach verschachtelte Loops unter Umständen zu verdammt vielen Operationen führen können. Auch wenn man dann Beispielsweise "nur" jeweils wenige Iterationen in den einzelnen for Loops hat. Wenn man 3 ineinander verschachtelte for-Loops mit je 16 Iterationen in jedem Loop hat, dann hat man z.B. schon über 4000 Aufrufe.

Code:
//don't do that without reason!
integer i;

for(i=0;i<16;i++){
    for(i=0;i<16;i++){
        for(i=0;i<16;i++){
            llSay(0,"Hello!");
        }
    }
}

Genau so etwas sollte man eben nicht ohne guten Grund machen, auch wenn das ein Rechner schnell machen kann. Trotzdem gibts durchaus vor allem ältere Freebie-Scripts, die sich um Optimierungen und derartiges offensichtlich keine Sorgen machen.
Und halt leider dann auch Leute, die nicht überlegen was ihre Scripts genau machen. Meist weil sie es nicht besser wissen und weil sie z.B. gern mal irgendwelche fremden Teile zusammenkloppen.
(Also lieber richtig Scripten lernen statt nur Templates benutzten. Die Beispiele in den LSL Wikis sind aber Prima um Scripten zu lernen - einfach überlegen was die genau machen!).

Das Selbe gilt allerdings wohl auch für einige Leute, die z.B. Turnschuhe durchgehend mit vielen 1024-er Texturen zuknallen, damit die ja auch gut aussehen, wenn man die aus nächster Nähe begutachtet. Dass ihre 20 Texturen eben mal bis zu 60MB Grafikspeicher auf der Grafik-Karte belegen (nur für die Turnschuhe...) ist denen meist nicht mal bewusst. Ebenso wie manche User keinerlei Skrupel (oder eher Mangelnde Kenntnisse.. ) haben und Meshes mit zig tausenden Dreiecken hochladen, obwohl man das auch einfach mit einem Bruchteil in der selben Qualiät hätte machen können.

Gesunder Menschenverstand kann natürlich leider nicht immer vorausgesetzt werden. Aber bisschen Schlau machen und Grundlagen lernen vor dem professionellen Content erstellen schon.
(Ich hätte echt kein Problem damit, wenn LL irgenwann einen diesbezüglichen Upload-Test einführen würde... ähnlich wie beim Intellectual Property Test...)
 
Zuletzt bearbeitet:
Zur Erklärung was für ein teil das sehr wahrscheinlich ist. Toddler sind Kinder Avatare oft ganz Mesh oder zumindest Teilweise. Das Car ist wahrscheinlich eines der vielen Autos die es gibt, oder ein Kinderwagen. Snuggle Baby ist einer der vielen Shops für Kinderzubehör
 
Zuletzt bearbeitet:
LOD (level of Detail)

huhu,

ich habe so eben im GruppenChat vom Deutscher Info-Dienst folgende Aussagen mitgelesen.
  1. du musst den Lodfaktor hörer stellen
  2. der ist auf 4
Darauf hin habe ich mal nach etwas sehr interessantem gesucht und gefunden: http://www.cosy.sbg.ac.at/~held/teaching/bakk_seminar/se_arbeiten_07-08/LoD.pdf

Um es mal auf den Punkt zu bringen, dieser dubiose Ratschlag, man solle in SL den LOD Faktor erhoehen ist das absolute Gegenteil zum Thema Lag-Vermeidung. Die Erhoehung des LOD's ist in meinen Augen ausschliesslich denen vorbehalten, die ueber eine High-End Grafikkarte und einer sehr sehr schnellen Internetverbindung mit hoher Bandbreite ohne Traffikbegrenzung verfuegen. Alle anderen die hier und da mal ueber verzoegerungen klagen, sollten den LOD Wert grundsaetzlich unter 3.000 einstellen, wobei das schon sehr hoch ist, wenn man bedenkt, das der Standard-Wert im Linden Viewer 1.250 ist.
Der Regler "Objekte" in den Grafik-Einstellungen des Viewers regelt genau diesen Wert, der normalerweise 2.000 (im Cool bis 3.000) erreicht, wenn man ihn bis zum Anschlag aufdreht.

Sinn und Zweck des LOD
Grundsaetzlich werden alle Details, auch wenn sie fuers blosse Auge nicht erkennbar sind berechnet.
Der eigentliche Sinn, welcher auch in der PDF nachgelesen werden kann ist, die Rechenleistung des betrachtenden PC's zu steigern.
Damit kein LAG entsteht werden die Deteils weiter entfernter Objekte automatisch reduziert um moeglichs wenig Datenstrom ueber die Internet-Leitung und durch die Grafikkarte zu schleusen.

Wenn nun ein Objekt frueher als erwartet zerfaellt, liegt es nicht am Viewer oder an den System-Vorgaben des Servers, sondern schlicht und ergreifend am eigentlichen Objekt selber. Das bedeutet das es kein optimales Mesh-Objekt ist. Entweder der Ersteller hat zu wenig LOD vorgegeben um Uploadkosten und/oder Land Impakt (primcount) zu sparen, oder einfach keine Ahnung von dem was er da tut. Jedenfalls sollte man sich in diesem Fall nach Alternativen umsehen und das Mesh entsorgen.

Um noch mal auf den LOD des Viewers zurueck zu kommen.
Wer den LOD des Viewers erhoeht, setzt damit die automatische Berechnung der Level of Detail ausser kraft und laed dadurch saemtliche verfuegbaren Daten der Szene auf seinen Rechner in die Grafikkarte. Sollte nun die Bandbreite der Internet-Verbindung nicht ganz so dolle sein, werden gegebenenfalls sogar Objekte nicht dargestellt, die man direkt vor der Nase hat, eben weil die Daten dafuer noch gar nicht auf dem Rechner sind. Wenn jetzt noch ein Time-Out eintritt und der Viewer dieses Objekt einfach verwirft, wird man es auch nach 30 Minuten nicht sehen.

Kurz gesagt: Erhoehter LOD gepaart mit hoher Sichtweite = LAG

LG
Dae
 
Zuletzt bearbeitet:
huhu,

ich habe so eben im GruppenChat vom Deutscher Info-Dienst folgende Aussagen mitgelesen.
  1. du musst den Lodfaktor hörer stellen
  2. der ist auf 4
Darauf hin habe ich mal nach etwas sehr interessantem gesucht und gefunden: http://www.cosy.sbg.ac.at/~held/teaching/bakk_seminar/se_arbeiten_07-08/LoD.pdf

Um es mal auf den Punkt zu bringen, dieser dubiose Ratschlag, man solle in SL den LOD Faktor erhoehen ist das absolute Gegenteil zum Thema Lag-Vermeidung. Die Erhoehung des LOD's ist in meinen Augen ausschliesslich denen vorbehalten, die ueber eine High-End Grafikkarte und einer sehr sehr schnellen Internetverbindung mit hoher Bandbreite ohne Traffikbegrenzung verfuegen. Alle anderen die hier und da mal ueber verzoegerungen klagen, sollten den LOD Wert grundsaetzlich unter 3.000 einstellen, wobei das schon sehr hoch ist, wenn man bedenkt, das der Standard-Wert im Linden Viewer 1.250 ist.
Der Regler "Objekte" in den Grafik-Einstellungen des Viewers regelt genau diesen Wert, der normalerweise 2.000 (im Cool bis 3.000) erreicht, wenn man ihn bis zum Anschlag aufdreht.

Sinn und Zweck des LOD
Grundsaetzlich werden alle Details, auch wenn sie fuers blosse Auge nicht erkennbar sind berechnet.
Der eigentliche Sinn, welcher auch in der PDF nachgelesen werden kann ist, die Rechenleistung des betrachtenden PC's zu steigern.
Damit kein LAG entsteht werden die Deteils weiter entfernter Objekte automatisch reduziert um moeglichs wenig Datenstrom ueber die Internet-Leitung und durch die Grafikkarte zu schleusen.

Wenn nun ein Objekt frueher als erwartet zerfaellt, liegt es nicht am Viewer oder an den System-Vorgaben des Servers, sondern schlicht und ergreifend am eigentlichen Objekt selber. Das bedeutet das es kein optimales Mesh-Objekt ist. Entweder der Ersteller hat zu wenig LOD vorgegeben um Uploadkosten und/oder Land Impakt (primcount) zu sparen, oder einfach keine Ahnung von dem was er da tut. Jedenfalls sollte man sich in diesem Fall nach Alternativen umsehen und das Mesh entsorgen.

Um noch mal auf den LOD des Viewers zurueck zu kommen.
Wer den LOD des Viewers erhoeht, setzt damit die automatische Berechnung der Level of Detail ausser kraft und laed dadurch saemtliche verfuegbaren Daten der Szene auf seinen Rechner in die Grafikkarte. Sollte nun die Bandbreite der Internet-Verbindung nicht ganz so dolle sein, werden gegebenenfalls sogar Objekte nicht dargestellt, die man direkt vor der Nase hat, eben weil die Daten dafuer noch gar nicht auf dem Rechner sind. Wenn jetzt noch ein Time-Out eintritt und der Viewer dieses Objekt einfach verwirft, wird man es auch nach 30 Minuten nicht sehen.

Kurz gesagt: Erhoehter LOD gepaart mit hoher Sichtweite = LAG

LG
Dae

Die Bandbreite beeinflusst das LOD bei Second Life überhaupt nicht, da ohnehin immer das gesamte Objekt heruntergeladen wird. Das LOD beeinflusst nur, wie detailliert es bei dir angezeigt wird. SL lädt die Objekte allerdings IMMER komplett herunter. Womöglich wird sich das in vielen Jahren einmal ändern, dass der Server auch nur die Meshdaten in der gewünschten LOD-Stufe überträgt, aber so intelligent ist SL meines Wissens nicht. Bei Webanwendungen wie z.B. Google Maps ist das anders, aber das sind auch meistens nur reine 2D-Bilddaten (so ähnlich wie JPEGs), und keine komplizierten User-Generated 3D-Meshes.
 
@ Martin

Du verdrehst gerade die Situationen. Bitte nicht falsch verstehen.
Also, ich nehme hier ausschliesslich Bezug auf Second Life und da bedeutet es schon Bandbreite und Grafikkarte. Da viele hin gehen und die Sichtweite ganz gern erhoehen, sehen sie mit hohem LOD auch viel mehr weiter entfernte Objecte die gegebenenfalls ganz ausgeblendet waeren, eben weil sie zu weit weg bzw zu klein sind. Wenn nun der LOD so hoch eingestellt ist, das auch kleine Objecte voll dargestellt werden, ziehen sie auch saemtliche Daten von eigentlich nicht sichtbaren Objecten uebers Netz.
In einem anderen Thread habe ich mal beschrieben, das der Viewer sogar Objekte berechnet, die sich hinter anderen grossen Objekten befinden. Dazu geh einfach mal hin und oeffne das Baumenue und zieh einen Rahmen um die gesamte Szene, mit niedrigem LOD und mal mit hohem LOD, dann wiederhole es mit mit unterschiedlicher Sichtweite. Du wirst feststellen das du beim Markieren der Objekte der gesamten Szene mit Hohem LOD und hoher Sichtweite die meisten Objekte, auch die die du eigentlich nicht sehen kannst mit dem Baumenue erfasst.

Ansonsten stimme ich dir zu.

LG
Dae
 
Zuletzt bearbeitet:
@ Martin

Du verdrehst gerade die Situationen. Bitte nicht falsch verstehen.
Also, ich nehme hier ausschliesslich Bezug auf Second Life und da bedeutet es schon Bandbreite und Grafikkarte. Da viele hin gehen und die Sichtweite ganz gern erhoehen, sehen sie mit hohem LOD auch viel mehr weiter entfernte Objecte die gegebenenfalls ganz ausgeblendet waeren, eben weil sie zu weit weg bzw zu klein sind. Wenn nun der LOD so hoch eingestellt ist, das auch kleine Objecte voll dargestellt werden, ziehen sie auch saemtliche Daten von eigentlich nicht sichtbaren Objecten uebers Netz.
In einem anderen Thread habe ich mal beschrieben, das der Viewer sogar Objekte berechnet, die sich hinter anderen grossen Objekten befinden. Dazu geh einfach mal hin und oeffne das Baumenue und zieh einen Rahmen um die gesamte Szene, mit niedrigem LOD und mal mit hohem LOD, dann wiederhole es mit mit unterschiedlicher Sichtweite. Du wirst feststellen das du beim Markieren der Objekte der gesamten Szene mit Hohem LOD und hoher Sichtweite die meisten Objekte, auch die die du eigentlich nicht sehen kannst mit dem Baumenue erfasst.

Ansonsten stimme ich dir zu.

LG
Dae

Das hängt nur von der Sichtweite ab. Es ist in Wirklichkeit so, dass dein Viewer bestimmt welche LOD-Version eines Meshes gerendert oder eben ganz ausgeblendet wird, aber erst nachdem die Daten heruntergeladen sind.
Die Object-Updates werden gesendet egal welche LOD-Stufe verwendet wird, und die Daten sind längst heruntergeladen wenn der Viewer berechnen muss, ob er ein Objekt oder Linkset ausblendet oder nur in niedriger LOD-Stufe rendert oder nicht.
Auf die Bandbreite hat das keinen Einfluss. Nur auf die PC-Ressourcenverwendung.
Das kannst du ja sehr leicht testen indem du den Cache leerst und reloggst, und auf der Statistikanzeige beobachtest wieviele Daten heruntergeladen werden, dann wieder den Cache leerst und reloggst, und mit einer anderen LOD-Stufe neu einloggst, und dann die Werte vergleichst. Solange du an der Bandbreiten-Einstellung und an der LOD-Einstellung nichts änderst, sollten die Werte gleich bleiben.
 
@ Martin

Ich wage zu bezweifeln, das der Server irgend welche Geometriedaten an den Viewer sendet, die der Viewer auf Grund der Entfernung (Sichtweite) noch nicht darstellt, sonst hiesse das, man wuerde sich alle Skyboxen komplett in den Cache laden, wenn man nur mal hoch guckt. Nun gibt es mehrere Methoden den LOD festzulegen, zum einen auf Entfernungsbasis und zum anderen auf Basis der Groesse des Objects. SL geht nun einen Schritt weiter und verwendet eine Kombination aus beidem. Ich wuerde lediglich sagen, das der Viewer zunaechst erst einmal nur die Entfernung und Groesse der Objecte gesendet bekommt und dann erst wird entschieden ob das Object uebertragen wird oder eben nicht und wenn ja, mit welcher Detailstufe.

Und ab der Detailstufe sind wir bei der Grafikkarte. Wenn nun ein Object mehrere Faces mit unterschiedlichen Texturen verwendet, koennen wir froh sein die ausgeblendeten Texturen eventuell fehlender Faces des Objects nicht auch noch downloaden zu muessen. So wie ich es verstanden habe, werden erst die Geometriedaten geladen und dann erst die noetigen Oberflaechen-Texturen. Und alles was die Grafikkarte nicht bekommt ist eine Erleichterung. Kurz gesagt, was nicht da ist, muss auch nicht berechnet werden.

Das ist das eigentliche Problem, wenn die Sichtweite entsprechend hoch ist und der LOD ebenfalls, dann laed man Objecte und deren Texturen die man gegebenenfalls nicht sieht oder sehen koennte, weil sie zu klein sind. Darunter zaehlen dann auch Sculpties, wodurch gleich 2 Texturen geladen und verarbeitet werden, naemlich erst die Map und dann die Oberflaechentextur. Sculpties bedeuten immer eine doppelte Belastung fuer die Grafikkarte, da die Form des Sculpties ausschliesslich in der Grafikkarte generiert wird, in SL jedoch sind Sculpties Physisch immer Baelle (Eier). Nun gehen viele hin und verwenden viele kleine Sculpties fuer Deco wie Tassen, Kerzen, Flaschen und all das andere Gedoens was man so im Haushalt findet. Normalerweise wuerde dieser Kleinkram ab einer gewissen entfernung total zerfallen bzw noch nicht dargestellt werden, mit einem erhoehten LOD wuerde man sich das Zeug nun aber schon in den Cache und in die Grafikkarte laden, bevor man es ueberhaupt sehen koennte, weil es 100m weiter in einem Haus steht.

LG
Dae
 
Zuletzt bearbeitet:
@ Martin

Ich wage zu bezweifeln, das der Server irgend welche Geometriedaten an den Viewer sendet, die der Viewer auf Grund der Entfernung (Sichtweite) noch nicht darstellt, sonst hiesse das, man wuerde sich alle Skyboxen komplett in den Cache laden, wenn man nur mal hoch guckt. Nun gibt es mehrere Methoden den LOD festzulegen, zum einen auf Entfernungsbasis und zum anderen auf Basis der Groesse des Objects. SL geht nun einen Schritt weiter und verwendet eine Kombination aus beidem. Ich wuerde lediglich sagen, das der Viewer zunaechst erst einmal nur die Entfernung und Groesse der Objecte gesendet bekommt und dann erst wird entschieden ob das Object uebertragen wird oder eben nicht und wenn ja, mit welcher Detailstufe.

Und ab der Detailstufe sind wir bei der Grafikkarte. Wenn nun ein Object mehrere Faces mit unterschiedlichen Texturen verwendet, koennen wir froh sein die ausgeblendeten Texturen eventuell fehlender Faces des Objects nicht auch noch downloaden zu muessen. So wie ich es verstanden habe, werden erst die Geometriedaten geladen und dann erst die noetigen Oberflaechen-Texturen. Und alles was die Grafikkarte nicht bekommt ist eine Erleichterung. Kurz gesagt, was nicht da ist, muss auch nicht berechnet werden.

Das ist das eigentliche Problem, wenn die Sichtweite entsprechend hoch ist und der LOD ebenfalls, dann laed man Objecte und deren Texturen die man gegebenenfalls nicht sieht oder sehen koennte, weil sie zu klein sind. Darunter zaehlen dann auch Sculpties, wodurch gleich 2 Texturen geladen und verarbeitet werden, naemlich erst die Map und dann die Oberflaechentextur. Sculpties bedeuten immer eine doppelte Belastung fuer die Grafikkarte, da die Form des Sculpties ausschliesslich in der Grafikkarte generiert wird, in SL jedoch sind Sculpties Physisch immer Baelle (Eier). Nun gehen viele hin und verwenden viele kleine Sculpties fuer Deco wie Tassen, Kerzen, Flaschen und all das andere Gedoens was man so im Haushalt findet. Normalerweise wuerde dieser Kleinkram ab einer gewissen entfernung total zerfallen bzw noch nicht dargestellt werden, mit einem erhoehten LOD wuerde man sich das Zeug nun aber schon in den Cache und in die Grafikkarte laden, bevor man es ueberhaupt sehen koennte, weil es 100m weiter in einem Haus steht.

LG
Dae

Wie gesagt, das ist ganz einfach zu überprüfen dass der Traffic gleich bleibt, unabhängig vom gewählten LOD in den Grafikeinstellungen.
Log dich zwei Mal am gleichen Ort ein, einmal mit der höchsten LOD-Stufe, und einmal mit der niedrigsten, und vergleiche wieviel Traffic das verursacht.

Ich habe mir erlaubt das mal für dich zu testen, und habe hier an dieser Stelle die Anzahl der übermittelten Pakete bei zwei verschiedenen neuen Accounts mit leerem Inventar gemessen (natürlich genau über die gleiche Zeitspanne):

r6XoUxm.png

Wie du siehst ist bei beiden genau gleich viel heruntergeladen worden in einer Mainland-Sim mit der höchsten DD. Egal was bei LOD eingestellt ist.
Probier es einfach selber aus.
Und ich habe nie gesagt dass der Server Geometriedaten sendet die der Viewer aufgrund der Sichtweite noch nicht darstellt. Der Server richtet sich nach der "Interest List" die er gemeinsam mit dem Viewer ermittelt.
 

Anhänge

  • Traffic.jpg
    Traffic.jpg
    57,5 KB · Aufrufe: 3
Zuletzt bearbeitet:
Versuch das gleiche mal, auf meiner Sim. http://slurl.com/secondlife/Bay of Surreality/135/119/25
Stell dich in die Mitte der Sim auf die Bruecke und schau in Richtung meines Stores.
Die Werte sollten auf einer Vollen Sim dann voellig anders aussehen. ;)

PS: Was hat der Packetloss mit dem Traffik zu tun?
Du siehst darauf doch lediglich das bei beiden Einstellungen du keinen Datenverlust hast, aber nicht wieviel MB tatsaechlich uebertragen wurden.

LG
Dae
 
Zuletzt bearbeitet:
Versuch das gleiche mal, auf meiner Sim. http://slurl.com/secondlife/Bay of Surreality/135/119/25
Stell dich in die Mitte der Sim auf die Bruecke und schau in Richtung meines Stores.
Die Werte sollten auf einer Vollen Sim dann voellig anders aussehen. ;)

LG
Dae

Bitte probiere es selber, Selenia wo ich das getestet habe IST recht voll. Es ist völliger Unsinn dass das LOD sich auf die Bandbreite auswirken würde.
Wie stellst du dir das vor: wenn du die LOD änderst, müsste der Server dann alle Daten nochmal senden?? lol
Nein, der Server hat noch nichtmal die Daten aus den verschiedenen LOD-Stufen separat gespeichert - das einzige was diesbezüglich möglich ist, ist der sequentielle Transfer von JPEG-Daten in unterschiedlichen Kompressionsstufen, aber da wird dennoch das gesamte Bild übermittelt, aber eben in einer solchen Art und Weise, dass man die Datei schon anzeigen kann bevor sie komplett geladen ist.

Bitte komm von der Idee weg, dass sich LOD auf den Traffic auswirken würde, das ist Nonsense. Das hat es noch nie.

Wenn du wirklich vom Gegenteil überzeugt ist, logg dich so wie ich oben selbst mit zwei neuen Avataren gleichzeitig ein nachdem du den Cache gelöscht und den Viewer neu gestartet hast, logg dich genau gleichzeitig mit beiden Viewern ein, und schick dann einen Beweisscreenshot hoch (natürlich müssen beide Avatare genau in die selbe Richtung sehen schon beim ausloggen *vor* diesem Test).

PS: Ganz simpel kannst du dich auch davon überzeugen dass sich LOD in keinster Weise auf den Traffic auswirkst, indem du den Cache leerst, reloggst mit niedrigsten LOD-Stufen (schon bevor du eingeloggt hast sollte LOD auf der niedrigsten Stufe stehen), dann wartest du einfach bis alles geladen hat, und kappst dann deine Internetverbindung. Und noch bevor der Viewer merkt dass das Netz weg ist (du solltest zumindest 5-10 Sekunden Zeit haben) drehst du die LOD auf den höchsten Wert, und wirst sehen dass alles mit höchster LOD dargestellt wird, obwohl der Viewer gar keine Möglichkeit hatte, irgendwelche Extra-Daten runterzuladen.
 
Zuletzt bearbeitet:
@ Martin

Entweder wir reden aneinander vorbei, oder du verstehst mich nicht.
Natuerllich haengt der LOD mit der Sichtweite zusammen, es geht mir um die kleinen deteils (Einzel-Objekte) die bei gleicher Sichtweite nicht uebertragen werden, weil sie bei 100m Entfernung noch nicht sichtbar waeren, bei einem erhoehtem LOD jedoch schon.

LG
Dae
 

Users who are viewing this thread

Zurück
Oben Unten