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

Lag durch Meshes - Wahr, falsch oder was ist dran?

2.8. Lag

Warum legt uns das böse LindenLab so schwere Beschränkungen auf mit Hilfe des Land-Impact?

Nun, wir alle stöhnen über Lag, also sollten wir uns bemühen nicht selber Lag zu erzeugen. Die 3 Elemente des Land-Impact sollen uns das bewußt machen. Also lest dieses Kapitel mit meinem Halbwissen als lockere Unterhaltung für den „Hinterkopf“ um das zweite Leben ein Stückchen besser zu verstehen.

Der Download-Impact: Wer ärgert sich nicht darüber, ewig dazustehen, graue „Texturen“ und eiförmige Sculpty-Objekte zu sehen und darauf zu warten dass eine Textur, ein Sculpty oder eben ein Mesh endlich richtig sichtbar ist? Männer freuts, denn es gibt Mesh-gekleidete Damen massenweise nackicht zu sehen ;) Meshes haben hier Ihre Hauptschwäche, für jeden Vertice eines Meshes (und seiner Physics) müssen die 3 Fließkommazahlen für seine X- Y- und Z-Positionen vom Server zum Viewer übertragen werden (ein Sculpty begnügt sich mit einem einzigen niedrigen Festkomma-Wert, den wir als Farbpunkt der Sculpty-Map sehen). Bei einigen tausend Vertices kommt da schon eine Menge an Daten zusammen – hunderte Kilobytes pro Mesh-Objekt (ein Sculpty braucht 68KB, eine 512-Pixel-Grafik im Schnitt 50KB). Dazu kommen noch die Informationen für Edges und Faces. Wer ein Gefühl für die Datenmenge eines einzigen Meshes bekommen will, schaut sich einfach einmal die Größe der Collada-Dateien (.dae) seiner Meshes an - . Und das muss eben im Prinzip alles durch eine dünne Leitung vom Server zum Viewer gequetscht werden ;) Hier auch die große Bitte an die Kleider-Hersteller: Seid nicht so stinkfaul, gute Form durch Highpoly-Mehes zu erzeugen, weil es ja keine Land-Prims kostet - unser aller Download- und Viewer-Lag wird es Euch danken (rezzt mal eure Kleider-Demos vor dem Kauf) !

Der Physics-Impact: Ein großer Teil der Serverzeit geht beim Berechnen der Kollisionen drauf. Dazu ist um jedes Objekt eine „Bounding-Box“ gelegt, die bei Meshes aus dem Physics-Objekt berechnet wird und sich beim Verformen des Meshes bei Kleidern ständig ändern kann. Kollisionen werden berechnet zwischen den „Bounding Boxes“ der Objekte und der Avatare, aber auch zwischen denen der Objekte untereinander – wer das mal „Live sehen will“, der schaltet das Entwicklermenü mit Strg-Alt-D ein und wählt aus Entwickler > Metadaten darstellen > Bounding Boxes – zu sehen sind dann auch die vielen Kästchen um unsere Prim-Anhängsel. Besonders schlimm wird es bei Objekten, die als „physisch“ gekennzeichnet werden – deshalb ist es ein beliebtes Instrument von Griefern, die eine Sim lahmlegen wollen hunderte physische Objekte zu erzeugen (man braucht sie nur in wenigen Fällen und nur zeitweise wie zum Beispiel in sich gerade bewegenden Fahrzeugen und Viechern). Je komplizierter die Physics geformt ist, desto umfangreicher werden auch die Berechnungen. Ein Avatar hat deshalb einfach einen rechteckigen Quader als Bounding-Box und das ist auch, was wir selbst als Physics anstreben sollten (Mesh-Haare schneiden da übrigens deutlich besser ab als die Hunderte von Sculpties und Flexies anderer Haare). Beim Hochladen kann man zwar die Bounding-Box eines Meshes optimieren lassen, aber so richtig optimal wird das nie. Eine gute Idee ist dann noch, Unterprims eines zusammengesetzten Objekts im Bauen > Eigenschaften auf „Physische Form“ = „Keine“ zu setzen, da spart man sich die Bounding-Boxen dann ganz und senkt meist die Anzahl Prims.

