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

Tutorial Region/Viewer Performance

Daemonika Nightfire

Forumsgott/göttin
huhu,

wie die meisten von euch wissen, haben wir folgende Themen schon zum erbrechen durchgekaut, aber nie so richtig zusammen gefasst.
Die Performance Wiki ist fuer viele auch nicht gerade hilfreich, da sie relativ oberflaechlich ist und zu viel Fach-Chinesisch enthaelt.
In den folgenden Abschnitten, moechte ich euch einige Hilfsmittel vorstellen, die jeder von euch besitzt und ziemlich leicht versteht.

Anfangen moechte ich zu aller erst mit Texturen & Sculpties.

Texturen & Sculpties:

Das leidige Thema Texturen, immer wieder wird seit jahren gepraedigt, nicht zu grosse Texturen zu verwenden, weil sie mehr ladezeiten beanspruchen.
Bei sehr Grossen Bauwerken habe ich irgend wo noch ein gewisses Mass an Verstaendniss fuer Grosse 1024x1024 pixel Texturen, solange sie im gegenzug immer wieder verwendet wird. Allerdings gibt es Pappnasen, die sogar fuer saemtliche Details solche grossen 1024x1024 pixel Texturen verwenden, ja selbst fuer kleine Dinge.
Dazu moechte ich mit dem folgenden Bild ein kleines Beispiel erlaeutern:
attachment.php

Es ist 2x das gleiche Mesh, die linke Kiste verwendet die original Textur des Erstellers und ist 1024x1024 pixel gross.
Die kiste auf der rechten seite verwendet die gleiche Textur, jedoch habe ich sie vorher runter geladen (legal, sie lag fullperm dabei) und mit einem Bildbearbeitungsprogram lediglich verkleinert und mit 512x512 pixel neu hoch geladen.
Ich will nicht bestreiten, das die groessere Textur qualitativ etwas besser ist, allerdings solange man keinen direkten Vergleich hat, wird es niemals auffallen, dass die kleinere nicht ganz so scharf ist, allerdings benoetigt sie auch nur ein Viertel des Speichers der grossen Textur.

Fazit: Nach moeglichkeit generell auf Texturen groesser als 512x512 pixel verzichten.

Nun werden sich manche vielleicht fragen wie ich von Texturen nun auf Sculpties komme. Ganz einfach, Sculpties sind Texturen.
Auf dem folgenden Bild werdet ihr eine Statue sehen, der ein oder andere mag sie vielleicht sogar kennen. Jemand ganz bestimmtes wird sich jetzt vielleicht nicht mehr wundern warum ich diese Statue nicht leiden kann.
attachment.php

Optisch sieht diese Statue einfach gut aus, kein zweifel. Technisch ist sie aber ein Desaster.

Diese Statue besteht aus 48 Sculpties und eben so vielen Oberflaechen-Texturen mit gebackenen Schattierungen.
Idiotischerweise besteht jede Textur aus 1024x1024 pixel Texturen, wobei die Sculptie-Maps gerade mal lediglich 128x128 pixel gross sind.
Koennt ihr euch vorstellen, wieviel MB daten durch das Netzwerk gehen, wenn man sie noch nicht im Cache hatte und direkt dort hin teleportiert?
Jemand mit einer nicht ganz so schnellen DSL Leitung wartet einige Minuten bis das diese Statue vollstaendig geladen ist und hat anschliessend mit sehr hoher Wahrscheinlichkeit sogar LAG. Wenn jede dieser Texturen und Sculptie-Maps jeweils mit 50kb fuer die Maps und 500kb fuer die Texturen zu Buche schlaegt, macht das einen Download von 26,4MB nur fuer diese einzelne Statue aus, den man erst einmal nach rezzen/teleport ueber sich ergehen lassen muss.
Jetzt stellt euch mal vor, Avatare schlagen so behangen in einem Club auf. ;)

Warum sind fuer viele Sculpties eigentlich beim ersten Rezzen Eier?
Ganz einfach, die Dinger muessen 2x durch eure Grafikkarte, 1x fuer die Map, um die Form zu generieren und 1x fuer die Oberflaechen-Textur.

Bleiben wir noch ein wenig bei Sculpties.
Wie erkennt man eigentlich Sculpties, die die Viewer-Performance in den Keller ziehen?
Das ist gar nicht so einfach, wenn man nicht weiss wo man sich die groessen der Maps anzeigen lassen kann.
Dazu haben die Viewer ein nettes Hilfsmittel, ihr findet es im Linden-Viewer im Entwickler Menue unter den Meta Daten. Dort schaltet einfach mal Sculpties an.
Im Cool VL Viewer befindet sich dieser Menupunkt im Advanced - Rendering - Info Displays.

Nachdem ihr das eingeschaltet habt, werdet ihr erst einmal von unzaehligen Buchstaben und Zahlen erschlagen. Keine Panik, zoomt da einfach mal naeher ran und lest die untere Zeile und beachtet die Buchstaben nicht. In der unteren Zeile steht genau wie gross die jeweilige Sculptie-Map ist.
Auf dem folgenden Bild, seht ihr welche Zahlen ich meine:
attachment.php

Ich habe den Reifen mal rot eingefaerbt, um besser zu sehen um welches Detail es sich handelt.
Warum zum Teufel wurde fuer diesen Reifen eine 512x512 pixel Sculptie-Map verwendet, waerend der Rest des Fahrzeugs fuer wesentlich komplexere Sculpties, aus viel kleineren Maps besteht?
Zu 99,9% bestehen saemtliche Sculpties auf meiner Region aus wesentlich kleineren Maps und der ueberwiegende teil davon sogar nur aus 64x64 pixel Maps.
Jetzt nachdem ich diesen Reifen entdeckt habe, hat er keine hohe Lebenserwartung mehr und geht uebern Jordan, sobald ich einen passenden Ersatz habe.

