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

Ist SL am Ende seiner Entwicklung?

Was es nicht löst sind die datenmengen und rechenkapazitäten, die allgemein nötig sind für die tausenden sculpties und meshes am körper von avataren.

Die Attachments sind für den Server im Grunde auch nur einfach ganz normale Prims, d.h. bis zu 38 Attachments am Körper mit bis zu 255 Prims pro Avatar. Macht man einen TP, dann werden die auf dem einen Server eben gelöscht und auf dem neuen Server dann gerezzt. Was natürlich bedeutet, dass da einige Parameter übertragen werden müssen zwischen den Sims und zwischen den jeweiligen Sims und den Viewern. Wobei sich diese Datenmengen aber bei sculpties und normalen Prims wirklich in Grenzen halten, vor allem Sculpts und Prims sind ziemlich klein, da man dort nur eine kleine Textur als Sculptmap übertragen muss bzw. die Prim-Parameter. Meshes sind leider bisschen größer, wenn man einen vollen Sim mit vielen Meshes besucht kann es schon sein, dass da dann teilweise bis über 100MB an Daten vom Sim an den jeweiligen Viewer gesendet werden müssen.

In dem Zusammenhang kommt dann aber ein neues Netzwerk-Protokoll bzw. ein geändertes HTTP-Protokoll ins Spiel, das auch schon in den Startlöchern steht. So dass auch die Datenübertragung von Texturen (die allerdings meist nur wenige kB groß sind als jpeg2000 Datei) und vor allem Meshes (die etwas größer sein können) über das Netzwerk verbessert werden wird.

Es gibt also jede Menge technische Weiterentwicklung in SL. Nur eben nicht immer sichtbar. Und nicht hier und jetzt und heute verfügbar, für manches muss man eben auch noch paar Tage oder Wochen warten.
 
(...)

Ein haken dabei ist allerdings, du selber siehst es dann auch erst nachdem es fertig ist.
Umziehen dauert also wesentlich laenger, weil du keine Vorschau mehr hast.
Bis jetzt war es ja so, dass wenn du schnell kleidung gewechselt hast, sofort sehen konntest was du anziehst, das musst du nun ebenfalls komplett abwarten bis es fertig gebacken ist.

LG
Dae


Das sollte kein großes Problem sein mit dem Warten.
Momentan läuft es ja so:
Anziehen neuer Kleidung ---> Download der verschiedenen Texturen übers Internet auf den Viewer (1.5 Mbits...) (--> Viewer backt die Texturen als jpeg2000, das geht aber super schnell alles) --> upload der neuen gebackenen Textur auf den Server (manchmal nur 128 kbits...)--> Download der aktuellen Textur des eigenen Avas vom Server -- > Anzeige der gebackenen Textur auf dem eigenen Ava.

Mit dem neuen System läuft das so:
Anziehen neuer Kleidung --> Server holt sich die Texturen im Grid (1Gbit-Anbindung...) (---> Server backt die Texturen als jpeg2000, was sehr schnell geht ) -- > Download der aktuellen Texturen des eignen Avas --> Anzeige der Texturen auf dem eigenen Ava.

Man spart sich mit dem neuen System also einmal den Download und einmal den Upload. Weswegen das Umziehen nicht wesentlich länger dauern sollte als das Texturieren eines Prims mittels einer Textur-UUID. Vor allem aber kommt der Server mit vielen schnellen Rebakes/KLeiderwechseln nicht durcheinander. Das kann nämlich mit dem alten System durchaus passieren, wenn man da die Kleidung zu oft wechselt (10.. 12 Wechsel in sehr kurzer Zeit, je nach upload Speed) bevor die gebackenen Texturen hochgeladen sind, dann kann sich da was "verheddern" im Queue und schlimmstenfalls werden die gebackenen Texturen gar nicht mehr korrekt hochgeladen bzw. man braucht einen Relog um sich selbst dann so zu sehen, wie einen die anderen auch sehen. Oder man wird eben Wolke.
 
