• 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.

Mesh Darstellung im Firestorm 4.5.1.38838

shanique

Nutzer
Hallo Leutz.

Vorgestern hab ich auf den neuesten Firestorm umgestellt und seitdem dauert es ewig bis die Mesh Kleidung anderer Avas geladen wird. Gibt's da vielleicht ne Einstellung die ich ändern sollte?
Vielen dank schon mal im Voraus

Shanique
 
Danke für die Antwort. Mein Krempel lädt prima schnell nur die anderen sehen oft komisch aus wenn da ewig die Textur fehlt und nur die Alpha´s Löcher in die Avas reißen ;-)
 
Hallo shanique,
probier mal den Wert MeshMaxConcurrentRequests höher zu stellen - z.B. 64 in den Debug-Settings (Standardwert ist 32). Die Debug-Settings erreicht man im Firestorm mit der Tastenkombination Ctrl-Alt-Shift-S (normal im "Advanced"-Menü - wenn das nicht angezeigt wird, drücke Ctrl-Alt-D).
Falls das nicht hilft, stell es bitte wieder zurück auf den Standardwert (32).

Du kannst auch die HTTP-Texturen aktivieren falls sie das nicht sind (ansonsten testweise deaktivieren):
CTRL+ALT+Q (Entwickler-Menü) -> HTTP Texturen

Sollte das nicht helfen, das ebenfalls bitte wieder zurückstellen auf die Original-Einstellung.
 
Zuletzt bearbeitet:
Hej Canis,

nun ja, wir empfehlen die Beta zu nutzen aber es ist eben noch eine Beta-Version. Die Unterstützung durch den Support ist sicherlich gegeben aber im Zweifel wird dann auf die Release verwiesen.
 
Ich hab auch die Betaversion geladen und auch wenn ich sagen muss, dass es die bisher schnellste Version eines Firestorms ist, so hab ich auch meine Probs. Meshes werden zwar korrekt dargestellt, aber irgendwie ist meine Grafik generell schlechter geworden. Das Antialiasing scheint nicht richtig zu funktionieren und selbst wenn ich auf Ultra bin und mich unter vielen Avataren befinde, sehen die weiter von mir entfernten Personen (z.B. außerhalb der Chatrange als Entfernungsvergleich) grobpixelig aus und bewegen sich nur ruckartig alle paar Frames … als wenn ich in einem überfüllten Raum auf Medium bin. Schatten werden meiner Meinung nach auch schlechter dargestellt. Mein Grafikkartentreiber ist auf dem neuesten Stand, daran kann es also nicht liegen … ich hoffe, dass noch ein wenig am Feinschliff gearbeitet wird bis die fertige Version released wird, bis dahin steige ich wieder auf den Vorgänger um.
 
selbst wenn ich auf Ultra bin und mich unter vielen Avataren befinde, sehen die weiter von mir entfernten Personen (z.B. außerhalb der Chatrange als Entfernungsvergleich) grobpixelig aus und bewegen sich nur ruckartig alle paar Frames … als wenn ich in einem überfüllten Raum auf Medium bin.
Hallo Charlie,
diese ruckartig animierten verpixelten Avatare sind sogenannte 'Impostors' - Ersatzbilder die geladen werden wenn zu viele Avatare gleichzeitig sichtbar sind.
In den Grafikoptionen kannst du selber einstellen ab wie vielen sichtbaren Avataren Impostors eingesetzt werden sollen, damit trotz vieler Avatare das Spiel trotzdem weiter flüssig bleibt (und um Ressourcen zu schonen).
 
Danke, Martin, aber an meinen Einstellungen hab ich nichts verändert und der Unterschied zur Vorgängerversion ist gravierend. Ich werd's dennoch heute Abend mal probieren ...
 
Hallo Leutz.

Vorgestern hab ich auf den neuesten Firestorm umgestellt und seitdem dauert es ewig bis die Mesh Kleidung anderer Avas geladen wird. Gibt's da vielleicht ne Einstellung die ich ändern sollte?
Vielen dank schon mal im Voraus

Shanique

Es kann bei sein, dass Meshes nicht komplett geladen werden. Dann bricht das Ganze nach einem timeout ab - und wird nach einer kurzen Pause noch mal gestartet. Und wird dann auch wieder nicht vollständig geladen, dann bricht das Ganze nach dem timeout wieder ab. Dabei werden Meshes nicht als ganzes geladen, sondern immer nur LOD (Detailstufen) für LOD. Zusätzlich sind oft noch Texturen in den Mesh-Daten drin, die werden dann auch über die Mesh-Pipeline geladen, weswegen eine einzelne Mesh Datei auch mal ein paar MB groß sein kann. Und weswegen für manche Sims mit vielen Avas erst mal über 100MB an Daten geladen werden müssen, bis man alle Meshes sehen kann.

Sehen kann man das Laden der Meshes im Viewer, wenn man neben dem Advanced Menu (Strg+Alt+d) auch das Develop Menu (Strg+Alt+q) aktiviert. Dort kann man dann mit "Show Info" --> "Show Render Info" diverse Statistiken und Zahlen einblenden. Interessant ist hier dann "0/0 Mesh HTTP Requests/Retries", Werden Meshes geladen, dann geht der linke Wert hoch. Geht aber der Rechte Wert hoch, dann mussten Meshes erneut geladen werden. Ein "2639/0 Mesh HTTP Requests/Retries" ist also eine gute Anzeige, eine "2639/2100 Mesh HTTP Requests/Retries" ist alles andere als gut, da wurden die meisten LOD nicht geladen, weil der Download abgebrochen wurde.

Helfen kann in diesem Fall eine Reduzierung von "MeshMaxConcurrentRequests" von 32 auf z.B. 5 oder 6 (oder noch weniger...) und paar Minuten warten helfen. Dann haben die einzelnen Meshes mehr Bandbreite für den Download (weil nicht mehr 32, sondern nur noch 5 oder 6 gleichzeitig geladen werden), so dass die schneller zu Ende geladen werden können - und es kommt nicht mehr zu einem Timeout. Läuft das alles gut, dann kann man den Wert langsam wieder hoch drehen, bis die "Mesh Loading Retries" wieder hoch gehen.

Falls viele Retries angezeigt werden: Wie ausgelastet ist deine Netzwerk-Verbindung? Z.B. durch andere Programme (besonders File Sharing).
Wenn du für SL nur wenig Bandbreite über hast (1Mbit z.B.), dann kann genau dieses Problem auftreten. Denn da können andere Programme auch viele gleichzeitige Verbindungen benötigen, so dass billige/ältere Router durchaus mal überfordert sein können, eben weil da nicht mehr als z.B. 200 oder 500 gleichzeitige Verbindungen möglich sein. Manchmal hilft da ein Router Reset, bei dem der Router den Speicher wieder frei bekommt.

Ansonsten (wenn es nicht viele Retries gibt) kann es helfen wie erwähnt den Wert für "MeshMaxConcurrentRequests" bisschen hoch zu drehen - allerdings wohl nicht mehr lange, denn das wird in absehbarer Zeit vom Server auf 32 limitiert werden, einfach weil viele User den Wert ziemlich hoch geschraubt hatten, so dass eben auf dem Server Netzwerk-Lag enstand, wenn da viele User waren...
 
Muss ich das jetzt verstehen?

Hallo shanique,
probier mal den Wert MeshMaxConcurrentRequests höher zu stellen - z.B. 64 in den Debug-Settings (Standardwert ist 32).

...Helfen kann in diesem Fall eine Reduzierung von "MeshMaxConcurrentRequests" von 32 auf z.B. 5 oder 6 (oder noch weniger...) und paar Minuten warten helfen. Dann haben die einzelnen Meshes mehr Bandbreite für den Download (weil nicht mehr 32, sondern nur noch 5 oder 6 gleichzeitig geladen werden), so dass die schneller zu Ende geladen werden können - und es kommt nicht mehr zu einem Timeout...

LG
Dae
 
Und da schimpft man auf Behörden: "Nein, Sie müssen die ganze Treppe wieder runter in den Raum, von dem man Sie hierher geschickt hat"


:rofl
 
Muss ich das jetzt verstehen?





LG
Dae

Shirley hat sehr gut erklärt in welchem Fall man den Wert reduzieren muss. Es kann sicherlich nicht schaden beides zu probieren. Schließlich ist jedes System und jede Internetleitung anders.
Wenn man einen sehr guten Router hat, dann kann es durchaus helfen den Wert zu erhöhen. In dem von Shirley beschriebenen Fall, wenn die Downloads abbrechen, weil mehr gleichzeitige Verbindungen als von der Hardware des Users unterstützt benutzt werden, dann sollte man den Wert senken : )


allerdings wohl nicht mehr lange, denn das wird in absehbarer Zeit vom Server auf 32 limitiert werden, einfach weil viele User den Wert ziemlich hoch geschraubt hatten, so dass eben auf dem Server Netzwerk-Lag enstand, wenn da viele User waren...

Monty Linden hat gesagt, dass er den Wert in Zukunft serverseitig auf "gut unter 100" beschränken möchte, und dass in Zukunft einmal viewer-seitig der Wert auf ein niedrigeres Maximum gestellt werden soll: http://modemworld.wordpress.com/201...date-week-34-2-server-viewer-group-bans-http/

Ich finde man kann aus diesen Aussagen nicht unbedingt konkrete Zahlen (32) ableiten.
 
Zuletzt bearbeitet:
Die "32 maximalen gleichzeitigen Verbindungen" sind auch nichts offizielles, die wurden (vermutlich dann von Oz) nur irgendwann mal nebenbei auf der OS-Dev liste als default-Wert für den Viewer genannt, die man "irgendwann in Zukunft" eben nur noch kleiner stellen kann (vor allem für User mit nur wenig Bandbreite) bzw. die vom Curl/HTTP Part im Viewer irgendwann automatisch geregelt werden sollten, die man dann aber nicht mehr über den default wert hochdrehen können soll. Konkret gings damals allerdings weniger explizit um Mesh (das war damals nur neu und wurde nur mal als Beispiel genannt) sondern um die neue HTTP Librarries und dabei generell um die Anzahl der HTTP-Verbindungen an sich, die der Viewer bzw. curl (die HTTP-Bibliothek im Viewer) zum Simulator aufbaut. Und in wie weit das mit den entsprechenden HTTP RFCs usw. noch passt, die nur 2 Verbindungen zum Server vorsehen usw.. Das muss also noch grob Mitte 2012 gewesen sein dann. Jedenfalls gings eben darum, dass manchmal zu viele User mit zu vielen Connections dann irgendwann auch Netzwerk-Probleme machen, und daher der Hinweis "kann irgendwann nur noch kleiner eingestellt werden, nicht mehr größer".

Ich hab allerdings keine Lust die ganzen Archive der Mailing list jetzt zu durchsuchen. Zumal das damals auch alles andere als offiziell war. Und der Viewer bzw. curl derzeit wohl locker 256 Verbindungen zum Simulator aufmachen könnte.
 
Vielen Dank, mehr wollte ich gar nicht wissen.
Mir leuchtete nur nicht ein, wieso im einen Beitrag eine Erhoehung empfohlen wird und in einem anderen eine Reduzierung fuer die gleiche Sache.
Also kann man das so gar nicht pauschalisieren. Kurz zusammen gefasst bedeutet das, wenn du eine schnelle Internet Anbindung mit hoher Bandbreite hast, kannst es mit erhoehen probieren, sollte deine Bandbreite nicht so dolle sein, versuche es lieber mit reduzieren.

