Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Virtuelle Welten, wo bauen und wohin exportieren?
#1
In diesem Thread möchte ich Vor- und Nachteile verschiedener Strategien beleuchten, zukunftsfest fürs nächste Jahrzehnt Big Grin 3D-Regionen zu bauen. Dabei betrachte ich drei Tools: OpenSim, Blender und Unity. OpenSim und Blender sind Open Source, Unity hat zumindest eine "Community-Edition", die kostenfrei nutzbar ist.

Annahme: Man will die gebauten Szenen (Regionen) zwischen verschiedenen Virtuellen Welten transferieren können, Stichwort Zukunftsfestigkeit. Wer weiß, welche Software in 10 Jahren Standard ist?

Um das Problem einzugrenzen, untersuche ich folgendes:
1) Konstruieren einer Szene in Blender, exportieren nach Unity oder OpenSim.
2) Konstruieren einer Szene in Unity, exportieren nach OpenSim oder Blender.
3) Konstruieren einer Szene in OpenSim, exportieren nach Blender oder Unity.

Gerne könnt ihr Erfahrungen, Ideen oder weitere Möglichkeiten beitragen. Smile Selber betrachte ich nur Varianten, die unter Linux lauffähig sind, aber ihr könnt gerne auch das andere Betriebssystem einbeziehen.
Zitieren
#2
1) Konstruieren einer Szene in Blender, exportieren nach Unity oder OpenSim.

Vorteile:
- Blender ist das am besten unterstützte Open-Source-Programm für 3D-Simulationen, selbst Animationsfilme hoher Qualität können damit erstellt werden.
- Um Mesh-Objekte zu erzeugen, sind viele von uns eh an das Tool gewöhnt.
- Export Richtung Unity ist möglich.

Nachteile:
- Abgesehen von Einzelobjekt-Export müsste ein Export-Tool in Richtung OpenSim noch entwickelt werden. Ich halte das für möglich, wenn auch aufwändig (man muss z.B. Methoden aus libopenmetaverse verwenden).
- Eine Blender-Szene wird schnell unübersichtlich, man wird also keine komplette Region als Blender-Szene entwickeln können. Mit der Merge-Option könnten allerdings Teilszenen als viele Einzel-OARs zu einer Region kombiniert werden.
- Eine Blender-Szene wird in Unity zu einem einzelnen "Prefab". Auch dies legt nahe, in Blender kleinere Teileinheiten zu gestalten und keine ganzen Regionen im Block.
- In Blender ist es nicht möglich, ein Objekt aus mehreren Meshes fest zu verbinden. Wenn man das Root-Mesh (Stichwort Parenting) bewegt, kommen die anderen Meshes mit. Wenn man aber ein Client-Mesh bewegt, wird das einzeln verschoben. Dies ist ein gewolltes Feature von Blender.
- Innerhalb einer Szene können mehrere Kopien des selben Objekts nur die selben Texturen tragen, anderenfalls werden es neue Objekte. In OpenSim sind wir aber gewohnt, ein Mesh beliebig zu "texturieren", ohne damit die Datenbank aufzublasen. (Letzteres gilt natürlich nur, falls die neue Textur eh schon im Grid ist.)
- Beim Export Richtung Unity tragen die Meshes keine Texturen. Diese müssen von Hand in Unity den einzelnen Oberflächen wieder zugeordnet werden. Dafür lässt sich bestimmt innerhalb von Unity ein Tool scripten, aber derzeit scheint noch nichts derartiges zu existieren.
- Beim Import nach OpenSim gibt es die Optionen "Generate Normals" und Berechnung von LoD-Leveln, die ggf. von einem OpenSim-Exporter irgendwie nachgestellt werden müssten. Der Aufwand ist vermutlich sehr groß. Ohne diese Features ist ein nackter Export meistens nicht so toll, zumindest bei meinen Blender-Meshes.
Zitieren
#3
2) Konstruieren einer Szene in Unity, exportieren nach OpenSim oder Blender.

Vorteile:
- In Unity Szenen zu gestalten ist eine wahre Freude. Das Tool ist professionell, mächtig und anwenderfreundlich.
- Es gibt unglaubliche Mengen von legalem Content zu kaufen. Content heißt hier, Lizenzen an den Grafikdateien des Künstlers zu erwerben im Gegensatz zu Binär-Objekten für eine spezielle Virtuelle Welt mit speziellen Community-Regeln (oder DRM).
- Das Tool ist bezüglich der Features auf dem Stand der Technik.