Sorry Shirley, das Umziehen macht mit dem Server Side Baking absolut keinen Spass mehr und dauert je nach Netzauslastung erheblich laenger.
Vorher konnte ich wie in einer Art Vorschau immer sehen was ich anziehe, es war quasi sofort zu sehen, allerdings nur fuer mich. Alle anderen mussten aufs rebacke warten. So konnte ich teilweise bis zu 15 ganze Outfits durchprobieren, bevor ueberhaupt nur ein mal rebacken wurde.
Jetzt muss ich mit dem neuen System ebenfalls auf das Rebacke warten, bis ich eine Aktualisierung sehe.
Dabei werden dann jedes mal alle Avatar Sectionen komplett neu gebacken, selbst wenn ich nur verschiedene paar Handschuhe teste.
Ob das dann wirklich weniger Download fuer den Viewer bedeutet, wage ich ernsthaft zu bezweifeln.

Selbst Henri Beauchamp hat schon gemerkt, dass es lamarschig ist.
Made the manual rebake requests (CTRL ALT R) more aggressive in server-side baking mode, by force-updating the current outfit folder version.
http://sldev.free.fr/forum/viewtopic.php?f=3&t=81&start=180#p5115
Added an "Aggressive avatar rebakes" setting (toggle in "Advanced" -> "Character") to force a COF version incremental in SSB regions and a more aggressive rebake (close to what is obtained by opening and closing the Appearance floater) in non-SSB regions.
http://sldev.free.fr/forum/viewtopic.php?f=3&t=81&start=180#p5170

LG
Dae
 
Zuletzt bearbeitet:
Anstatt schnell hintereinander 15 outfits anzuziehen empfehle ich Dir, Dir einen Kleiderschrank anzuschaffen: https://marketplace.secondlife.com/...ith-style-A-visual-inventory-organizer/935078

Danke dir, aber damit kann ich nichts anfangen, ich bin es von je her gewohnt, Clothes und Attachments via doppelklick manuell anzuziehen.
Dabei kombiniere ich oft, eigentlich immer, Outfits aus verscheidenen Ordnern. So kann es sein, dass ich mein Outfit von 10 verschiedenen Designern zusammen stelle. Wuerde ich im Inventar oder in so einem Schrank meine Outfits jedes mal als Ganzes speichern, haette ich fueher oder spaeter jedes item 10 oder 20 mal im Inventar.

Deshalb kommt fuer mich dieses lame rebacken echt ungelegen.

LG
Dae
 
Kein Problem. Das Backen läuft zur Zeit so: Alle Einzel-Texturen werden einzeln vom Server an den Avatar geschickt, der die Kleidung, tattoo, alpha, etc trägt.

Sind da auch die Texturen von Mesh Kleidung drin oder nur die normale Kleidung, die ja wie ein Tattoo auf der Haut sitzt? Weil, wenn immer mehr Leutchen Mesh Kleidung tragen und die nicht gebaked werden braucht/kann, ist das neue Feature ein bissi spät dran. :)
 
Das kann nur die Normalkleidung sein, denn die Attachments laufen eh nur über den Server. Du hast also Recht, sofern Mesh-Kleidung betroffen ist. Aber wenn ich mich in größeren Menschenansammlungen umsehe, dann macht Mesh maximal 20% aus, auch wenn ich fast nichts anderes mehr trage als Mesh.
 
Sorry Shirley, das Umziehen macht mit dem Server Side Baking absolut keinen Spass mehr und dauert je nach Netzauslastung erheblich laenger.
Vorher konnte ich wie in einer Art Vorschau immer sehen was ich anziehe, es war quasi sofort zu sehen, allerdings nur fuer mich. Alle anderen mussten aufs rebacke warten. So konnte ich teilweise bis zu 15 ganze Outfits durchprobieren, bevor ueberhaupt nur ein mal rebacken wurde.
Jetzt muss ich mit dem neuen System ebenfalls auf das Rebacke warten, bis ich eine Aktualisierung sehe.
Dabei werden dann jedes mal alle Avatar Sectionen komplett neu gebacken, selbst wenn ich nur verschiedene paar Handschuhe teste.
Ob das dann wirklich weniger Download fuer den Viewer bedeutet, wage ich ernsthaft zu bezweifeln.

Selbst Henri Beauchamp hat schon gemerkt, dass es lamarschig ist.

http://sldev.free.fr/forum/viewtopic.php?f=3&t=81&start=180#p5115

http://sldev.free.fr/forum/viewtopic.php?f=3&t=81&start=180#p5170

LG
Dae

Zumindest die Leute, die vorher hin und wieder Probleme mit dem uploaden vieler baked Texturen hintereinander hatten, die werden sich freuen.

Und wie das Ganze letztendlich zeitlich aussehen wird zeigt sich dann, wenn der LL-Viewer als Release Cadidate raus ist, der den Sunshine-Code mit der ServerSide Appearance drin hat. Noch ist der Code aber noch nicht mal auf den Relase Candidates, geschweige denn im Beta-Viewer, der Code ist derzeit erst mal im offiziellen Development Viewer in der Testphase, eben weil es noch hier und da noch Fehler gibt. Und im MainGrid ist das auch noch nicht auf den Servern, das ist noch nicht mal auf den Release Candidates. Bisher gibts lediglich ein paar einzelne Test-Regionen im Beta-Grid für das ServerSide Baking. Und wenn du dich mit dem CoolVL in SL nun schlechter umziehen kannst, dann liegt das am CoolVL selbst.

D.h. der CoolVL-Viewer hat da derzeit eigentlich schon Zeug in seiner Release eingebaut, das noch nicht mal wirklich "freigegeben" ist von LL, und wenn er pech hat, dann darf er seinen Code da noch mal kräftig überarbeiten. Das ist nebenbei mit der Grund, warum die Firestorm Version mit Server Side Appearance noch nicht offiziell raus ist, einfach weil die Lindens da eventuell noch Änderungen/Bugfixes am SSA-Code machen könnten bevor das in den Beta-Viewer kommt.

SL entwickelt sich zwar zügig weiter, aber ein paar Wochen dürfte es mindestens noch dauern, bis man über die Server Side Appearance (wie das Ding wohl nun heist) eine verlässliche Aussage machen kann. Momentan kommt erst mal der CHUI Viewer (mit dem neuen Interface) bzw. das Materials Update als Beta raus.
 
Das was ich bisher auf dem Beta Grid mit SSB testen konnte war verdammt fix, auch das an und ausziehen. Ich bin gespannt wie das dann in der Masse sein wird ;)
 
@ Shirley

Ich hoffe das es noch besser wird, nur das was ich bis jetzt im EXPERIMENTAL Viewer gesehen habe, ueberzeugt mich nicht davon besser zu sein.

@ Kelith

Das Rebaken betrifft ausschliesslich die Texturen, die direkt auf den Avatar gelegt werden, Attachments (Mesh sind auch Attachments) sind davon nicht betroffen.
Die Alpha Layer die du benoetigst um deinen Avatar unter dem Mesh zu verstecken sind ebenfalls Layer und muessen auch gebacken werden.

LG
Dae
 
@ Shirley

Ich hoffe das es noch besser wird, nur das was ich bis jetzt im EXPERIMENTAL Viewer gesehen habe, ueberzeugt mich nicht davon besser zu sein.

Oh Stimmt, mein Fehler, das mit dem Experimental hab ich übersehen.
Das hat sich allerdings schon gewaltig weiter entwickelt mit dem SSA. Der CoolVL ist eben "nur ein Nachbau", der auch viel eigenen Code da drin verwurstelt hat. Und zwar manchmal ziemlich gut Fehler behebt/umgeht, aber leider nicht das Maß aller Dinge ist. Und eben ein 1-Mann-Projekt mehr oder weniger, weswegen sich der Coder wohl noch mal hinsetzen muss, wenn man sich da immer nur noch so langsam umziehen kann und wenn das beim Release demnächst nicht so bleiben soll.

Wenn du dich mit dem aktuellen Sunshine Development Viewer (Second Life 3.5.1 (273573) vom 5.4.2013) in einer der Sunshine-Testregionen im Beta Grid einloggst und wartest, bis dein Inventory vom Server geladen ist (damit die Bandbreite davon nicht blockiert wird), dann dauert das Umziehen kurz (1s) und noch mal bisschen bis die Texturen vom Server geladen sind, und der Viewer muss die Texturen auch noch auf den Ava rechnen - und nach 3 bis 5s Sekunden bist du spätestens komplett fertig umgezogen. Das Limitierende ist dann allerdings dein Download Speed, d.h. mit einer schnellen Anbindung bist du schon nach 1s bis 2s komplett fertig umgezogen. Dabei werden dann so wie es hier aussieht aber nur die Texturen geladen, die auch geändert werden. Also nur Oberkörper, wenn man nur das Unterhemd wechselt.
Momentan zumindest (Testsim ist ganz leer) geht das sogar über VPN-Verbindung mit nur 300 kbits Download wunderbar.

Testregionen mit SSA:
secondlife://Aditi/secondlife/SunshineTest/111/134/23

Sunshine Development Viewer:
http://automated-builds-secondlife-.../sunshine-external/arch/CYGWIN/quicklink.html (windows)
http://automated-builds-secondlife-...o/sunshine-external/arch/Linux/quicklink.html (Linux)
 
Zuletzt bearbeitet:
[*]"das Teil einstampfen" -- was würdest du denn bis zur Live-Schaltung eines "völlig neuen Produkts" als Alternative zu SL anbieten wollen?

Ich will gar nichts anbieten, muss es auch nicht. Schauen wir, was Rosedale zusammenbringt.

"mit Top-Grafik" - Bist du nicht auch diejenige, die mit am lautesten einen offiziellen Client für Mobilgeräte einfordert? Also dass LL genau das tun soll, was BM den Hals gekostet hat? Liebe Mona, eins kannst du nur haben: Entweder Top-Grafik, die nur an Game-Konsolen oder High-End-Desktops möglich ist - ODER Mobil-Zugang, ODER Zugang für die Allgemeinheit der Rechner. Was willste denn nu?

Wie ich das Video verstanden habe, ist Voxel eine völlig neue Technik, die in Summe weniger Leistung braucht als Polygone. Damit wäre der Weg für mobile Anwendungen frei. (Wobei "Mobilgeräte" wie Tablets sowieso nicht geeignet wären, da ginge es eher um Datenbrillen und solche Dinge.)

Übrigens (jemand hat es angedeutet) wollte ich nicht trollen und dann abhauen, ich habe einfach erst jetzt Zeit zum Antworten.
 
also Voxel soll weniger Hardware, bzw Rechenleistung beanspruchen?
Das habe ich irgendwie anders verstanden.

Das hängt stark davon ab, wie viele verschiedene Objekte man in der Szene darstellen will. Vermutlich wird Linden Lab seine erste Voxel-Welt von der Spielidee her entsprechend einschränken, dann können Voxeldarstellungen auch deutlich ressourcenschonender sein als Meshdarstellungen. Eine durch User frei projektierbare Welt mit unglaublich vielen verschiedenen detailreichen Objekten würde aber leistungsstarke Grafikkarten erfordern. Sehr gut mit Voxeln gehen würden Spiele wie Minecraft, das wurde auch mit einer experimentellen Engine bereits demonstriert (erstes der beiden Videos).

EDIT im Blog der Firma gefunden:

[video=youtube;nizHTdGUWkM]http://www.youtube.com/watch?v=nizHTdGUWkM[/video]

Realtime Capture auf einer ATI 4770 mit HD720p.
Framerate 30 fps (mehr wurde durch das Programm verhindert).
Größe der Region 1 km x 1 km.
Sieben Level of Details (LOD).
Drei Programm-Instanzen "VoxelFarm" benötigten zusammen 12 Stunden, um die Landschaft zu erzeugen.
Der generierte Mesh-Datensatz ist 100 MB groß (zum tatsächlichen Anzeigen braucht die Grafikkarte ja wieder Meshes).
Streaming-Bandbreite unter 300kb/sek, also deutlich weniger als üblicherweise in SL.

Es wurde nur eine Art Baum-Zweig verwendet, und zwei Arten von Gras.
Es wurden keine Schatten und kein globales Licht gerendert.
Die Texturen sind recht einfach gestaltet.

Zum Schluss noch ein Beispiel aus dem RL, wo Rechnerleistung (fast) keine Rolex spielt:

[video=youtube;uW3GmHTfG4g]http://www.youtube.com/watch?v=uW3GmHTfG4g[/video]
 
Zuletzt bearbeitet:
(...)
Wie ich das Video verstanden habe, ist Voxel eine völlig neue Technik, die in Summe weniger Leistung braucht als Polygone. Damit wäre der Weg für mobile Anwendungen frei. (Wobei "Mobilgeräte" wie Tablets sowieso nicht geeignet wären, da ginge es eher um Datenbrillen und solche Dinge.)
(...)

Ob man nun Datenbrillen an den PC hängt oder 3DMonitore oder hoch auflösende TFTs, das macht nicht wirklich einen Unterschied, es kommt da vor allem auf die Auflösung an bzw. auf die Anzahl der Pixel, die man pro Sekunde letztendlich berechnen muss. Bei einem FullHD Monitor mit 24FPS sind das eben 1920 * 1080 px * 24 = ca. 48 Megapixel/Sekunde, die man berechnen muss. Bei einem großen Bildschirm mit 2560 x 1440 px sind es bei 24FPS dann 88 Megapixel. Und wenn man das Oculus Rift Dingens verwendet, dann hat das z.B. ein 1920x1080 px Display. Also so viel wie ein FullHD Monitor.

Was die Voxel angeht, da ist das Video ein bisschen missverständlich, das ist allerdings aber auch ein Werbevideo für Investoren, keine Dokumentation. Und neu ist diese Technik auch nicht wirklich. Diese Technik braucht aber viel mehr Rechenleistung als vergleichbare Polygongrafiken. Die Objekte an sich sind damit zwar erst mal viel einfacher zu berechnen als mit den Polygonen, aber dafür sind die dabei entstehenden Datenmengen sehr viel größer - so dass man unter dem Strich mehr berechnen muss. Da kann man zwar bisschen was mit passenden Algorithmen vereinfachen und Datenmengen reduzieren (das ist das, was Rosedale da mit seinen Octree-Berechnungen wohl machen wird..), aber mit Vektorgemetrie kann man bei 3D-Operationen einfach viel effektiver Arbeiten. Das kann man in etwa vergleichen mit dem Unterschied zwischen Bitmaps/Rastergrafiken einerseits und Vektorgrafiken andererseits, die kennst du ja vermutlich ziemlich gut. Vektorgrafiken lassen sich wesentlich einfacher skalieren. Voxelgrafiken sind im Prinzip einfach "3D-Bitmaps" während Polygongrafiken mehr oder weniger "3D-Vektorgrafiken" sind, und letztere kann man eben mit dem Einsatz höherer Mathematik (vor allem mit Vektor- Ebenen- und Matrix-Berechnungen, aber auch mit Differentialgleichungen usw.) wesentlich effektiver Berechnen. Wobei man da den Vorteil hat, dass der PC einem diese Dinge extrem schnell mit Näherungs-Rechnungen ausrechnen kann. Eine Tangente an ein Kreis in einer bestimmten Kreiskoordinate zu berechnen bringt zwar gern mal Oberstufenschüler und Studenten ins Schwitzen, für den PC ist das aber nur eine Frage von Sekundenbruchteilen. Nicht zuletzt weil die GPU genau auf solche Operationen optimiert sind.

Dafür haben Voxelgrafiken den Vorteil, dass man Elemente, die oft auftauchen (immer wieder der selbe Baum etwa) einfach mehrmals ins Bild kopieren kann, man muss nur die Voxelgröße dann an die Perspektive anpassen. Minecraft macht das derzeit so ähnlich, d.h. da kommen im Prinzip Voxel-artige Elemente zum Einsatz, die aber dann über eine Vektorgrafik in 3D umgesetzt werden, weil man damit leichter skalieren kann. Und Voxelgrafiken werden im wissenschaftlichen Bereich gern eingesetzt, weil man 3D-Scans sehr leicht als Voxelgrafiken umsetzen kann. Und weil man 3D-Datensätze einfach als Voxelgrafik darstellen kann.
 
Nur ganz nebenbei:
Seit dem 22.03.2013 ist jetzt Patterns (http://lindenlab.com/products/patterns) über Steam verfügbar. (http://store.steampowered.com/app/218980/)
Und so rein zufällig sieht Patterns ganz so aus, als könne es ein sehr guter Kandidat für einen Voxelrenderer sein, einfach weil da ziemlich viel aus immer den selben Objekten besteht.
Mit SL hat das Ganze dann aber nichts zu tun. Das wird ganz sicher nicht eine virtuelle "Nachfolge-Welt" werden, auch wenn das eine virtuelle Welt ist.
 
[...], auch wenn das eine virtuelle Welt ist.

Naja, Patterns eine Virtuelle Welt zu nennen, ist meiner Meinung nach schon seeeeehr weit hergeholt. Nach dem Maßstab könntest du ja gleich auch Sketchup eine Virtuelle Welt nennen. Oder Cooliris. :twisted: Patterns ist ein "Shared Creativity Space", ein "Sandbox Game" - Nicht mehr, nicht weniger. Aber auf keinen Fall ist es eine Virtuelle WELT.

Übrigens gibts außer SL und den OpenSim-Grids gerade mal eine Handvoll virtueller Plattformen, die ich tatsächlich als Virtuelle Welt bezeichnen würde - alle anderen sind entweder 3D-Chats, Games, oder irgend ein Möchtegernding. :)
 
Zuletzt bearbeitet:
SL ist cool, bis auf die Tatsache das Linden viel zu gierig ist. Für das Geld was die für einen einzigen, elendigen SIM verlangen, kann ich heutzutage ein halbes Rechenzentrum mieten. Auch die selbsternannten Kreativen sind viel zu maßlos, was da teilweise für ein paar dämliche Bildchen (nichts anderes sind doch Texturen, Sculpts und Meshes) verlangt wird ist unverschämt, mal abgesehen von der grenzenlosen Arroganz die da einige an den Tag legen. Besonders widerlich sind die "Kreativen" die sich fröhlich in der Modding Szene bedienen und frei verfügbare Texturen und Meshes in SL zu Geld machen. Was bleibt noch über SL zu sagen - nun ungefähr 90% der Nutzer haben einen Dachschaden oder sind irgendwie merkwürdig. Kurz und gut - ein großes, teures Irrenhaus. Und es gibt tatsächlich immer noch Irre die glauben mit oder in diesem großen Therapiezentrum, ließe sich viel Geld verdienen. Aber erstaunlicherweise ist SL immer noch am Leben, hartnäckig sind sie, das muss man ihnen lassen.

Aber der Untergang ist nah - lasst endlich los und geht in das Licht!
 

Users who are viewing this thread

Zurück
Oben Unten