Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Lagreduzierung: Der schwächste fliegt - oder doch nicht?
#11
Meine Erfahrung mit Skripten in os ist. Alle Funktionen die Ereignisbedingt aktiviert werden, wie Sit, llListen,Touch …   sind  relativ harmlos, da sie meistens „schlafen“. Was man aber unbedingt im Auge behalten sollte sind die Timer Funktionen. Die werden periodisch durchgeführt. Hat man zu viele, gerät alles schnell aus den Fugen, weil die  irgendwann nicht mehr in eine Zeitscheibe passen. Blöder Weise braucht man den Timer aber auch für extrem viele Sachen und einen Ersatz gibt es leider nicht.  Wenn möglich, sollte man ihn daher an eine Ereignisfunktion koppeln. Beispiel, ein Avatar soll mit Namen begrüßt werden. Dann wäre es am Serverfreundlichsten man lässt den Ava auf ein unsichtbares Prim latschen, wodurch das Ereignis, Kollision eintritt und das aktiviert dann erst den Timergesteuerten Sensor um herauszufinden wer es ist. Später wird der Sensor/Timer wieder abgeschaltet. Oder man benutzt einen Timer zentral und schickt die Infos per Regionssay an die Objekte, die erst aktiv werden, wenn Daten auf ihrem Kanal anliegen.

Zum Thema Mesh und Flächenbegrenzung, das ist alles furchtbar theoretisch. Ich habe mir für mich  folgende Methode überlegt. Die Engine wurde Jahrelang auf Prims u. Sculptprims getrimmt.
Wenn ich etwas als Mesh baue überlege ich wie viele Sculptprims ich brauchen würde und addiere die Flächen. Dann habe ich eine Bezugsgröße.
Beispiel, ein verspielter Jugendstil Sessel. Das wären über den Daumen 2 Lehnen, zwei Lehnenträger, Stuhlrumpf, Stuhlrückenlehne,zwei Kissen für Hintern und Rücken, vier Beine und vier Querstreben = 16 Objekte x 1024 Dreieckflächen = 16.384 Dreiecke, wenn er mit Sculptprims gebaut würde. Wenn ich das mit meinem Mesh Sessel spürbar unterbiete ist alles im grünen Bereich Wink
Degolburg:
24h online und ca. 12% fertig
Taxi:85.214.150.139:9000:degolburg
Antworten }
Thanks given by: Achim
#12
(05.06.2017, 17:50)MoniTill schrieb: Meine Erfahrung mit Skripten in os ist. Alle Funktionen die Ereignisbedingt aktiviert werden, wie Sit, llListen,Touch …   sind  relativ harmlos, da sie meistens „schlafen“. Was man aber unbedingt im Auge behalten sollte sind die Timer Funktionen. Die werden periodisch durchgeführt. Hat man zu viele, gerät alles schnell aus den Fugen, weil die  irgendwann nicht mehr in eine Zeitscheibe passen. Blöder Weise braucht man den Timer aber auch für extrem viele Sachen und einen Ersatz gibt es leider nicht.  Wenn möglich, sollte man ihn daher an eine Ereignisfunktion koppeln. Beispiel, ein Avatar soll mit Namen begrüßt werden. Dann wäre es am Serverfreundlichsten man lässt den Ava auf ein unsichtbares Prim latschen, wodurch das Ereignis, Kollision eintritt und das aktiviert dann erst den Timergesteuerten Sensor um herauszufinden wer es ist. Später wird der Sensor/Timer wieder abgeschaltet. Oder man benutzt einen Timer zentral und schickt die Infos per Regionssay an die Objekte, die erst aktiv werden, wenn Daten auf ihrem Kanal anliegen.

Zum Thema Mesh und Flächenbegrenzung, das ist alles furchtbar theoretisch. Ich habe mir für mich  folgende Methode überlegt. Die Engine wurde Jahrelang auf Prims u. Sculptprims getrimmt.
Wenn ich etwas als Mesh baue überlege ich wie viele Sculptprims ich brauchen würde und addiere die Flächen. Dann habe ich eine Bezugsgröße.
Beispiel, ein verspielter Jugendstil Sessel. Das wären über den Daumen 2 Lehnen, zwei Lehnenträger, Stuhlrumpf, Stuhlrückenlehne,zwei Kissen für Hintern und Rücken, vier Beine und vier Querstreben = 16 Objekte x 1024 Dreieckflächen = 16.384 Dreiecke, wenn er mit Sculptprims gebaut würde. Wenn ich das mit meinem Mesh Sessel spürbar unterbiete ist alles im grünen Bereich Wink