Server-Impact: Lag, Lag, Lag – Mist-Sim! Um eine Sim so richtig laggy zu machen, brauchen wir nicht unbedingt viele Avatare mit angehängtem Lametta und tausenden Schuh-Resize-Scripten. Wir Scripter können eine Sim auch ganz ohne Avatare lahmlegen. Eine mögliche Ursache für Server-Lag sind Skripte (zum Beispiel Sitzskripte in Posebällen, automatische Türen, Sicherheits-Kugeln, ...) und ihre oft miserable Programmierung. Besonders schlimm sind Skripte, die auf den Chat in Kanal 0 hören oder mit einem Sensor alle Sekunde die Avas in 95 Metern Umkreis erfassen (Tanzbälle machen das oft, was mittlerweile überflüssig ist) oder die ständig aktiv sind um in einer Schleife irgendeinen Animations-Blödsinn zu machen (zum Beispiel Viecher herumlaufen zu lassen). Aber die Verwaltung jedes einzelnen Objekts erzeugt auch eine gewisse Grundlast auf dem Server, weshalb der Server-Impact immer mindestens 0.5 beträgt – deshalb hat ein Mesh-Objekt immer mindestens einen LI von 0.5.
 
Ich dachte wir haetten diesen Mythos "Lag durch Meshes" endgültig aus der Welt geschafft.
Aber sowas scheint sich ja wirklich bis in alle ewigkeit zu halten.
Naja .. ich gebs auf dagegen anzureden.
 
Ich dachte wir haetten diesen Mythos "Lag durch Meshes" endgültig aus der Welt geschafft.
Aber sowas scheint sich ja wirklich bis in alle ewigkeit zu halten.
Naja .. ich gebs auf dagegen anzureden.

Falsch gedacht.
Wie bei allem anderen auch, koennen auch Meshes LAG (Viewer-LAG) verursachen, wenn es einfach zu viel ist.
Schliesslich sind nicht ausnahmslos alle Mesh gut gemacht, es gibt jetzt schon jede menge Scheisse auf dem Grid, wofuer der Ersteller aus SL verbannt gehoert.

LG
Dae
 
Ich dachte wir haetten diesen Mythos "Lag durch Meshes" endgültig aus der Welt geschafft.
Aber sowas scheint sich ja wirklich bis in alle ewigkeit zu halten.
Naja .. ich gebs auf dagegen anzureden.

"Normale" Meshes machen weniger Probleme als Sculpties. Weil sie oft sogar weniger Dreiecke haben. Das stimmt. Aber Meshes können durchaus massive Probleme machen, wo das mit normalen Prims & Sculpts eben nicht geht:

Wenn das Mesh File (z.B. wegen vielen zu großen Texturen in der Datei) eben zu groß ist (man kann bis 8MB dae Files hochladen AFAIK), dann dauert es manchmal eben ziemlich lange, bis es runtergeladen ist, vor allem, wenn da noch viele andere Meshes geladen werden müssen. Schafft es der Viewer dann in 30s nicht diese Riesen-Datei zu laden, dann wird der Download mit einem timeout hart abgebrochen. Und nach eine kurzen Wartezeit lädt der Viewer die Datei noch mal komplett ganz von vorn. Schafft es der Viewer auch diesmal nicht in 30s, dann wird das wieder angebrochen - und wieder ganz von vorn geladen usw. Bis es nach vielen versuchen ganz abgebrochen wird oder irgendwann doch in den 30s geladen ist. Ein Mesh-Objekt, das aus 5 gelinkten Objekten mit z.B. je 1MB Downloadgröße besteht ist eben normalerweise so um Welten schneller geladen als ein einzeler 5MB-Download. Obwohl 5 Downloads mehr Overhead haben. Mit vielen zu großen Mesh-Dateien kann man also schon mal den Download selbst eines schnellen Anschlusses dicht machen - denn auch die Bandbreite von SL zum Viewer ist leider begrenzt. Bei Leuten mit kleiner Bandbreite reichen aber schon ein oder 2 Riesen-Dateien um den Download erst mal dicht zu machen, so dass ein Sim eben wirklich ewig braucht um zu laden.