Langsam moechte ich aber zum Thema Mesh ueberwechseln, aber vorher vergleicht mal die Werte der folgenden beiden Bilder. Bachtet dabei die unteren 4 eintraege des Fensters Object Weights:
Sculptie
attachment.php


Mesh
attachment.php


Fortsetzung im naechsten Beitrag, wegen Bilder-Limit.



grosse Texturen.jpg zu viele zu grosse texturen.jpg Sculpt-Map.jpg LOD Sculpt.jpg LOD Mesh.jpg
 
Fortsetzung Tutorial Region/Viewer Performance

Auf diesem Bild habe ich mal beide Reifen direkt nebeneinander gelegt und die groessen angeglichen.
attachment.php

Fuer mich besteht kein plausibler Grund auf Sculpties zurueck zu greifen, die Resultate sind bei Mesh aehnlich und oftmals sogar besser.

Entlich beim Thema Mesh angekommen, moechte ich auch gleich mit dem LOD Faktor los legen.
Es gibt doch tatsaechlich Pappnasen, die beim Mesh-Upload in allen 4 Detailstufen die Gleichen Werte verwenden, wie in der ersten.
Das sie damit reine Lagschleudern produzieren scheinen sie entweder nicht zu wissen, oder es ist ihnen egal.
Auf dem naechsten Bild moechte ich euch ein kleines Beispiel zeigen wie sich der LOD Faktor auswirkt.
attachment.php

Hier seht ihr 2x die selbe Szene aus der selben Blickrichtung. Links im bild war meine Cam etwa 15 Meter entfernt, rechts im Bild habe ich bis auf 2 Meter heran gezoomt. Nicht ganz so gut zu erkennen, weil es doch etwas weit weg ist, aber man kann sehen, das die weissen Isolatoren teilweise zerfallen. Mancher wuerde jetzt sagen, 15 Meter und schon zerfallen ist mist. Naja, nicht bei der groesse und sie sind auch gar nicht direkt im Sichtbereich. Man muss also abwaegen wofuer man hoeheren LOD benoetigt, fuer Details die man sowiso erst erkennt wenn man direkt hin schaut, reicht das voellig aus, besonders bei diesen Dingern, da sie knapp 10 Meter uebern Boden haengen.

Wer mehr ueber die LOD Stufen von Mesh erfahren moechte, dem kann ich den Thread von Jenna Felton waermstens empfehlen:
http://www.slinfo.de/forum/meshes/32021-mirage-effekt-durch-meshes.html

Naeher moechte ich im Moment nicht auf Mesh eingehen und das Thema auf Lichtquellen umschwenken.
Lichtquellen stehen bei mir auf der Liste der Lagschleudern ganz oben an erster stelle. Je mehr Lichtquellen in der Szene (Sichtbereich) desto laenger dauert das rendern. Fuer jede Lichtquelle muss nicht nur das Licht gerendert werden, sondern auch saemtliche Reflektionen auf den umliegenden Oberflaechen.
Ganz schlimm sind fuer mich diese Facelights, denn die Fluten nicht nur die Szene mit licht und verpesten das Ambiente, sie bewegen sich auch noch, wodurch die Szene permanent neu gerendert werden muss.

Das ist aber noch nicht alles.
Viele verwenden auch viel zu viel Licht. Auf dem folgenden Bild kann man sehen, wieviel Lisht fuer eine Kerze ausreichend ist:
attachment.php

Hier habe ich mir wieder die Meta Daten (LL Viewer, Entwickler Menue - Meta Daten | Cool VL Viewer, Advanced - Rendering - Info Displays) zur hilfe genommen und diesmal Lights (Licht) aktiviert.
Man kann erkennen, das der Lichtradius lediglich 80cm betraegt was einen Durchmesser von 1,60m ausmacht. Viel mehr wuerde eine Kerze im Real Life auch nicht ausleuchten. Trotzdem verwenden sehr viele in Second Life Einstellungen von 10m und 20m fuer so eine Popelige Kerze.
Nun ist mein Bild mit Ultra Grafik und aktivierten Schatten aufgenommen, jemand mit Middle Grafik ohne Schatten wuerde von dem Licht wahrscheinlich gar nichts sehen. Das hat auch seinen guten Grund, naemlich den die Umgebung auf die Leistung seiner Hardware anzupassen. Wuerden naemlich alle mit Middle und High Grafik das selbe sehen koennen, wie die mit Ultra Grafik, wuerden alle gleichermassen ueber LAG jammern. Trotzdem gehen viele hin, damit sie mit einer Beschissenen 10€ Grafikkarte etwas von den Lichtverhaeltnissen sehen koennen, stellen im Baumenue bei den Lichtern 10m und 20m Radius ein. Dann sehen sie auch ein wenig licht, aber alle anderen mit hoeherer aufloesung, werden entweder geblendet, oder haben LAG wie Sau, weil man das Licht vom Mond aus sehen kann.

Fazit: Mit Lichtquellen sollte man extrem sparsam umgehen und darauf achten, dass sie nicht zu hohe werte haben, andernfalls habt ihr gewaltigen LAG.

Nun moechte ich euch Zeigen, was ihr mit hilfe der Metadaten alles ueber Particle auslesen koennt.
Particle machen eigentlich selten LAG, ausser man verwendet zu viele und zu grosse Texturen dafuer. Na doll, nun spielen Grosse Texturen schon wieder eine Rolle. ;)
Anhand der Metadaten koennt ihr zwar nicht sehen wie gross die verwendete Textur ist, aber ihr koennt es erahnen, wenn ihr sie das erste mal seht, je laenger sie Grau ist, desto groesser ist sie.
Worauf ich aber hinaus will sind die Particle Parameter.
Auf dem Folgenden Bild koennt ihr 2 Pfeile sehen, die fuer mich im ersten Moment den Wichtigsten Punkt darstellen:
attachment.php