Liebe Moni ich halte auch Befehle wie llListen für suboptimal, da ich dafür einen aktiven Listener ständig brauche. Dieser muss ja ständig lauschen ob was für ihn kommt.

Ich versuche diese Befehle einzusparen indem ich den Kommunikationsbedarf im Linkset minimiere, also so wenig Scripte wie Möglich pro Objekt einsetzte und diese dann auch alle im Rootprim unterbringe. Childprims kann man dann immer noch über Befehle wie llSetLinkPrimitiveParams "remote" manipulieren.

Auch Kollisions Objekte müssen ja ständig auf Kollision geprüft werden, wenn auch nicht von uns Scritptern selbst.

Ich denke es gibt keinen Königsweg der bei allen Scripten passt, daher muss man sehr stark Fallbezogen entscheiden was am besten geeignet ist.

Ist zum Beispiel die gewünschte Funktion in einen passiven (Warten) Zustand und einen (oder mehreren) aktiver Interaktions Zustand trennbar so arbeite ich mit mehreren "State" zuständen. So kann man die Last des Scriptes immer dann reduzieren wenn es nicht gebraucht wird. Als Kriterium könnte man einen generellen Simweiten Detector nutzen ob jemand in der Sim ist- und dann alle Scripte wecken - oder schlafen schicken.
Aber das ist nur eine Möglichkeit unter Vielen.

Eine effizientere Methode Scripte zu sparen habe ich darin gefunden gleichartige Aufgaben aus mehreren Prims zusammenzufassen, und die betroffenen Prims zu einem Linkset zu koppeln.
Beispiel 20 anrollende Wellen an der Strandlinie, oder viele gesteuerte Schnee Partikel Emitter über der Sim. Da kann ich dann mit einem einzigen Script und Befehlen wie llSetLinkPrimitiveParams zum Beispiel alle child Prims des Linksets in einem Rutsch abdecken, und behalte trotzdem die volle Veränderbarkeit des Scriptes.

Sehr Lasthaltig sind Scripte die ein Objekt stufenweise in einer Programmschleife verändern, wie zum Beispiel ein Objekt langsam unsichtbar machen. Schafft man es dafür Partikel einsetzten zu können, so kann man Start Alphs und End Alpha in der Partikelerzeugung gut dafür einsetzten.

Und ob Timer oder Wait ist vor allem eine Frage der Häufigkeit der Events. Meine Beobachtung ist folgende: Timer sind besser wenn Sachen sehr selten passieren (ca. > 10 Sekunden). Wait scheint für häufige sehr kurze Wartezeiten im Vorteil zu sein. Dabei darf man sich aber nicht auf die Regionconsole verlassen. Die scheint Waits generell zu bestrafen, was aber nach meinen Tests nicht der realen Last entspricht.
Ich habe versucht ein Objekt ohne es "physisch" zu machen, ruckfrei zu bewegen - also mit ca. 25 frames pro sekunde in kleinen Schritten. Mit wait ging das sanft -wenn auch mit messbarer Last. Die Wartepausen mit Timer zu überbrücken war hingegen ein Misserfolg. Es ruckte sehr stark, und die Last war sehr hoch. Daher vermute ich das der Wait Befehl ein Stop Befehl dasrstellt, der das Script anhält, aber geladen beläßt. Der Timer hingegen wir in Interrupt zu sehen ist der das script im Prozessor entläd und läd. Und diese Ladecyclen machen dann offenbar die meiste Last. Seither setzte ich Timer nur noch für größere Warteperioden ein.

Generell muss man sich aber fragen was man eigentlich optimieren will:

1. - die Script CPU Last auf dem Server
2. - den Script Speicherverbrauch auf dem Server
3. - den Ablauf innerhalb eines Scriptes um zum Beispiel ein Fahrzeug sanft ruckfrei und schnell bewegen zu können.

In den oberen Passagen haben wir nur über 1. und 2. gesprochen

Für einen Besucher Inworld ist aber alleine 3. entscheidend solange die zu hohe Serverlast nicht bei ihm sichtbar und fühlbar wird.

und um 3. zu optimieren muss man sich schon schon auf Prozessor befehls Ebene hinunter begeben, und wissen welcher CPU Code wieviele CPU Schritte benötigt - und welcher Befehl wie in CPU Code umgesetzt wird. Leider ist dazu rein gar nichts veröffentlicht.

Das eine Variable++ das gleiche wie Variable = Variable +1 ergibt ist noch einsehbar. Aber ersterer Befehl ist deutlich effizienter da nur ein Register geladen werden muss und ein Increment Befehl auf allen CPUs in einem Takt erledigt ist. Die Zweite Variante hingegen läd 2 Register und führt eine Addition durch. Ja das ist Kleinvieh - aber auch das macht Mist.