Das andere große Problem sind Meshes mit zu vielen Dreiecken. Viele Mesh-Objekte, die sich in SL tummeln sind überhaupt nicht für SL oder Spiele gemacht, sondern zum Rendern von Filmen oder 3D-Szenen, und diese Objekte haben dann gern mal viel zu viele Dreiecke. Grafikkarten können aber nur eine bestimmte Anzahl von Dreiecken pro Sekunde verarbeiten. Es gibt in SL durchaus einzelne Gebäude, die z.B. für eine einfache Säule eben mal tausende von Dreiecken verbraten, weil da vermutlich irgendwo einfach eine Säule aus dem Internet nach SL importiert wurde. Und noch schlimmer sind Klamotten. Da gibts teilweise Shirts und Hosen, die mehr Dreiecke haben als eine normale Sim mit 15000 Prims. So dass man eben dann, wenn man den damit angezogenen Ava im Sichtfeld hat, eben mal einen Einbruch der FPS um 50% und mehr hat - nur durch diese schlechten Mesh-Objekte.

Das sind beides Bereiche, in denen eben normale Prims und auch Sculpts völlig unproblematisch sind. Aber zu große/nicht für SL geeignete Meshes machen hier oft wirklich Probleme mittlerweile. Die Leute gehen einfach auf irgendwelche Mesh-Repos, laden sich die Dateien als Collada runter und schieben das Ding dann unverändert nach SL, egal ob das Model für Computerspiele, für Animationsfilme oder für 3D-Szenen gemacht wurde. Und weils sie nicht wirklich Ahnung haben und weil es dann von weitem Besser aussieht, da zahlen sie eben bisschen mehr und laden für alle LOD eben hochauflösende Model hoch.

Das ist nicht anders als mit den Leuten, die prinzipiell nur 512er und 1024er Texturen für ihren Kram verwenden "weil das die beste Qualität ist" - egal wie viele Pixel von der Textur man nachher effektiv sieht.
 
"Normale" Meshes machen weniger Probleme als Sculpties. Weil sie oft sogar weniger Dreiecke haben. Das stimmt. Aber Meshes können durchaus massive Probleme machen, wo das mit normalen Prims & Sculpts eben nicht geht:

Wenn das Mesh File (z.B. wegen vielen zu großen Texturen in der Datei) eben zu groß ist (man kann bis 8MB dae Files hochladen AFAIK), dann dauert es manchmal eben ziemlich lange, bis es runtergeladen ist, vor allem, wenn da noch viele andere Meshes geladen werden müssen. Schafft es der Viewer dann in 30s nicht diese Riesen-Datei zu laden, dann wird der Download mit einem timeout hart abgebrochen. Und nach eine kurzen Wartezeit lädt der Viewer die Datei noch mal komplett ganz von vorn. Schafft es der Viewer auch diesmal nicht in 30s, dann wird das wieder angebrochen - und wieder ganz von vorn geladen usw. Bis es nach vielen versuchen ganz abgebrochen wird oder irgendwann doch in den 30s geladen ist. Ein Mesh-Objekt, das aus 5 gelinkten Objekten mit z.B. je 1MB Downloadgröße besteht ist eben normalerweise so um Welten schneller geladen als ein einzeler 5MB-Download. Obwohl 5 Downloads mehr Overhead haben. Mit vielen zu großen Mesh-Dateien kann man also schon mal den Download selbst eines schnellen Anschlusses dicht machen - denn auch die Bandbreite von SL zum Viewer ist leider begrenzt. Bei Leuten mit kleiner Bandbreite reichen aber schon ein oder 2 Riesen-Dateien um den Download erst mal dicht zu machen, so dass ein Sim eben wirklich ewig braucht um zu laden.


Das andere große Problem sind Meshes mit zu vielen Dreiecken. Viele Mesh-Objekte, die sich in SL tummeln sind überhaupt nicht für SL oder Spiele gemacht, sondern zum Rendern von Filmen oder 3D-Szenen, und diese Objekte haben dann gern mal viel zu viele Dreiecke. Grafikkarten können aber nur eine bestimmte Anzahl von Dreiecken pro Sekunde verarbeiten. Es gibt in SL durchaus einzelne Gebäude, die z.B. für eine einfache Säule eben mal tausende von Dreiecken verbraten, weil da vermutlich irgendwo einfach eine Säule aus dem Internet nach SL importiert wurde. Und noch schlimmer sind Klamotten. Da gibts teilweise Shirts und Hosen, die mehr Dreiecke haben als eine normale Sim mit 15000 Prims. So dass man eben dann, wenn man den damit angezogenen Ava im Sichtfeld hat, eben mal einen Einbruch der FPS um 50% und mehr hat - nur durch diese schlechten Mesh-Objekte.