Warum neben der Burst Rate so eine Krumme Zahl steht weiss ich nicht, sie bedeutet aber 0.1 und steht fuer die haeufigkeit pro sekunde. Das heisst, 10x pro sekunde stoesst der Emiter die Particle aus. Wie viele seht ihr neben Burst Count. nun rechnen wir mal etwas.
4 Particle 10x pro secunde etsprechen 40 Particle pro Sekunde.
Nun lassen wir mal die Lebensdauer 5 secunden betragen, schon haben wir nach 5 Sekunden nicht 40 Particle, sondern 200 Particle pro secunde, weil die ersten noch existieren, waerend schon neue gemacht werden.
Jetzt stellt ihr euch mal vor, wenn bei dem Burst Count nicht 4 particle eingestellt sind, sondern 40. Da komt gleich eine stolze summe von 2000 particle pro seckunde heraus, wenn sie 5 sekunden Lebensdauer haben. Jetzt stellt mal 4 Solcher brennenden Tonnen in eurer Szene auf, ihr seht dann satte 8000 Particle. Macht euch mal den Spass und stellt 20 Tonnen auf, wie viel Particle seht ihr dann? Genau, 8000 und alle sehr ausgeduennt, weil der Viewer bei 8000 dicht macht. Im schlimmsten Fall seht ihr nur die ersten 4 Tonnen brennen und die restlichen gar nicht.

Einen habe ich noch fuer die Meta Daten.
Animierte Texturen, die koennt ihr ebenfalls damit aufspueren.
Auf einer Region sollten Texturen nur Animiert werden, wenn es wirklich Sinnvoll ist oder man nicht drauf verzichten kann.
Im folgenden Bild macht eine animierte Textur natuerlich Sinn, weil Wasser ohne Animation einfach Kacke aussieht.
attachment.php

Ob animierte Texturen die Viewer performance beeintraechtigen oder nicht kann man daran sehen, dass man sie explizit im Advanced abschalten kann.
Wie viel animierte Texturen nun ausmachen kann ich nicht sagen, jedoch sollte man unnoetige Animationen vermeiden.
Manchmal kommt es sogar vor, das man eine Animierte Textur ausprobiert und dann evtl. doch verwirft und sie lediglich mit ZERO Werten im Script stoppt.
Wenn man dann vergisst den Animationsbefehl auf FALSE zu setzen sieht man es zwar nicht und die Textur bewegt sich augenscheinlich auch nicht, wird im Viewer trotzdem als Animierte Textur erfasst. Was der Viewer dann damit anstellt weiss ich nicht, aber wenn es schon abgeschaltet ist, sollte man es auch richtig machen und nicht unnoetig Resourcen verbrauchen.

Das wars erst einmal fuer heute.
Ich hoffe einigen geht jetzt ein Licht auf.

LG
Dae


reifen vergleich.jpg LOD nah & weit.jpg Lichtquelle2.jpg Particle2.jpg Textur-Animation.jpg
 
Zuletzt bearbeitet:
Auf dem naechsten Bild moechte ich euch ein kleines Beispiel zeigen wie sich der LOD Faktor auswirkt.
attachment.php

Hier seht ihr 2x die selbe Szene aus der selben Blickrichtung. Links im bild war meine Cam etwa 15 Meter entfernt, rechts im Bild habe ich bis auf 2 Meter heran gezoomt.
Gerade mal lumpige 15 Meter entfernt, und schon ist bei dir alles dermaßen undeutlich? Weia. Ich glaub deine Cam braucht 'ne neue Linse... :shock:
 
Das liegt nicht an meiner Cam, sondern am Snippint tool von Windows.
Der Bildausschnitt ist naemlich nur 255 pixel gross, richtige Screenshots sehen bei mir auch anders aus.

LG
Dae
 
Entlich beim Thema Mesh angekommen, moechte ich auch gleich mit dem LOD Faktor los legen.
Es gibt doch tatsaechlich Pappnasen, die beim Mesh-Upload in allen 4 Detailstufen die Gleichen Werte verwenden, wie in der ersten.
Das sie damit reine Lagschleudern produzieren scheinen sie entweder nicht zu wissen, oder es ist ihnen egal.

Helau und Allaf! Soviel zur Pappnase :)
Wenn man ein kleineres Objekt hat (0,5 m) und für die ersten drei LOD Stufen das gleiche Mesh (mit nur ein paar Dutzend Dreiecken) benutzt, ändert sich der Landimpact nicht gegenüber der Variante, bei der der SL Uploader die LOD Stufen automatisch reduziert. Nur das im letzteren Fall das Objekt in SL schon in kurzer Entfernung wie Müll aussieht.
Wenn sich der Landimpact in beiden Varianten also nicht ändert, wie ist dann der möglicherweise verursachte Lag zu bewerten in den beiden Fällen? Auch identisch? Oder im letzteren Fall günstiger? Immerhin entfällt im ersten Fall ja das Mesh-Switching durch den LOD, was evtl. auch einen positiven Effekt haben kann?
 
(mit nur ein paar Dutzend Dreiecken)

Ihhh Dreiecke ... ich bin ja noch blutige Anfängerin was Mesh betrifft, aber versuche es mal mit Vierecke dann hast Du auch weniger LI und Viewer Lag. Ob sich das auf die LOD auswirkt kann ich nicht beantworten aber das Mesh sollte schon von Überflüssigem bereinigt sein
 
Zuletzt bearbeitet:
Helau und Allaf! Soviel zur Pappnase :)
Wenn man ein kleineres Objekt hat (0,5 m) und für die ersten drei LOD Stufen das gleiche Mesh (mit nur ein paar Dutzend Dreiecken) benutzt, ändert sich der Landimpact nicht gegenüber der Variante, bei der der SL Uploader die LOD Stufen automatisch reduziert. Nur das im letzteren Fall das Objekt in SL schon in kurzer Entfernung wie Müll aussieht.
Wenn sich der Landimpact in beiden Varianten also nicht ändert, wie ist dann der möglicherweise verursachte Lag zu bewerten in den beiden Fällen? Auch identisch? Oder im letzteren Fall günstiger? Immerhin entfällt im ersten Fall ja das Mesh-Switching durch den LOD, was evtl. auch einen positiven Effekt haben kann?

Noe !
Lach .. das war die kurze Antwort, nun kommt die lange.
Wie immer ist die Aussage hier "Kommt drauf an"

Das Problem besteht hauptsächlich in den Lade- und Verarbeitungszeiten des Objektes wenn es in Sichweite gerät.
Zudem auch noch in den Ladezeiten für die Textur, was oben ja schon einmal angesprochen wurde.

Heutige Grafikkarten sind eigentlich in der lage UNMENGEN von Dreiecken ( Tris ) darzustellen was auch generell gesehen keinerlei Probleme macht.
Hier haben wir es aber mit gestreamten Daten zu tun, so das die Dateigröße sowie die Anzahl der Dateien an sich eine immer bedeutendere Rolle spielt.
Hier zählt halt jedes Byte. Je größer die Datei desto länger dauert der Downstream. Jehr mehr Dateien zu streamen sind, desto mehr Anfragen auf den Asset Server
und desto mehr parallel laufende Downloads werden in den Downstream zum lokalen Rechner eingeflochten.

Grob gesagt, je dicker das Mesh ( mehr Flächen, mehrere UV-Maps ) desto dicker die Datei desto mehr Downloadbandbreite wird vom Stream in anspruch genommen.
Im Moment erscheint es dann wie ein Wiederspruch, wenn man sagt, man solle die LOD als einzelne Dateien hochladen, was ja das Downloadvolumen dann erhöht!

Hier kommen wir zu Punkt 2 Rendering und Geschwindigkeit. Der Uploader packt, wenn wir ein mesh hochladen, alle 4 LOD Stufen zu einer Datei zusammen.
Also werden aus den 4 Dateien die wir angeben eine einzige gemacht, die komplett heruntergeladen wird. Und hier haben wir schon den Knackpunkt.
Geben wir bei LOD 1-4 Immer die gleiche Datei an, wird sie auch 4x verwendet, und nicht nur 1x wie man das annehmen sollte.

Geschwindigkeit.
Das umswitchen von LODs ist eigentlich keine große sache und kostet kaum zeit. Ausser in Open GL -- UHPS!
Nunja auch das ist eigentlich nicht dramatisch. Was allerdings Dramatisch ist, ist die Schiere Masse an dingen die wir herunterladen müssen und die Anzahl der Texturen,
die immer noch den Speicher der Grafikkarte sehr rasch füllen, so das es sehr schnell zum "swapping" kommt, bei dem die Daten von der Grafikkarte auf das RAM und danach auf die Festplatte und zurück verschoben werden.
Dieser Vorgang kostet, gemessen an allem anderen, eine extrem lange Zeitspanne.
Das ist auch nicht verwunderlich, wenn wir uns ansehen welche Datemengen denn da zu bewältigen sind.
Datenmengen bei Texturen die das Volumen purer übertragener Bits und Bytes berechnen sind für alle Formate Universell, Wenn ein Format verwendet wird, das keine Kompression beinhaltet.
Das wäre dann einfach die Formel Höhe x Breite x ( Farbtiefe + Alphakanal )
So haben wir für eine Standart 512x 512 Textur mit 8 Bit Farbtiefe und keinem Alphakanal eine rohe Datenmenge von
512 x 512 x 8= 2.097.152 Bits, oder verständlicher ausgedrückt 265.77 Kilobyte. ( Tga unkompressed ) Als 24 Bit Datei gespeichert ( Was bei TGA häufig vorkommt, da Photoshop das vorgibt )
wären es also schon 6.291.456 Bit ! Oder zu ende gerechnet zu einer Datei von 768 KB. ( Um das kurz zu machen eine 24Bit TGA von 1024x1024 umfasst ziemlich genau 3 Megabyte )
Diese wird zu einer JPG2000 gewandelt. Das stimmt, doch die meisten gehen mittlerweile dazu über, den Haken bei Lossless Compression beim upload der Textur gar nicht mehr wegzumachen,
so das die VOLLE größe auf den Asset Server gespielt wird.

Unkromrimiert steigt die Datengröße der Texturen überproportional an und damit auch die Speicherbelegung der Textur im Grafikkartenspeicher.
Mann kann sich ja mal hinstellen, wer ne eigene Sim hat und anfangen zu zählen was denn da so an Texturen herumschwirrt, spätestens nach 2 Minuten schwirrt dann der Schädel auch ^^

Das reine Prozessing , also Zeit, in der die Daten in sichbare Bilder oder Formen umgewandelt werden ist dagegen absolut zu vernachlässigen. Einfach ein Witz.

LOD - Stufen bei Meshes verringern die zu ladende Datenmenge insgesamt, Sparsamer Einsatz von Texturen noch viel mehr.
Ältere und langsamere Rechner ( Also GANZ ALTE ) sind auch Dankbar wenn die LOD stufen angepasst sind und die ganz alten Grafikkarte sind auch dankbar, wenn weniger Kilotris zu berechnen sind.
Zum Beispiel eine 65€ teure GeForce GTS 450 misst ihre Berechnungen in Mtris/sec ( Millionen tris pro sekunde ) und hat dabei einen Wert von 783. Also 783 Millionen Triangles pro sekunde.
Und kann intern mit 98 Gigabyte pro sekunde Daten verschieben. Mehr als ausreichend!
Selbst ältere Modelle von 2006 an aufwärts sollten hier keinerlei Probleme bei der Verarbeitung haben.

Das schiere Volumen der zu streamenden Daten ist das Problem. Und da sind alle gefragt die hier eigenes entwerfen und hochladen.
Dem Endkunden ists eigentlich egal, er will nur das es realistisch und gut ausschaut. Technische Probleme sind ihm erstmal vollkommen egal.
Apelle sind da hoffnungslos, die meisten achten nicht mal ansatzweise darauf was in dem Produkt drin steckt, es muss nur gut aussehen und möglichst Kostenlos sein.

Nun damit kommen wir zum Aspekt der Ästhetik.
Selbstverständlich muss ein Ästetischer anspruch berüksichtigt werden. Es bringt gar nichts, wenn alles nur noch in verwaschenen / unschafen Texturen unterwegs ist.
Das wäre Unsinn, aber Daemonika hat ja auch schon recht treffende Beispiele gezeigt ( das mit der Kiste war sehr gut ) bei denen man sieht, worauf es ankommt.

Um z.B. zu den kleinen Gegenständen zu kommen.
Ab einer gewissen Entfernung ist es vollkommen egal, was man da sieht, der Gegenstand ist auf dem Monitor so klein, das es eh keine rolle mehr spielt. Er ist dann
gar nicht mehr zu erkennen. Ein dunkler Punkt bleibt ein dunkler Punkt.....

Auch muss man überlegen wo denn der Gegenstand eingesetzt wird, wenns sich um einen Teller handelt, so liegt der mneistens innerhalb eines Hauses.
Da machts wenig Sinn das mann ihn nach 20m noch sehen kann.. Er wäre dann zu 99% sowieso hinter einer Haus- oder Zimmerwand verborgen.

Ein Ring muss auch nicht nach 10m noch zu sehen sein, den sieht eh keiner auf die Entfernung. Totaler Unsinn, das er da noch mit Höchstdetails angezeigt wird.
Alles was ein Betrachter aus der Entfernung sieht, ist ein maximal 5 Pixel breiter Farbstreifen.
Dasselbe muss man sich bei Sofas - Tischen und anderem Gerät für die eigenen 4 Wände fragen. Ab welcher Entfernung bekomme ich das Ding denn zu Gesicht?
Auf 100m wird auch die größte Couch zu einem bedeutungslosen Farbklecks auf dem Monitor.
Ab 30m bin ich ausserhalb des Zimmers ( wobei 30m große Zimmer schon ein Kracher sind )

Alles das sollte mit einfliessen, wenn man sich daran macht, Meshs zu entwerfen und LOD Stufen zu planen.


Ach und nochwas ...
Am ende wird ALLES zu Dreiecken ^^
Der Exporter verwandelt alle Quads ( Vierecke ) in Tris ( Dreiecke ) und das ist auch gut so.
Der Importer von SL verwandelt diese sonst in einer Vorstufe selbst in Dreiecke, dies kann man im Vorschaufenster des Uploaders sehen, wenn man dort die Drahtgitterdarstellung aktiviert.
 
Zuletzt bearbeitet:
Noe !
Lach .. das war die kurze Antwort, nun kommt die lange.
Wie immer ist die Aussage hier "Kommt drauf an"

Wow, die Antwort ist wirklich ausführlich! Vielen Dank. Werde mir das noch mit mehr Ruhe zu Gemüte führen.

Noch was zu den Texturen: Ich packe ja gerne von einem Objekt (das z.B. aus 4 Meshes besteht) alles in eine einzelne Textur. Die wäre z.B. 1024x1024. Ich könnte versuchen, alles in 4 Texturen a 512x512 zu packen. Wäre das besser?

Noch ein Nachtrag: Für so eine Holzkiste aus Daemonikas Beispiel würde ich auch keine 1024x1024 Textur verwenden. Man sieht ja selbst bei der riesen Textur, dass sich die Holzmuster wiederholen. Da wurde der Texturplatz aber total verschwendet. Das kann man bei so einer großen Textur nun wirklich besser machen. Selbst mit einer kleineren Textur (es genügt wahrscheinlich ein einziges Brett von sagen wir 512x128 ) kann man durch Verschieben der UV-Bereiche der einzelnen Bretter deutlich mehr Abwechselung erzielen, so dass kaum Wiederholungen zu sehen sind.
 
Zuletzt bearbeitet:
Wow, die Antwort ist wirklich ausführlich! Vielen Dank. Werde mir das noch mit mehr Ruhe zu Gemüte führen.

Noch was zu den Texturen: Ich packe ja gerne von einem Objekt (das z.B. aus 4 Meshes besteht) alles in eine einzelne Textur. Die wäre z.B. 1024x1024. Ich könnte versuchen, alles in 4 Texturen a 512x512 zu packen. Wäre das besser?

Hmm schauen wir mal 4x 768 KB = 3072 KB

Bleibt sich also wurst ^^

ABER 4 Assetserveranfragen im Gegensatz zu einer ( oder auch 4 Parallele Downloads im Gegensatz zu einem ).. in dem Fall wäre die 1024er Variante vorzuziehen. Soweit die Flächen bzw das Objekt auch wirklich eine solche größe benötigen, um gut auszusehen
 
Dain, du sagtest dem Endverbraucher ist es eigentlich egal was dahinter steckt, solange es gut aussieht.
Stimmt, viele machen sich kaum gedanken darum, aber ueber LAG meckern koennen sie alle. Dabei haben es gerade die Endverbraucher in der Hand, die Content Creator zum ueberdenken ihrer Kreationen zu zwingen, indem sie es einfach im Laden haengen lassen.

In einem anderen Thread wurde mal bemaengelt, das Second Life in sachen Content Creation zu "professionell" geworden sei, nun ja, von jemanden der auf dem Marketplace verkaufen und gegebenenfalls richtiges Geld damit verdienen will, kann man ein gewisses Mass an Professionalitaet erwarten.

Meine oben genannten Beispiele sollen jetzt keine Hexenjagt ausloesen, sondern nur ein wenig aufklaeren.
Jedes Beispiel fuer sich macht erst ein mal keinen LAG, nicht mal wenn alle Beispiele auf einmal zusammen kommen.
Ich habe immer gesagt, LAG ist die Summe des Ganzen und bedeutet, LAG entsteht dann, wenn es einfach zu viel wird.
Mit anderen worten, eine Lichtquelle macht rein gar nichts aus, Lichtquellen an jeder erdenklichen Ecke, bremsen die Rechenleistung gewaltig bis hin zu Standbildern und sogar Viewercrash.

Irgend wo in einem aelteren Thread habe ich mal erwaehnt, dass ich keine Bauwerke und Moebel und sonstige groesseren Produkte auf dem Marketplace kaufe, wenn der Shopinhaber keinen Inworld Store hat. Viele haben mich deswegen belaechelt. Dass ich mir Inworld aber die Produkte mit den Meta-Daten ansehe um herauszufinden ob sie am ende nicht doch dazu beitragen, dass es bei mir laggt, haben kaum welche verstanden.

Und genau da sind die Endverbraucher gefragt.
Geht einfach Inworld in die Shops und schaut eich die Meta-Daten an. Dann entscheidet, ob ihr es kauft oder auch nicht.
Die groesse der Texturen kann man fuer jede Flaeche einzeln abfragen.
Ich kann euch nur sagen wie das im Cool VL Viewer geht, da ich mich mit den anderen nicht so sehr beschaeftige.
Zuerst oeffne ich das Baumenue und waehle Flaeche waehlen und klick die entsprechende Flaeche an, dann druecke ich die Tastenkombination Strg + Alt + Shift + T und erhalte im chat folgende Meldung:
[07:56:43] Texture info for primitive "Object" (UUID: b9a2af33-bdaa-762e-ab15-0a4d77258acd):
[07:56:43] 89556747-24cb-43ed-920b-47caed15465f 512x512 opaque on face 0
Die UUID der Texturen erhaelt man nur von eigenen Fullperm Objecten, aber die Groesse der Textur steht immer dort.

Wie man das in den anderen Viewern macht, wird hier bestimmt noch jemand erklaeren.

LG
Dae
 
Dain, du sagtest dem Endverbraucher ist es eigentlich egal was dahinter steckt, solange es gut aussieht.
Stimmt, viele machen sich kaum gedanken darum, aber ueber LAG meckern koennen sie alle. Dabei haben es gerade die Endverbraucher in der Hand, die Content Creator zum ueberdenken ihrer Kreationen zu zwingen, indem sie es einfach im Laden haengen lassen.

In einem anderen Thread wurde mal bemaengelt, das Second Life in sachen Content Creation zu "professionell" geworden sei, nun ja, von jemanden der auf dem Marketplace verkaufen und gegebenenfalls richtiges Geld damit verdienen will, kann man ein gewisses Mass an Professionalitaet erwarten.

Meine oben genannten Beispiele sollen jetzt keine Hexenjagt ausloesen, sondern nur ein wenig aufklaeren.
Jedes Beispiel fuer sich macht erst ein mal keinen LAG, nicht mal wenn alle Beispiele auf einmal zusammen kommen.
Ich habe immer gesagt, LAG ist die Summe des Ganzen und bedeutet, LAG entsteht dann, wenn es einfach zu viel wird.
Mit anderen worten, eine Lichtquelle macht rein gar nichts aus, Lichtquellen an jeder erdenklichen Ecke, bremsen die Rechenleistung gewaltig bis hin zu Standbildern und sogar Viewercrash.

Irgend wo in einem aelteren Thread habe ich mal erwaehnt, dass ich keine Bauwerke und Moebel und sonstige groesseren Produkte auf dem Marketplace kaufe, wenn der Shopinhaber keinen Inworld Store hat. Viele haben mich deswegen belaechelt. Dass ich mir Inworld aber die Produkte mit den Meta-Daten ansehe um herauszufinden ob sie am ende nicht doch dazu beitragen, dass es bei mir laggt, haben kaum welche verstanden.

Und genau da sind die Endverbraucher gefragt.
Geht einfach Inworld in die Shops und schaut eich die Meta-Daten an. Dann entscheidet, ob ihr es kauft oder auch nicht.
Die groesse der Texturen kann man fuer jede Flaeche einzeln abfragen.
Ich kann euch nur sagen wie das im Cool VL Viewer geht, da ich mich mit den anderen nicht so sehr beschaeftige.
Zuerst oeffne ich das Baumenue und waehle Flaeche waehlen und klick die entsprechende Flaeche an, dann druecke ich die Tastenkombination Strg + Alt + Shift + T und erhalte im chat folgende Meldung:

Die UUID der Texturen erhaelt man nur von eigenen Fullperm Objecten, aber die Groesse der Textur steht immer dort.

Wie man das in den anderen Viewern macht, wird hier bestimmt noch jemand erklaeren.

LG
Dae


Soweit einverstanden. Ich kann mir allerdings keine SIM leisten oder auch nur eine halbe um mal eben alles auszustellen.
Naja .. ich produiziere auch Hauptsächlich für bestimmte Läden und Shops.

Also nicht soooo drastisch.
Aber vom Prinzip her hast du natürlich recht.
Im Develop Menue stehen allerhand gute Tools bereit um sich Informationen über seine Umgebung zu verschaffen.
Der Interessierte sollte sich ruhig einmal damit ausgiebig beschäftigen.
 
Stimmt, das ist in dem Fall ein gewaltiges Problem.
Jemand der lediglich eine Parzelle besitzt, hat quasi 0 Chance die Region entsprechend zu optimieren, um die Viewer-Leistung zu erhoehen.
Selbst wenn jemand auf seiner Parzelle alles optimal eingerichtet hat, machen es ihm die Nachbarn sofort zu nichte, wenn sie sich innerhalb der eingestellten Sichtweite befinden.

Nachtrag: OK, jemand der mit 256 Metern und mehr Sichtweite herum rennt ist selber schuld und brauch von mir kein Mitleid erwarten, wenn es laggt.

LG
Dae
 
Zuletzt bearbeitet:
Sichtweite

Immer wieder bekomme ich mit, dass viele eine sehr hohe Sichtweite eingestellt haben.
Auf den folgenden beiden Bildern, die ich allerdings wegen ihrer groesse auf ImageShack hochgeladen habe, koennt ihr sehen, wie sich die Sichtweite auswirkt.
ImageShack Album - 2 images

Auf den Bildern koennt ihr sehr gut sehen, wie ich einfach mal alles was ich sehe mit dem Baumenue eingefangen habe.
Das linke Bild ist mit einer Sichtweite von 128 Metern aufgenommen und im Baumenue sind 1545 Prims markiert.
Bei dem rechten Bild habe ich die Sichtweite auf 256 Meter erhoeht und wieder alles mit dem Baumenue markiert, diesmal umfasst das Baumenue aus dem selben Blickwinkel ploetzlich 2285 Prims.

Da soll noch mal einer behaupten, es wuerde nicht alles dargestellt, was man hinter Waenden nicht sieht (auf das Thema Model-Show anspiel) ;).
Natuerlich wird das alles eingefangen, ja auch die entsprechenden Texturen und es spielt keine Rolle ob da ein Prim dazwischen ist.

Wenn ich jetzt auch noch einen uebertriebenen RenderVolumeLODFactor (alles ueber 3.000 ist Schwachsinn) in den Debug Settings eingestellt haette, wuerden mir auch saemtliche versteckten kleinen Objecte hinter den Mauern vollstaendig dargestellt, obwohl sie eigentlich zerfallen sollten. Also LAG Pur.

Auf den beiden Bildern kann man es nicht gut erkennen, aber das erhoehen der Sichtweite hat mir lediglich eine einzige Tanne ganz hinten im Hintergrund gebracht. Alles andere auf den Bildern blieb unveraendert, eben weil es hinter anderen Objecten versteckt ist. Waere ich auf den Bildern weiter vor gegangen um mehr von der Umgebung rund herum zu sehen, koennte ich mir eine Sichtweite von 256 Metern sofort wieder sparen, weil eine Sichtweite von 128 Metern aus der Region-Mitte voellig reicht, um die ganze Region zu ueberblicken, eben weil es von dort aus in Richtung Osten, Westen, Norden und Sueden nur 128 Meter bis zum Rand der Region ist.

Wenn ich einen Club besuche, drehe ich grundsaetzlich die Sichtweite auf 64 Meter runter, damit mir die Umgebung ausserhalb des Clubs, nicht unnoetig in die Grafikkarte geladen wird, schliesslich interessieren mich in dem Moment ausschliesslich die Avatare mit denen ich mich unterhalte.

LG
Dae
 
Zuletzt bearbeitet:
Datenmengen bei Texturen die das Volumen purer übertragener Bits und Bytes berechnen sind für alle Formate Universell, Wenn ein Format verwendet wird, das keine Kompression beinhaltet.
Das wäre dann einfach die Formel Höhe x Breite x ( Farbtiefe + Alphakanal )
So haben wir für eine Standart 512x 512 Textur mit 8 Bit Farbtiefe und keinem Alphakanal eine rohe Datenmenge von
512 x 512 x 8= 2.097.152 Bits, oder verständlicher ausgedrückt 265.77 Kilobyte. ( Tga unkompressed ) Als 24 Bit Datei gespeichert ( Was bei TGA häufig vorkommt, da Photoshop das vorgibt )
wären es also schon 6.291.456 Bit ! Oder zu ende gerechnet zu einer Datei von 768 KB. ( Um das kurz zu machen eine 24Bit TGA von 1024x1024 umfasst ziemlich genau 3 Megabyte )

Da möchte ich mal einlenken: In deiner Formel 512 x 515 x 8 fehlt noch der Faktor 3, nämlich für die drei Farbkanäle. Die Formel müsste so lauten: Höhe x Breite x Farbbittiefe x (Farbkanäle + Alphakanal ). Du berücksichtigst im ersten Satz nur einen Kanal, was einem Graustufenbild entspricht. Dein Satz „Als 24 Bit Datei gespeichert ( Was bei TGA häufig vorkommt, da Photoshop das vorgibt )„ könnte so gelesen werden, als wäre das TGA Format irgendwie „schlecht“ oder „schuld“. Man speichert aber nahezu immer mindestens in 24 Bit (normale Farbbilder mit 3 Farbkanälen x 8 Bit). Wenn man zusätzlich noch einen Alphakanal für Transparenz nutzt, sind es 32 Bit (also 4 Kanäle x 8 Bit).


Diese wird zu einer JPG2000 gewandelt. Das stimmt, doch die meisten gehen mittlerweile dazu über, den Haken bei Lossless Compression beim upload der Textur gar nicht mehr wegzumachen,
so das die VOLLE größe auf den Asset Server gespielt wird.

Und nun zu lossless compression (verlustfreie Kompression): Ich rede jetzt nur vom Firestorm, bei anderen Viewern kenne ich das nicht. Der Haken bei lossless compression im Upload Dialog ist bei großen Texturen immer grau, immer gesetzt und kann nicht verändert werden. Erst bei Texturen von 128 x 128 oder kleiner ist der Haken frei einstellbar. Aber das ist alles kein Problem. Denn: Diese Hakenanzeige in Firestorm bei großen Texturen ist Mumpitz. Was ich gelesen habe im Firestorm Jira ist, dass SL bei größeren Texturen generell verlustbehaftet komprimiert, egal, was man ggf. irgendwo einstellen kann. Im Firestorm kann man da, wie schon gesagt, sowieso nichts einstellen. Dumm ist eben, dass bei einer großen Textur der Haken (wenn auch grau und inaktiv) in Firestorm sichtbar ist, das gibt ein falsches Bild dessen, was wirklich passiert. Ich schließe daraus: Alle Texturen größer 128 x 128 werden immer verlustbehaftet komprimiert, ohne das der Anwender was daran ändern kann. Gut so :) Und bei den kleineren Texturen sollte man die lossless compression eingeschaltet lassen, wenn es sich um Sculpt-Maps handelt. Sonst könnten die Sculpties ziemlich schrottig aussehen.


Unkromrimiert steigt die Datengröße der Texturen überproportional an und damit auch die Speicherbelegung der Textur im Grafikkartenspeicher.

Nur so als Randbemerkung/Ergänzung: Im Grafikkartenspeicher können meines Wissens keine komprimierten Texturen wie JPG liegen bzw. die Grafikkarte komprimiert die selbst z.B. im Format S3TC. D.h., das Komprimieren von Texturen nützt bei der Datenspeicherung auf den SL-Servern den Platz zu sparen, klar, im Grafikkartenspeicher aber hat eine von mir gewählte Kompression keinen Einfluss, was da passiert. Da ist es egal, wie ich (oder SL) die Textur gespeichert hat. Mein einziger persönlicher Einfluss auf den Grafikkartenspeicher ist der, die Pixelgröße der Textur weise zu wählen, wie Du ja auch schon ausführlich beschrieben hast.

Das sind nur freundliche Anmerkungen. Sollte ich was falsch verstanden oder falsch beschrieben haben, bitte korrigieren. :)
 
Da möchte ich mal einlenken: In deiner Formel 512 x 515 x 8 fehlt noch der Faktor 3, nämlich für die drei Farbkanäle. Die Formel müsste so lauten: Höhe x Breite x Farbbittiefe x (Farbkanäle + Alphakanal ). Du berücksichtigst im ersten Satz nur einen Kanal, was einem Graustufenbild entspricht. Dein Satz „Als 24 Bit Datei gespeichert ( Was bei TGA häufig vorkommt, da Photoshop das vorgibt )„ könnte so gelesen werden, als wäre das TGA Format irgendwie „schlecht“ oder „schuld“. Man speichert aber nahezu immer mindestens in 24 Bit (normale Farbbilder mit 3 Farbkanälen x 8 Bit). Wenn man zusätzlich noch einen Alphakanal für Transparenz nutzt, sind es 32 Bit (also 4 Kanäle x 8 Bit).

Nicht schlecht oder Schuld, an dieser stelle ging es rein um eine Technische Beschreibung und nicht um eine Bewertung ^^
Na gut .. wahrscheinlich ist die Formulierung noch Optimierungsbedürftig, man könnte dies Missverstehen, ja


Und nun zu lossless compression (verlustfreie Kompression): Ich rede jetzt nur vom Firestorm, bei anderen Viewern kenne ich das nicht. Der Haken bei lossless compression im Upload Dialog ist bei großen Texturen immer grau, immer gesetzt und kann nicht verändert werden. Erst bei Texturen von 128 x 128 oder kleiner ist der Haken frei einstellbar. Aber das ist alles kein Problem. Denn: Diese Hakenanzeige in Firestorm bei großen Texturen ist Mumpitz. Was ich gelesen habe im Firestorm Jira ist, dass SL bei größeren Texturen generell verlustbehaftet komprimiert, egal, was man ggf. irgendwo einstellen kann. Im Firestorm kann man da, wie schon gesagt, sowieso nichts einstellen. Dumm ist eben, dass bei einer großen Textur der Haken (wenn auch grau und inaktiv) in Firestorm sichtbar ist, das gibt ein falsches Bild dessen, was wirklich passiert. Ich schließe daraus: Alle Texturen größer 128 x 128 werden immer verlustbehaftet komprimiert, ohne das der Anwender was daran ändern kann. Gut so :) Und bei den kleineren Texturen sollte man die lossless compression eingeschaltet lassen, wenn es sich um Sculpt-Maps handelt. Sonst könnten die Sculpties ziemlich schrottig aussehen.
Aha .. nun im grunde ändert das nichts, in dem Falle müssen die Daten ja in der Gafikkarte umcodiert werden. Der Grundsatz bleibt aber und ist auch universell. Mehr Daten mehr Verarbeitungszeit. Aber wie auch schon im text angemerkt, diese Art der verarbeitung ist vernachlässigbar. Das Volumen ist wichtig.
Bliebe eventuell auszutesten, wie stark der Komprimierungsfaktor ist. Dann könnte man auch eine statitische Hochrechnung über das tatsächliche Volumen machen.
Ehrlich gesagt, soweit geht mein Ehrgeitz dann doch nicht ^^

Nur so als Randbemerkung/Ergänzung: Im Grafikkartenspeicher können meines Wissens keine komprimierten Texturen wie JPG liegen bzw. die Grafikkarte komprimiert die selbst z.B. im Format S3TC. D.h., das Komprimieren von Texturen nützt bei der Datenspeicherung auf den SL-Servern den Platz zu sparen, klar, im Grafikkartenspeicher aber hat eine von mir gewählte Kompression keinen Einfluss, was da passiert. Da ist es egal, wie ich (oder SL) die Textur gespeichert hat. Mein einziger persönlicher Einfluss auf den Grafikkartenspeicher ist der, die Pixelgröße der Textur weise zu wählen, wie Du ja auch schon ausführlich beschrieben hast.

Das ist korrekt und genau das worauf ich hinaus wollte. Das Beispiel wurde mit unkomprimierten Dateien angegeben um eine gesicherte Berechnungsbasis zu haben. Da mir die Kompressionsrate in % unbekannt ist, konnte ich nicht einfach was hernehmen. Allerdings wird das Verhältniss gleich bleiben. Eine Datei in 1024x1024 ist immer 4 mal so groß wie eine 512x512 das trifft auch dann zu wenn die Daten komprimiert vorliegen. Die Kompressionsrate bleibt ja auch konstant. Expliziet, um das hier nochmal anzumerken, bezog sich das ganze auf den Kistenvergleich von Daemonica. Die kleinere Textur ist nicht schlechter als die große, ist aber um den Faktor 4 kleiner im Datenvolumen.


Das sind nur freundliche Anmerkungen. Sollte ich was falsch verstanden oder falsch beschrieben haben, bitte korrigieren. :)

Danke schön :) War schon gut angemerkt das ganze :)
 

Users who are viewing this thread

Zurück
Oben Unten