Bei Fahrzeug Scripten kommt es vor allem darauf an das die ständig zu durchlaufende Fahr Steuerungs Schleife so wenig Zeit braucht wie möglich, sonst ruckt es. Die Mittel dazu sind:

- Verzicht auf überflüssige Abfragen
- Verzicht auf entbehrliche periodische Ausgaben ( Die Geschwindigkeit in jeder Schleife zu ermitteln und mit floatText auszugeben kann schon reichen das das Fahrvergnügen dahin ist). Notfalls Periode der Ausgabe duch incrementierenden Zähler minimieren, zum Beispiel nur jede 100. Schleife Geschwindigkeit anzeigen
- Befehle zu verwenden die mit 200ms Strafzeit belegt sind ist fatal.
           siehe:  http://wiki.secondlife.com/wiki/LlSetLin...tiveParams
  daher nur die "fast" Befehle verwenden wie llSetLinkPrimitiveParamsFast
- In der FahrSchleife hat nichts Entbehrliches drin zu suchen was ich davor auch erledigen kann, wie Variablen deklarieren, Startwerte zuweisen, statische Berechnungen durchführen, etc. Kann man Teile der Berechnungen "vorher" erledigen so sollte man das auch tun und mit dem Teilergebnis in der Schleife operieren.
- keine Listen Befehle an Reifen etc. absetzten sondern Linkset Befehle verwenden
- statt drehende oder bewegte Objekte Texturanimation geschickt einsetzten
- keine Timer einsetzten das diese wie ein Interrupt zur unmittelbaren Unterbrechung an beliebiger Scritpstelle führen.

Naja und wer jetzt Blut geleckt hat auf ein performantes Boot Script der besuche uns in Nextlife-World. Dort gibt es diese Boote auf der Isla Bonita als Freebee.
Antworten }
Thanks given by: Achim
#13
Ich finde den Eingangspost sehr gut, würde ich gern in gekürzter Form als NC auf englisch rumschicken. Auch den Teil "AO in den Viewer laden" würde ich gern kopieren und in die AOs mit rein packen.

Zum Thema Mesh-Bodies: Die neueren haben keine 4 Layers mehr und sind low ARC (Avatar Rendering Cost). Das betrifft Ruth, Athena ab 4.0, dann Adonis ab 3.0, Apollo und Ares.
Sapphira, Eva und Athena2 sowie bei den Männern Muscle Body und der Satyr Body sind multiple Layer. Bei Ruth kann man das 2. Layer aber extra anziehen oder nicht und bei Athena ist das Tattoo-Layer auch extra.

Bei den Herren ist es ja eher unüblich, leichtbekleidet umherzurennen und da verstehe ich nicht, warum man nicht extra Bento Hände zum Regular Body trägt. Es geht ja eigentlich meist nur um ein kleines Stück Ausschnitt oder Arm. Und hier ist die gute Nachricht: Die meisten Bodys kann man auseinanderbauen und manuell bestimmte Faces auf Transparenz = 100% setzen. Dann hat man nur die Arme und den Hals an. Dadurch geht dann die Alpha-HUD nicht mehr, die man aber in dem Fall eh nicht mehr braucht (die Scripte kann man löschen), aber der Skin Applier geht trotzdem noch.

Eine weitere Möglichkeit besteht darin, sich seine Alphas selber zu machen, wenn es nur um den Ausschnitt geht. Sehr oft liegen die Alpha-Texturen der Kleidung bei und man muss dann nur noch im Photoshop die Hände weg machen und den oberen Teil des Full Body Alphas ersetzen. Dann hat man einen "Regular Ausschnitt", was nicht auffällt, wenn die Skin Texturen identisch sind.
Alle Scripte aus einem "Party Mesh Body" zu löschen finde ich überflüssig, stoppen reicht. AOs sollte man allerdings komplett abnehmen, die braucht man ja beim Tanzen sowieso nicht.

Ansonsten fehlt mir das Verständnis fürs Mesh Bashing. Ich laufe bestimmt nicht mit aufgemalten Hosen und ohne Haare rum, nur weil irgendwer einen Rechner aus den Neunzigern und ein Telefonmodem hat. Der kann dann eben nicht auf solche Partys. Pech gehabt. Wer kein Geld für Technik hat, hat seine Prioritäten vermutlich woanders.

Gruß, Otto
Ich habe noch nie im Leben etwas Gescheites gesagt und bin zu eitel, andere zu zitieren.
Antworten }
Thanks given by: Achim


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste