Beiträge: 1.547
Themen: 74
Thanks Received: 786 in 337 posts
Thanks Given: 377
Registriert seit: May 2013
Der Unity-Exporter ist ein separates Projekt, ein Hilfstool und nicht Teil von Third Room. Ich denke, einen Exporter könnte man relativ einfach auch für andere geeignete Tools schreiben, die Entwickler kannten sich vermutlich mit Unity am besten aus und haben dann halt das verwendet. Die Unity Game-Engine wird ja gar nicht benutzt. Unity dient lediglich als Editor, um eine Szene aus diversen glTF 2.0 Meshes zusammenzustellen, und die fertige Szene nach Third Room zu exportieren.
Übrigens: Unity verlangt Runtime-Gebühren nur von größeren Firmen, die eh nicht die kostenlose Personal-Version verwenden dürfen. Außerdem entstehen mit dem obigen Exporter keine Unity-Runtimes.
Beiträge: 7.021
Themen: 774
Thanks Received: 1.351 in 665 posts
Thanks Given: 3.495
Registriert seit: Jul 2010
@Magreta: Benutzt nicht Overte auch Unity ? Hab irgendwo sowas gelesen ;D
Dann könnte man doch auch mit Blender eine Szene erstelllen für Thirdroom oder irre ich mich da ?
Beiträge: 1.547
Themen: 74
Thanks Received: 786 in 337 posts
Thanks Given: 377
Registriert seit: May 2013
Also wenn ich bei "Szene" an eine ganze Region denke, dann möchte ich persönlich das nicht in Blender erstellen. Das wird schnell sehr unübersichtlich. Aber Godot z.B. ist auch Open Source und arbeitet sehr eng mit Blender zusammen. Also technisch gesehen ja, man könnte auch einen Blender-to-Thirdroom-Exporter programmieren.
In Overte habe ich Unity nur als eine Alternative gefunden, Avatare zu erzeugen. Da gibt es aber auch einen " Avatar Packager" direkt im Interface, also dem "Viewer". Eine Importmöglichkeit für komplette Szenen aus Fremdtools gibt es in der offiziellen Doku nicht. Es kann natürlich sein, dass da jemand was programmiert hat. Der normale Weg geht über den Import von Objekten, die dann inworld ausgerichtet werden, ganz analog zu OpenSim.
Beiträge: 87
Themen: 7
Thanks Received: 72 in 35 posts
Thanks Given: 41
Registriert seit: Sep 2023
Es wird keine Unity Engine verwendet? Das Basketball spiel läuft also anders? Unity ist dann also nur wie Blender im Einsatz?
Beiträge: 1.547
Themen: 74
Thanks Received: 786 in 337 posts
Thanks Given: 377
Registriert seit: May 2013
1) Mit irgendwas müssen die Meshes erzeugt werden, z.B. Blender. Das geht nicht direkt in Unity, außer man kauft Objekte im Store oder importiert sie von irgendwo.
2) Dann muss eine Szene aus vielerlei Objekten erstellt werden, z.B. das Basketballfeld. Momentan ist es wohl noch nicht möglich, die einzelnen Objekte nach Third Room zu importieren, und dann inworld zu positionieren, so wie in OpenSim und Overte. Aber es war wohl vor der Pause schon was in Entwicklung, vielleicht kommt das Feature noch.
Man kann nach aktuellem Stand eine Szene nur in externen Tools vorbereiten und als große binäre glTF 2.0 Datei (.glb) importieren. Dafür haben die Entwickler ein separates Tool programmiert, den Unity-Exporter. Man gestaltet die Szene (z.B. das Basketballfeld) im Editor von Unity. Mit dem Exporter, der technisch ein Unity-Plugin ist, werden die Objekte dann in glTF umgewandelt und das Ergebnis nochmals in eine komprimierte glTF Binärdatei zusammengepackt.
=> Es wird der Editor von Unity verwendet, nicht die Game-Engine von Unity.
=> Die glTF Binärdatei könnte auch mit anderen - noch nicht programmierten - Plugins aus anderen geeigneten 3D Editoren exportiert werden.
3) Die irgendwie extern erzeugte glTF Binärdatei wird nach Third Room importiert. Third Room verwendet die Manifold Engine als Game-Engine, sie ist eine Eigenentwicklung und direkt in die Quelldateien von Third Room integriert.
Beiträge: 87
Themen: 7
Thanks Received: 72 in 35 posts
Thanks Given: 41
Registriert seit: Sep 2023
Danke für die Aufklärung. Dann nochmal um es für mich verständlich zu machen:
Dann kann man also wie Bogus schon sagte einfach in Blender alles bauen und dann mit dem Unity editer eine Sim zusammenstellen und dann mit dem Unity Exporter dann in Thridroom als eigenen Room/sim hochladen.
zusätzliche Frage:
Die Engine (Manifold Engine von thirdroom) wird dann auch automatisch von diesen Objekten unterstützt und getragen, sodass man dann auch scripts im Editor einsetzen kann, die dann mit den Objekten hochgeladen werden?
Beiträge: 1.547
Themen: 74
Thanks Received: 786 in 337 posts
Thanks Given: 377
Registriert seit: May 2013
(Bitte bedenke bei meinen Antworten, dass das alles nur auf der Doku basiert. Third Room setzt auf die Matrix Infrastruktur auf, und einen Matrix-Server kann ich nicht mal schnell an einem Nachmittag aufsetzen, um da selber was auszuprobieren. Das würde ich dann machen, wenn das Projekt Fahrt aufnimmt.)
(07.10.2023, 11:50)Cheryl Furse schrieb: Dann kann man also wie Bogus schon sagte einfach in Blender alles bauen und dann mit dem Unity editer eine Sim zusammenstellen und dann mit dem Unity Exporter dann in Thridroom als eigenen Room/sim hochladen.
Ja, das ist wohl derzeit der übliche Weg eine Szene ("Region") zusammenzustellen. Man könnte theoretisch auch andere Tools nehmen, aber bisher wurde nur ein Unity-Exporter programmiert. Womit man die einzelnen Mesh-Objekte baut, ist schon jetzt dem eigenen Geschmack überlassen. Wikipedia nennt außer Blender unter anderem noch Maya, Houdini, sogar Paint 3D von Windows.
Zitat:Die Engine (Manifold Engine von thirdroom) wird dann auch automatisch von diesen Objekten unterstützt und getragen, sodass man dann auch scripts im Editor einsetzen kann, die dann mit den Objekten hochgeladen werden?
Wie ich das verstanden habe, füllt man die Laufzeit-Scripte inworld ein, oder beim Hochladen der Szene. Geplant ist ein zukünftiger Standard, um auch interoperable Scripte in glTF speichern zu können, aber das ist noch in der Abstimmungsphase. https://github.com/omigroup/omi-scripting-group. Momentan wird das WebSG API verwendet, wobei Third Room die erste Implementierung dieses API ist. (Also noch kein allgemein genutzter Standard...) Unity nutzt C# für Inworld-Scripte, Third Room hingegen JavaScript. Also schon sprachlich gesehen können Untiy-Scripte nicht in Third Room laufen.
Beiträge: 87
Themen: 7
Thanks Received: 72 in 35 posts
Thanks Given: 41
Registriert seit: Sep 2023
C++ ist nicht so unterschiedlich zu Java, meines Wissens nach. C# ist wie C++?
Beiträge: 1.547
Themen: 74
Thanks Received: 786 in 337 posts
Thanks Given: 377
Registriert seit: May 2013
07.10.2023, 13:12
(Dieser Beitrag wurde zuletzt bearbeitet: 07.10.2023, 13:25 von Mareta Dagostino.)
Die Unterschiede zwischen C++ und Java sind die größten zwischen den von dir genannten Sprachen. Aber hier geht es ja nicht darum, ob ein programmierender Mensch umlernen kann, sondern um einen Importer. Da wird man nicht in einer Sprache programmieren und das beim Import automatisch in eine andere Sprache übersetzen - schon gar nicht bei einem Hilfstool, das eher aus der Not heraus geboren ist.
Eigentliches Ziel der Veranstaltung ist ja, Open Source Schnittstellen für ein 3D Web zu etablieren, damit ein künftiges Metaversum unabhängig von bestimmten Anbietern oder bestimmter Software funktioniert. Third Room ist sozusagen eine Machbarkeitsstudie, ein Prototyp um außer Dokumenten auch was Greifbares vorzeigen zu können. Zitat aus der Doku: "We're focused on building out a browser-based client in JavaScript, but we've seen a lot of interest in building out alternate clients in Godot, Unity, and Unreal. If you're interested in building a Third Room client or integrating the WebSG API into your own application, please reach out on Matrix. There you'll find other like-minded people interested in building out the WebSG ecosystem."
EDIT: Man wird aus Sicherheitsgründen keine Binärdateien von Unbekannten auf den Rechnern der Anwender erlauben können. Also keine der Sprachen C++, Java, C#. Deshalb ist im Web ja fast alles mit JavaScript gemacht, denn ein Interpreter dafür ist in nahezu jedem Browser schon eingebaut. Man braucht keine Sicherheitswarnung wegklicken, um dem Browser die Ausführung von fremdem Binärcode zu erlauben... Anders ist das bei Viewern, die nicht im Browser laufen, sondern auf dem Computer installiert werden (z.B. OpenSim, Overte). Die können machen, was sie wollen, denn mit der Programminstallation hat man ihnen das volle Vertrauen gegeben. Aber aus den selben Gründen wie beim Browser erlauben auch OpenSim und Overte den Anwendern nur die Ausführung von Scripten, nicht die Ausführung von binärem Code. (In der OpenSim.ini kann man das Ausführen von Binärdateien erlauben, aber da steht auch eine sehr sehr deutliche Warnung im Kommentar zu dem Parameter.)
Beiträge: 7.021
Themen: 774
Thanks Received: 1.351 in 665 posts
Thanks Given: 3.495
Registriert seit: Jul 2010
Moin zusammen ;D
Also mich würde auch nur ein eigener Server neugierig machen auf Thirdroom. Aber das man da nun extern die Szenen bauen muss und dann uploaden soll, erinnert mich sehr an ActiveWorlds, wo man aber nicht ganze Szenen hochlädt, sondern halt nur die Objekte, obwohl die Objekte da auch auf einen eigenen Server oder webspace oder so lagern können. Bin da einige Jahre aktiv gewesen und war meine erste 3D Welt Erfahrung, bis ich 2006 ... ja richtig 2006 zu SL kam und ich mich wie im Paradies fühlte, da man da online bauen konnte, ohne was hochzuladen, obwohl ja da auch die Texturen hochladen muss, wenn man welche braucht tut tut ;D
Für mich persönlich ist Thirdroom nicht so in moment was mich sooo sehr neugierig macht. Wie Magreta schon schrieb, das Projekt muss bisschen noch wachsen und werde auch nicht in den Hysterie verfallen zu Thirdroom wechseln zu wollen, obwohl ich hier in OpenSim ja mit GridTalk auch ein klein wenig Pionier arbeit geleistet hab. Bin wohl kein Builder vor dem Herrn, aber halt so extern mit GridTalk doch für User ein kleine Plattform geschaffen ;D
Natürlich ist GridTalk ohne den ganzen UserContent ein nichts ;D
Nun, aber genug der Selbstbeweihreucherung ;D
|