Nachteile:
- Es gibt keinerlei offizielle Exportmöglichkeit von Szenen. Man kann nur einzelne Meshes exportieren, Texturen liegen als Grafikdateien vor und sind daher sowieso exportierbar. Texturen und Meshes nach dem Export aber wieder zu Szenen zusammenzubauen, dafür müsste noch ein Programm entwickelt werden. Aufwand aus meiner Sicht jenseits von Gut und Böse.
- Jederzeit kann die Herstellerfirma entscheiden, keine gebührenfreie "Community-Edition" mehr anzubieten. Linux-Versionen gibt sowieso nur inoffiziell, solange sich in der Firma Entwickler finden aus dem Quellcode auch für Linux zu bauen (und das Management dieses nicht verbietet).
Zitieren
#4
3) Konstruieren einer Szene in OpenSim, exportieren nach (Blender oder) Unity.

Vorteile:
- Wir sind OpenSim gewöhnt.
- Einzel-Meshes können problemlos aus Blender importiert werden.
- Es gibt ein Tool, um Regionen von OpenSim nach Unity zu exportieren. (Test meinerseits steht noch aus.)

Nachteile:
- Die Grafik-Engine ist alt, die Ergebnisse können mit aktuellen Game-Engines nicht mithalten. Auch nach einem Export in Richtung z.B. Unity wird die Grafik natürlich nicht besser, weil die modernen Features in den OpenSim Quelldateien ja nicht vorkommen.
- Beim Export von OpenSim Richtung Unity gehen die Matrialien verloren, nur die Haupt-Texturen werden übernommen. Das Exporter-Programm der japanischen Universität (Open Source) könnte man sicherlich erweitern, aber das ist Aufwand. Aus meiner Sicht allerdings ist es "nur" Fleißarbeit, also machbar.
- Derzeit scheint die Entwicklung von OpenSim stillzustehen bzw. es handelt sich eher um "Verschlimmbesserungen". Sehr wenige Entwickler sind in dem Code noch aktiv, vermutlich weniger als 5.

Einen Export von Szenen in Richtung Blender habe ich bisher nicht näher untersucht. Wenn von Blender aus ein weiterer Export in Richtung einer Virtuellen Welt relevant würde, müsste dort ggf. noch mal nachgebohrt werden.
Zitieren
#5
Hallo Mareta ;D

Auf die Idee mit der Szene erstellen in OS und dann in Unity bzw. Blender, bin ich noch gar nicht gekommen. Das mit den Texturen find eich gar nicht so schlimm, würde halt diese in OS Szene wech lassen, halt nach dem Exportieren die Texturen drauf legen.
Nur bringt es mir eh zu der Frage, wielange noch an OpenSim entwickelt wird. Um eines vorraus zu schicken, ich will bin immer noch sehr zufrieden mit der jetzigen OpenSim version, davon abgesehen, das OS eigentlich nur noch für Event genutzt wird. Obwohl, wenn ich mir die Region GridTalk ansehe und was der Anachron draus gemacht hat. Er hat aus einen hässlichen Region, eine sehr schöne und ansehnliche Region gemacht, danke dafür

Aber das ist ja nicht das Thema hier ;D
Wenn OpenSim weiter leben soll, muss nach meiner Ansicht ne neue Grafikengine her, vielleicht werden so auch wieder mehr neue User anngelockt. Obwohl wenn ich mir ActiveWorlds anschau, da wo ich vor SL aktiv war, diese Virtuelle Welten gibts immer noch und die bestehen schonn seit gut 20 Jahren. Dazu gibt es noch so Forks wie Halcyon und WhiteCore-Sim. Dieses sollen nur beispiele sein, bitte nicht hier eine Diskussion um diese Forks anfangen ;D
Signatur
Have a nice Day ;D

>> BogusMusikRausch am 28.03.24 um 20 Uhr in Uwes KeulenBar

Tschöö

Bogus | PinguinsReisen.de | M: @gse@norden.social
Zitieren
#6
(24.07.2019, 23:24)Mareta Dagostino schrieb: 1) Konstruieren einer Szene in Blender, exportieren nach Unity oder OpenSim.
...
Nachteile:
- Beim Export Richtung Unity tragen die Meshes keine Texturen. Diese müssen von Hand in Unity den einzelnen Oberflächen wieder zugeordnet werden.

Das muss ich relativieren. Wenn man in Blender Matrialien anlegt und mit Texturen versieht und ein Objekt oder eine Szene aus Blender exportiert z.B. als .fbx oder als .blend, dann ist das Objekt auch nach einem Unity-Import noch texturiert. Es wird jeweils ein Standard Unity-Shader mit der in Blender verknüpften Textur erzeugt und die Oberflächen sind hinterher ganauso texturiert wie in Blender.

Folgende Nachteile verbleiben, und deshalb verwerfe ich diese Methode für mich:
- Es wird nur eine Textur übernommen, die "Albedo" (Unity) bzw. "Diffuse" (OpenSim). Normals und Specular können so nicht übergeben werden.
- Der Shader mit der Textur ist im .fbx gespeichert und kann so ohne weiteres nicht geändert werden. Man kann also nicht nachträglich Normals und Specular ergänzen, ohne das Unity-Prefab manuell aufzubrechen und neu zusammenzubauen (s.u.).
- Jede .fbx Datei wird mit Texturen aufgebläht, statt sie irgendwo zentral zu sammeln. Auch zur Laufzeit würde dann die Szene und die Welt (Grid) unnötig mit vielen Kopien der eigentlich selben Textur belastet!

-----------------

Ansonsten funktioniert der Transfer von Objekten (auch aus mehreren Meshes) wunderbar als .fbx - Datei von Blender nach Unity und umgekehrt. Ein möglicher Workflow Blender=>Unity für mich wäre:
Objekte
1) Objekt in Blender erstellen. Dabei UV-Map erzeugen, ggf. mit provisorischen Materialien um zu sehen, ob's passt.
2) Materialien in Blender aus dem Objekt löschen, sonst blähen sie unnötig die .fbx Datei auf.
3) Ordentliche Namen für jedes Mesh vergeben, so heißt das Zeug hinterher in Unity!
4) Objekt als FBX aus Blender exportieren. Ein solches Objekt kann aus einem oder mehreren Meshes bestehen. Wird Parenting verwendet, dann gibt es später auch in Unity eine Hierarchie ("Rootprim", "Childprims").
Texturen
1) Alle Texturen irgendwie systematisch in Unterordnern von "Assets/Textures" anordnen, also ins Unity-Projekt kopieren.
2) Auf einem der vielen möglichen Wege jeweils ein Material "Standard (Specular Setup)" erzeugen. Dort die passenden Albedo, Normal, Specular Texturen einarbeiten.
3) Alle Materialien in der gleichen Struktur speichern wie die Texturen, sonst sucht man sich den Wolf. Diesmal unter "Assets/Materials" .
Verknüpfung
1) In der Szene die gewünschten Materialien auf die jeweiligen untexturierten Oberflächen ziehen, so wie man es mit Texturen in OpenSim machen kann. (Hier muss man das nicht für Normals und Specular wiederholen, weil das Material bereits fertig vorbereitet ist.)
2) Aus dem dekorierten Objekt ein neues Prefab machen (aus der Scene-Hierarchy in die Project-Hierarchy kopieren).
3) Das untexturierte Prefab aus dem Import kann nun gelöscht werden.
Zitieren
#7
Ergänzung: In Richtung Blender=>OpenSim geht der obige Ablauf leider nicht ganz so einfach, es ist ziemlich viel Handarbeit im OpenSim Importmenü und OpenSim Baumenü nötig:
Objekte
1) Objekt in Blender erstellen. Dabei UV-Map erzeugen, ggf. mit provisorischen Materialien um zu sehen, ob's passt.
2) Die Texturen sollten nur einmal ins Grid importiert werden, nicht mit jedem Objekt wieder neu. Vor dem Export brauchen die provisorischen Materialien aber nicht gelöscht zu werden, sie können beim Export abgewählt oder einfach nach dem Export auf der lokalen Festplatte ignoriert werden.
3) Jedes Mesh muss einzeln exportiert werden. Wird ein Objekt aus mehreren Meshes exportiert (Parenting oder Mehrfachselektion), dann kommt es in OpenSim als ein einzelnes Mesh an! Also ggf. Objekte vor dem Export auftrennen.
Texturen
1) Alle Texturen irgendwie systematisch in Unterordnern des Inventars anordnen, also in OpenSim importieren.
Verknüpfung
1) Nach dem Rezzen im Baumenü die einzelnen Flächen selektieren und die jeweils passenden Materialien (Diffuse, Normals, Specular) einzeln zuordnen.
2) Aus den importierten Einzelmeshes ggf. wieder ein zusammenhängendes Objekt machen (Rootprim, Childprims).
3) Rechte usw. einstellen und strukturiert im Inventar ablegen.
Zitieren
#8
Weiter oben hatte ich erwähnt der Test meinerseits stehe noch aus, deshalb nun:

Test des Exporttools OAR=>Unity aus dem Network System Laboratory of TUIS

Installation (Ubuntu Linux 18.04):

Für diesen Kurztest habe ich den angebotenen Binärdownload gewählt, also v1.4.0 statt die aktuelle v1.4.4.

Heruntergeladenes Zipfile ins eigene Homeverzeichnis entpacken

Aufruf probieren: ~/oarconv/oarconv.sh

Jetzt meckert es vermutlich diverse fehlende Bibliotheken an (*.so.*), die passenden Pakete müssen nachinstalliert werden. Am besten mit der Suchmaschine des Vertrauens auf die Jagd auf den Paketnamen gehen. Nur im absoluten Notfall etwas installieren, was nicht in der eigenen Linux-Distribution enthalten ist. Bei meinem Ubuntu 18.04 waren keine Fremdpakete nötig.

Problem: libcrypto.so.10

Dieses alte Dings gibt es nicht mehr, wer referenziert da explizite Versionen? Abhilfe:

1) Sicherstellen, dass die notwendigen Pakete installiert sind (oft bereits vorhanden):
sudo apt-get update
sudo apt-get install libssl libssl-dev

2) Im Verzeichnis "/lib/x86_64-linux-gnu" etwas möglichst ähnliches suchen und einen Link setzen, bei mir war das
cd /lib/x86_64-linux-gnu
sudo ln -s libcrypt-2.27.so libcrypto.so.10

Wenn obiges Kommando nichts mehr ausgibt, aber im Homeverzeichnis ein Ordner "DAE" entsteht, dann ist es gut geworden.

Benutzen (Option -h gibt Hilfe aus):

Das OAR in z.B. ein Verzeichnis "~/TestOAR" entpacken. Die Unterverzeichnisse in (hier) TestOAR müssen bereits die XML-Dateien und OAR-Unterverzeichnisse sein, nicht wie bei manchen Entpackertools erst mal ein Ordner mit dem Namen der gepackten Datei.

~/oarconv/oarconv.sh -i TestOAR -d

Jetzt rödelt das Tool eine Weile rum und wegen der angegebenen Debug-Option gibt's auch reichlich Textausgaben.

Am Ende ist der Ordner ~/DAE mit allerlei Zeug gefüllt. Diesen Ordner dann in ein Unity-Projekt kopieren, als Unterverzeichnis des "Assets" Ordners. Dort empfehle ich vor dem Start von Unity den Ordner sinnvoll umzubenennen, DAE ist irgendwie nichtssagend.

Beim nächsten Start rödelt Unity heftig rum und konvertiert die Dateien in sein Format. Der Lüfter (oder wetterbedingt eher Föhn?) kriegt Arbeit und am Ende... Voila!

Region in Unity erstellen:

1) Allen Inhalt im Verzeichnis "DAE" (bzw. umbenannt) in eine leere Unity-Szene kopieren. Nicht einzelne Objekte im Baufenster platzieren, das würde ja einem Neubau entsprechen. Also im Projekt-Menü alle Prefabs selektieren, und dann mit der Maus ins Szenen-Hierarchie-Menü schieben.

2) Das selbe mit dem Unterverzeichnis "Phantoms" machen, da sind zum Beispiel meine Bäume und mein Geschirr drin, also alles was in OpenSim auf Phantom stand.

   
Zitieren
#9
Bewertung des Workflows aus meiner Sicht:

Vorteile:
- Import sehr einfach, die haben klasse Arbeit gemacht in Japan. Smile
- Alles ist fertig texturiert, aber die Texturen werden ordentlich in einem separaten Ordner geliefert. Es ist also nicht (wie weiter oben beim .fbx Import beschrieben) in jedem Prefab eine individuelle Textur drin.
- Objekte aus mehreren Meshes (Rootprim, Childprims) behalten in Unity ihre Hierarchie. Sie werden also nicht in Einzelobjekte zerlegt, und auch nicht in ein gemeinsames Mesh zusammengefügt.

Nachteile:
- Es werden nur die "Diffuse" bzw. "Albedo" Texturen übernommen.
- Jedes Objekt ist ein eigenes Prefab. Habe ich in der Herberge 20 Betten und 100 Flaschen Wein, dann gibt es jetzt entsprechend viele Prefabs mit Kopien von immer den selben Meshes und nur anderen Positionsdaten.
- Entsprechend kann auch nur jedes Objekt einzeln geändert werden. Wollte ich jetzt die "Normals" und "Specular" Texturen von Hand ergänzen, müsste ich das für jedes gerezzte Objekt tun, also für alle 20 Betten und 100 Weinflaschen...
- Die Prefabs und Texturen haben sehr lange Namen, weil die jeweilige OpenSim GUID und mehrere numerische Zähler angefügt werden. Meine über 60 Stühle auf der Region kann man also nur z.B. unterscheiden an beispielsweise: "tavern_chair1_101-061-033__e01a73bd-3e91-46ab-89c3-1a9598f2d75a" oder "tavern_chair1_067-060-028__2a1dbf89-ea06-4400-b064-38def53cfb80".
Zitieren
#10
Klasse Arbeit, Mareta.Smile
Zitieren


Gehe zu:


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