Das sind beides Bereiche, in denen eben normale Prims und auch Sculpts völlig unproblematisch sind. Aber zu große/nicht für SL geeignete Meshes machen hier oft wirklich Probleme mittlerweile. Die Leute gehen einfach auf irgendwelche Mesh-Repos, laden sich die Dateien als Collada runter und schieben das Ding dann unverändert nach SL, egal ob das Model für Computerspiele, für Animationsfilme oder für 3D-Szenen gemacht wurde. Und weils sie nicht wirklich Ahnung haben und weil es dann von weitem Besser aussieht, da zahlen sie eben bisschen mehr und laden für alle LOD eben hochauflösende Model hoch.

Das ist nicht anders als mit den Leuten, die prinzipiell nur 512er und 1024er Texturen für ihren Kram verwenden "weil das die beste Qualität ist" - egal wie viele Pixel von der Textur man nachher effektiv sieht.

Ok .. die ausführungen sind soweit richtig, was haben denn nun, und das ist die essenzfrage, Ladezeiten mit LAG zu tun ?

Aber was red ich denn, wir haben das Thema schon so oft durchgekaut das es vollkommen sinnlos ist, hier noch mehr zu sagen.
 
Ok .. die ausführungen sind soweit richtig, was haben denn nun, und das ist die essenzfrage, Ladezeiten mit LAG zu tun ?

Ich finde das einfach zu verstehen. Es gibt Lag der serverseitig kaum noch existeirt es sei denn irgendwas im System ist gestört und es gibt das an LAG von dennen wohl die meisten reden. Das ist der viewerseitige LAG zu dem der jeweilige Viewer nichts kann sondern der sehr individuell sich bei jedem anders auswirkt.
Die Ursache ist nun mal weniger durchdachte Objekte in SL durch Ersteller, die Internetverbindung an die Westküste der USA und der heimische PC.

Wenn nun ein Mesh welches weniger durchdacht ist gerezzt werden muss dann belastet es das Netzwerk (Internetverbindung) und fordert sehr vil von unserem PC ab das Objekt zu laden bis wir es sehen können. Da wir ja nun nicht nur in der Gegend herumstehen sondern uns bewegen müssen ständig neue Objekte und Texturen gerezzt werden (rendern).

Ich habe mich aus diesem Grunde nun von meiner betagten wenn auch immer noch guten alten 9800GT verabschieden müssen. Durch den mit der Zeit ansteigenden Datenstrom wurde die Grafikkarte zum Nadelöhr und konnte die Informationen nicht mehr schnell genug verarbeiten so das mir nur noch stellenweise 5 bis 15 FPS blieben von eins 20 bis 30.
 
Und? Die frage bleibt, was hat das mit LAG zu tun?

LAG .. also das reine LAG .. nicht den Begriff der immer wieder so selbstverständlich für alles mögliche verwendet wird, hat rein gar nichts damit zu tun.
Worüber hier geredet wird sind Ladezeiten oder waren bei dir eben Bottlenecks ... das hat aber nichts mit LAG zu tun.

Ich verwehre mich halt dagegen, das in solchen Artikeln so expliziet auf den Bösewicht Mesh verwiesen wird, das stinkt nach "Nimm das blos nich, das macht ja LAG" obwohl das purer unsinn ist.
 
Zuletzt bearbeitet:
Sorry .. aber ich bin sehr wohl Informiert was LAG bedeutet.

Aber ich will mich nicht streiten, ihr werded von eurer Meinung sowieso nicht abrücken, wie immer.
Also .. weitermachen ...
 
@ Dain

Natuerlich macht so ein Mesh alleine kein lag, genau so wenig wie ein Film auf Youtube - das macht auch kein lag, bis... jetzt kommts... Trommelwirbel... Spannung steigt... bis man es sich ansieht.

LG
Dae
 
Und? Die frage bleibt, was hat das mit LAG zu tun?
(...)
Ich verwehre mich halt dagegen, das in solchen Artikeln so expliziet auf den Bösewicht Mesh verwiesen wird, das stinkt nach "Nimm das blos nich, das macht ja LAG" obwohl das purer unsinn ist.

Niemand - und ich betone hier nochmal - NIEMAND! behauptet, dass man keine Meshes mehr nehmen soll. Ich habe sogar das Gegenteil geschrieben. Was soll diese Unterstellung also? Ist Mesh jetzt irgendwie heilig?

Fakt: Meshes können aus bis zu 8MB großen Collada-Files bestehen, die dann in ein anderes xml-Format, das LLSD-Format übersetzt werden. Hat man viele große Downloads aus SL - und der SL Viewer macht dabei viele gleichzeitige Verbindungen zum Server, dann ist das Netzwerk für dich erst mal dicht. Deine Pings können auf sehr hohe Werte steigen und man kann sich nicht mehr wirklich richtig in SL bewegen, alles wird Gummiartig, weil die Netzwerk-Pakete für die Bewegung zu lange brauchen oder gar verloren gehen durch timeouts. Dies nennt man für gewöhnlich lag. Netzwerk-Lag.

Teste es selbst aus, packe einen Sim einfach mal voll mit sehr vielen Meshes, die aus riesigen Collada Dateien bestehen. Und wenn du nicht gerade 20 Mbit Internet hast, sondern 4Mbit oder gar nur 1Mbit, dann viel Spass, wenn du mit einem Viewer mit frish geleertem Cache einloggst. Ich sag nur Connection Timeout & Reload & Packet Loss. (BTW: Vor der Mesh-Zeit ging SL sogar mit einer 150kbit Leitung völlig Problemlos, heute geht es eigentlich mit einer 500kbit Leitung problemlos...)

Fakt: Meshes können in SL aus bis zu 2^16 = 65536 Dreiecken bestehen. Eine Hose etwa mit 40 000 Dreiecken hochzuladen ist also technisch überhaupt kein Problem, das geht problemlos. (Zum Vergleich: Ein komplett nackter SL-Avatar hat 7200 Dreiecke...) Das Problem ist dann nur, diese Dreiecke auch anzuzeigen und zu berechenen. Vor allem wenn da noch andere Dreiecke im Sichtbereich gerendert werden müssen. Und wenn da noch Licht + Schattenberechnungen durchgeführt werden müssen.
Dann besteht so ein Ava eben nicht mehr aus z.B. 10000 Dreiecken oder 20 000 Dreiecken (wegen Attachments wie Haaren usw.), sondern eben aus 60 000 Dreiecken. Noch mehr, wenn dann noch komplexe Mesh-Haare dazu kommen. Und genau das kann dann dazu führen, dass die Framerate des Viewers, der das rendern muss, drastisch sinkt. Bis zu einem Bereich, in dem eben es nur noch extrem ruckelt und in dem der Viewer irgendwann (da die Verarbeitung von Netzwerkpaketen direkt von den FPS des Viewers abhängt) auch im Netzwerk-Berreich durchaus udp-Timeouts, Verzögerungen und Packet-loss bekommen kann. Kurz: Lag. Viewer Lag. Und dadurch eben auch bisschen Netzwerk-Lag.

==>> NOCH MAL: NIEMAND will hie deine heiligen Meshes abschaffen. Aber Meshes, die wegen ihrer Größe/Komplexizität nicht für SL geeignet sind, die haben in SL nicht wirklich was verloren. Und wer keine Ahnung davon hat, wie man Meshes für Umgebungen wie SL gestaltet oder zumindest optimiert, der sollte sich bitte schlau machen, am besten bevor er einfach irgendwelche Objekte in den Verkauf bringt.
 
Zuletzt bearbeitet:
Vor kurzem hat sich jemand gewundert und mich gefragt, warum ich so einen aufwand betreibe, selbst fuer Attachments die Veritys so weit wie moeglich zu reduzieren. Meine antwort bestand im Wesentlichen daraus, weil es sonst LAG macht.
Gut, der Land Impact wird bei Attachments zwar nicht berechnet, trotzdem muessen saemtliche Geometriedaten dieses Objects an den Viewer uebertragen werden.
Wie Canis oben schon mal beschrieben hat, wenn ihr wissen wollt ob ein attached Mesh gut oder schlecht ist, rezzt es einfach mal auf dem Boden.
Je mehr Prims es auf dem Land zaehlt, desto hoeher ist die Belastung fuer den Server und Viewer. Welche Durchschnittlichen Werte nun gut bzw. schlecht sind, kann momentan nicht wirklich jemand sagen, das werden uns die Erfahrungen im laufe der Zeit lehren.
Zum jetzigen Zeitpunkt kann man wohl schon sagen, je feiner das Mesh im Bearbeitungsmodus ist, desto mehr unnoetige Dreiecke.

LG
Dae
 
Schoen mit dem Buch. :thumbup Tut not. Vielleicht kann ich dann das auch lernen.

Mit meiner kleinen Bandbreite und dem zwar neuen aber normalen Laptop leide ich zunehmend sehr unter den Nebenwirkungen der falsch gemachten Meshes.

Ich wuenschte, Linden koennte viel strengere Auflagen an die Optimierung stellen.
 
Wieviel "zuviel" ist an Dreiecken, bzw. wie viel Ok ist, kann man glaube ich schwer in Zahlen fassen. Ist eine Mesh Hose mit 5.000 Dreiecken Ok, oder auch noch mit 10.000? Mich ärgert es vor allem, wenn Meshes unnötig viele Flächen haben. Also z.B. wenn eine Fläche 10x unterteilt ist, aber alle Teile sind vollkommen plan auf einer Ebene. Oder man hat eine Rundung und statt dem Smooth Shading und 10 Eck-Segmenten macht man 50 Feinst-Segemnte ohne Smooth. Und verzichtet bei all dem noch auf LOD. Ganz besondere "Kandidaten" für Verschwendung sind z.B. in Blender eingegebene Buchstaben, in Mesh konvertiert und ohne Nachbearbeitung in SL importiert. Da sind dann oft massig doppelte Vertices drin und gerade Kanten sind 20x unterteilt.
 
Ich muss ehrlich sagen, ich kapiere Mesh nicht wirklich --aber ich stelle mir das so ähnlich vor wie wenn du auf eine Sim kommst mit einem Ort oder Wald, wo zig tausend einzelne Flächen mit jeweils unterschiedlichen Texturen sind, das gibt ja schon anhand der Render-Arbeit der Graka wesentlich mehr LAG als wenn nur ein paar wenige Flächen mit Texturen dort sind.

Und wenn ich mir dann als Vereinfachung überlege, das jedes einzelne dieser Dreiecke und Vierecke eines Meshes vergleichbar sein könnte mit einer einzelnen dreieckigen oder viereckigen - texturierten - Fläche an einem normalen Item, dann heißt das für mich: Je weniger Dreiecke (weniger Texturen), desto weniger LAG - je mehr Dreiecke (mehr Texturen), desto mehr LAG.

Aber unsere Mesh-Experten hier können mich ja aufklären WIE weit ich weg von der Wahrheit bin :D
 
Zuletzt bearbeitet:
aber ich stelle mir das so ähnlich vor wie wenn du auf eine Sim kommst mit einem Ort oder Wald, wo zig tausend einzelne Flächen mit jeweils unterschiedlichen Texturen sind,

Was Du sagst ist nicht ganz falsch, die Graka hat um so mehr zu tun, je mehr Flächen Sie texturieren muss. "Unterschiedliche Texturen" sind es nicht so ganz, es kann auch eine einzige Textur sein, die über viele Flächen gelegt wird.

Mesh ist einfach zu verstehen. In SL ist im weiteren Sinne alles ein Mesh, also im Wesentlichen aus Dreiecken zusammengeschustert. Eine normale Prim-Kugel besteht immer aus vielen kleinen Dreiecken, auf die auch die Textur der Kugel abgebildet werden muss.

Und bitte, versteht mich nicht falsch: Mesh ist nicht böse, sondern gut, weil man viele Flächen spart gegenüber zum Beispiel einem Sculpty. Böse sind die, die bedenkenlos riesige Meshes mit nutzlos vielen Flächen heraushauen. Es gibt Statuen im Marketplace, die hunderte von LI haben (und dann meist nicht verraten wieviele "Prims" sie haben) und Kleider, die aus Teppichen pixelgroßer Flächen bestehen! Ich denke mal so über den Daumen gepeilt können 500 Tris ausreichen für eine formschöne Hose, den Rest kann man mit einer guten Textur erledigen.

Lyncht mich jetzt, aber im Sinne der Echtzeit-Grafik ist SecondLife ein 3D-Spiel. Es sollten also auch nur Meshes erstellt werden, die "spielgeeignet" sind. Bei tausenden gleichzeitig sichtbaren Meshes sollten sie trotzdem 45 mal pro Sekunde gerendert werden können. Macht keine Mesh-Monster, die eine Stunde zum Rendern brauchen!

"Lag" bedeutet für mich ganz praktisch: Ich sitze vor meinem Bildschirm und ärgere mich darüber warten zu müssen oder mich nur noch hasensprungartig fortzubewegen. Da ist es mir völlig s-egal ob ich auf den Server, die Internet-Übertragung oder die Graka warte. Wer aber ein "Creator" sein will, der sollte intelligent genug sein und das bei seinen Kreationen berücksichtigen.
 
Zuletzt bearbeitet:
@ eight

Viele Dreiecke bedeuten nicht gleich mehr Texturen, meistens sind auf allen ein und die selbe Textur drauf, nur der Offset ist bei jedem Dreieck ein anderer.
Folgendes Collada habe ich mal mit dem Wordpad geoeffnet und hierbei handelt es sich lediglich um einen gemeshten rechteckigen Wuerfel mit 6 Seiten zu je 2 Dreiecken und nur einem Material (Texturflaeche).
Rechteck.jpg

Code:
<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.0">
  <asset>
    <contributor>
      <author></author>
      <authoring_tool>Mesh Studio</authoring_tool>
      <comments></comments>
    </contributor>
    <created>2013-03-25T14:41:06Z</created>
    <modified>2013-03-25T14:41:06Z</modified>
    <revision></revision>
    <title></title>
    <unit meter="1.000000"/>
    <up_axis>Y_UP</up_axis>
  </asset>
  <library_images>
        <image id="file2" name="file2">
            <init_from>default.jpg</init_from>
        </image>
  </library_images>
  <library_materials>
        <material id="blinn3" name="blinn3">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m1" name="blinn3m1">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m2" name="blinn3m2">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m3" name="blinn3m3">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m4" name="blinn3m4">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m5" name="blinn3m5">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m6" name="blinn3m6">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m7" name="blinn3m7">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m8" name="blinn3m8">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m9" name="blinn3m9">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m10" name="blinn3m10">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m11" name="blinn3m11">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m12" name="blinn3m12">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m13" name="blinn3m13">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m14" name="blinn3m14">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m15" name="blinn3m15">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m16" name="blinn3m16">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m17" name="blinn3m17">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m18" name="blinn3m18">
            <instance_effect url="#blinn3-fx"/>
        </material>
        <material id="blinn3m19" name="blinn3m19">
            <instance_effect url="#blinn3-fx"/>
        </material>
  </library_materials>
  <library_effects>
        <effect id="blinn3-fx">
            <profile_COMMON>
                <newparam sid="file2-surface">
                    <surface type="2D">
                        <init_from>file2</init_from>
                        <format>A8R8G8B8</format>
                    </surface>
                </newparam>
                <newparam sid="file2-sampler">
                    <sampler2D>
                        <source>file2-surface</source>
                        <minfilter>LINEAR_MIPMAP_LINEAR</minfilter>
                        <magfilter>LINEAR</magfilter>
                    </sampler2D>
                </newparam>
                <technique sid="common">
                    <blinn>
                        <emission>
                            <color>0 0 0 1 </color>
                        </emission>
                        <ambient>
                            <color>0 0 0 1 </color>
                        </ambient>
                        <diffuse>
                            <texture texture="file2-sampler" texcoord="UVSET0"/>
                        </diffuse>
                        <specular>
                            <color>0 0 0 1 </color>
                        </specular>
                        <shininess>
                            <float>0.3</float>
                        </shininess>
                        <reflective>
                            <color>0 0 0 1 </color>
                        </reflective>
                        <reflectivity>
                            <float>0.5</float>
                        </reflectivity>
                        <transparent>
                            <color>0 0 0 1 </color>
                        </transparent>
                        <transparency>
                            <float>0</float>
                        </transparency>
                        <index_of_refraction>
                            <float>0</float>
                        </index_of_refraction>
                    </blinn>
                </technique>
            </profile_COMMON>
        </effect>
  </library_effects>
  <library_geometries>
    <geometry id="o2jm1lib" name="o2jm1Mesh">
      <mesh>
        <source id="o2jm1libPos" name="position">
          <float_array id="o2jm1libPosa" count="24">-0.265000 -0.125000 0.265000 0.265000 0.125000 0.265000 -0.265000 0.125000 0.265000 0.265000 -0.125000 0.265000 -0.265000 -0.125000 -0.265000 0.265000 -0.125000 -0.265000 0.265000 0.125000 -0.265000 -0.265000 0.125000 -0.265000 </float_array>
          <technique_common>
            <accessor source="#o2jm1libPosa" count="8" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="o2jm1libUV0" name="map1">
          <float_array id="o2jm1libUV0a" count="72">0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 1.000000 0.000000 0.000000 1.000000 0.000000 1.000000 1.000000 0.000000 0.000000 0.000000 -1.000000 1.000000 -1.000000 0.000000 0.000000 1.000000 -1.000000 1.000000 0.000000 </float_array>
          <technique_common>
            <accessor source="#o2jm1libUV0a" count="36" stride="2">
              <param name="S" type="float"/>
              <param name="T" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="o2jm1libNorm" name="normal">
          <float_array id="o2jm1libNorma" count="18">0.000000 0.000000 1.000000 0.000000 -1.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 -1.000000 </float_array>
          <technique_common>
            <accessor source="#o2jm1libNorma" count="6" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <vertices id="o2jm1libVert">
          <input semantic="POSITION" source="#o2jm1libPos"/>
        </vertices>
        <triangles count="12" material="blinn3o2jm1m1">
          <input semantic="VERTEX" offset="0" source="#o2jm1libVert"/>
          <input semantic="NORMAL" offset="1" source="#o2jm1libNorm"/>
          <input semantic="TEXCOORD" offset="2" source="#o2jm1libUV0"/>
          <p>0 0 0 1 0 1 2 0 2 0 0 3 3 0 4 1 0 5 4 1 6 3 1 7 0 1 8 4 1 9 5 1 10 3 1 11 5 2 12 1 2 13 3 2 14 5 2 15 6 2 16 1 2 17 6 3 18 2 3 19 1 3 20 6 3 21 7 3 22 2 3 23 7 4 24 0 4 25 2 4 26 7 4 27 4 4 28 0 4 29 4 5 30 7 5 31 6 5 32 4 5 33 6 5 34 5 5 35 </p>
        </triangles>
      </mesh>
    </geometry>
  </library_geometries>
  <library_visual_scenes>
    <visual_scene id="Scene" name="Scene">
      <node id="Root" name="Root">
        <matrix sid="matrix">1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000</matrix>
          <instance_geometry url="#o2jm1lib">
              <bind_material>
                  <technique_common>
                      <instance_material symbol="blinn3o2jm1m1" target="#blinn3m1">
                          <bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0"/>
                      </instance_material>
                  </technique_common>
              </bind_material>
          </instance_geometry>
      </node>
    </visual_scene>
  </library_visual_scenes>
  <scene>
    <instance_visual_scene url="#Scene"/>
  </scene>
</COLLADA>

Das ganze Zeug muss beim Rezzen durch das Netzwerk bzw. von SL uebers Internet auf deinen Rechner und da ist noch keine Textur, keine Farbe, kein Glow oder sonstige Effecte und keine Physic bei.
Dieses Collada ist im Gegensatz zu den Meisten Mesh total Mini und mit 8kb quasi nicht der Rede Wert.
Ein Mesh mit 2404 Dreiecken und einem Land Impact von 8 Prim (Je nach Groesse) hat allerdings schon 323kb als Collada auf dem Rechner.

LG
Dae
 
Zuletzt bearbeitet:
Wäre das nicht sinnvoller gewesen, einen eigenen Thread für die Lag-Diskussion zu eröffnen bzw. einen bestehenden zu verwenden? Irgendwie finde ich diesen Thread zu schade dafür...
 

Users who are viewing this thread

Zurück
Oben Unten