Ich wollte nur sicher gehen, dass dieses nicht wieder in einem Pseudo-Ratschlag endet, wie der Schwachsinn mit dem LOD hoeher drehen, den so viele Sculptie Ersteller gerne in die Marketplace Beschreibung und in NCs verbreiten, nur damit schlecht gemachte Sculpties trotzdem ansehnlich sind. Das es dann laggt wie Sau, weil eben nicht nur die Sculpties, sondern auch andere nicht direkt sichtbare Details, die eigentlich ausgeblendet sein sollten verarbeitet werden, schreibt naemlich niemand dabei.

LG
Dae
 
Kurz zusammen gefasst bedeutet das, wenn du eine schnelle Internet Anbindung mit hoher Bandbreite hast, kannst es mit erhoehen probieren, sollte deine Bandbreite nicht so dolle sein, versuche es lieber mit reduzieren.
Es kommt auch sehr darauf an, wie viele gleichzeitige Verbindungen die Leitung (in erster Linie meist der Router/Kabelmodem) schafft. Die meisten Consumer-Geräte sind leider ziemlicher Mist :( - (ich schließ mich da nicht aus) deswegen sollte man es lieber mit defensiven Einstellungen probieren (das ist auch vermutlich der Hauptgrund, warum alle Leute von Firestorm sagen, man sollte die Bandbreite im Viewer möglichst niedrig einstellen).
 
(das ist auch vermutlich der Hauptgrund, warum alle Leute von Firestorm sagen, man sollte die Bandbreite im Viewer möglichst niedrig einstellen).

Nein das ist nicht der Grund denn die Bandbreiteneinstellung im Viewer beeinflusst nicht den Datenstrom per HTTP.
Die Nutzbare Bandbreite per UDP-Protokoll hängt nicht nur davon ab was der Provider, bzw der Tarif anbietet, sondern wie die Route an die Westküste der USA ausfällt.
 
Zuletzt bearbeitet:
Nein das ist nicht der Grund denn die Bandbreiteneinstellung im Viewer beeinflusst nicht den Datenstrom per HTTP.
Die Nutzbare Bandbreite per UDP-Protokoll hängt nicht nur davon ab was der Provider, bzw der Tarif anbietet, sondern wie die Route an die Westküste der USA ausfällt.

Ob die Route eine so große Rolle spielt weiß ich nicht, aber diese "Bandbreite" Einstellung sagt aber einfach dem Server wie viele kbits an UDP-Paketen er an den Viewer schicken kann, da es bei diesem Protokoll anders als bei HTTP keine Rückmeldung gibt (es ist "Verbindungslos").
Allerdings regelt der Viewer das auch bisschen selbst: Geht der Packet-Loss bei UDP-Paketen über 5%, dann drosselt der Viewer schrittweise diesen Wert intern. Und erst wenn er paar Sekunden unter 3% gefallen ist wird das wieder angehoben, und zwar so lange, bis der Packet loss wieder über 5% geht. Das heißt, dass man auch mit einer Einstellung von "1000 kbits" bis zu 50% mehr als die z.B. Eingestellten 1000 kbits Downloaden kann mit dem Viewer. Dieser "1000 kbits" ist nur ein "Anfangswert", um den das Ganze grob pendelt. Der Viewer kann dann bis 1500 kbits gehen, wenn man da 1000 kbits einstellt. (aber nie über 3000kbits, das ist im Viewer begrenzt). Zusätzlich regelt dieser Wert aber auch noch andere UDP Bandbreiten neben dem Texturdownload per UDP, abhängig davon was man da an kbits mind. eingestellt hat (50, 300, 500 oder 1000) werden auch andere UDP-Ströme beeinflusst (Resend, Task, usw), das hat dann auch Einfluss auf, Rückmeldung, Bewegungs-Lag usw.

Und genau deswegen wird immer wieder empfohlen das Ganze erst mal nicht zu hoch einzustellen. Und diesen Wert eben nicht gleich auf Vollgas zu drehen. Sondern allenfalls nach und nach nach oben zu schieben.
 

Users who are viewing this thread

Zurück
Oben Unten