Open-Source 3D Engines

[Rampage]

Hi,

kennt einer von euch gute Open-Source 3D Engines? Gibt es eine, die zumindest an die Features bzw. die Grafikleistung der Q3-Engine rankommt?

Ich fände es ziemlich cool, wenn sich ein paar Profis hinsetzten würden und ein D3/UE3 Konkurrent basteln würden. :tongue:

Das würde IMO der Spieleindustrie ganz gut tun...

[Gast]

Die Quake3-Engine wird bald OpenSource GPL.

Eigentlich hätte es schon längst sein sollen, aber da haben kurz davor noch welche sich eine Lizenz gekauft. Deswegen haben sie es verschoben.

[micki]

Hi,

kennt einer von euch gute Open-Source 3D Engines? Gibt es eine, die zumindest an die Features bzw. die Grafikleistung der Q3-Engine rankommt?

Nebula device ist eine solche, eine andere gute ist Fly3D(2), kann sogar die kompletten Q3 maps reinladen (und natürlich fehlerfrei anzeigen).

dann gibt es noch http://www.tenebrae2.com/ die gut ist. graphisch gut ist, aber wohl nicht mehr als ein prototyp ist.


Ich fände es ziemlich cool, wenn sich ein paar Profis hinsetzten würden und ein D3/UE3 Konkurrent basteln würden. :tongue:
wieso sollten sie ihr hart erarbeitetes wissen (und den hard erarbeiteten source) verschenken? wenn es konkurenzfähig wäre, dann kann man damit auch einiges an geld verdienen.
Zudem macht heutzutage nicht nur der engine source an sich eine gute engine aus, sondern eher die tools und der workflow den sie definieren. Die beste OS engine wäre meiner meinung nach NebulaDevice und sogar die haben "nur" eine integration in maya zu bieten und keinen eigenen editor.

ich würde jedenfalls nicht 2-3 jahre 16h arbeit am tag investieren nur damit es OS wird und verstehe die leute auch nicht die sowas machen würden. bei nem mailprogramm oder betriebssystem kann ich das ja noch verstehen, da bringt die community mehr, aber die wenigsten programmierer sind fähig eine engine zu coden die für mehr als ein buch reicht.


Das würde IMO der Spieleindustrie ganz gut tun...
wieso das?

MfG
micki

[Mr. Tweety]

Und dann gibt es noch NeL von Nevrax.
Den Entwicklern von Ryzom.
Ist aber wohl eher für MMORPG's gedacht.


For Immediate Release

Paris, France – January 31, 2005 – Nevrax, developer of the ground-breaking massively multiplayer online role-playing game (MMORPG) The Saga of Ryzom, announced today new commercial offerings for its open source MMORPG engine NeL. Short for Nevrax Library, NeL is a dynamic toolkit for the development of massively multiplayer online worlds. It provides the base technologies and a set of development methodologies for the creation of both client and server code.

Und hier der Link: http://www.nevrax.org/tiki-index.php

[Simon]

kennt einer von euch gute Open-Source 3D Engines? Gibt es eine, die zumindest an die Features bzw. die Grafikleistung der Q3-Engine rankommt?
Da wäre z.B. OpenSceneGraph (sehr geiles Teil), Ogre3D, CrystalSpace. Die Q3-Engine an sich ist kein Problem (Ok, ok, der Grafikteil!): Das wichtigste an diesem Paket ist Map Compiler vom gtkradiant und da wiederum die Beleuchtungslösung. Der restliche Grafikteil ist auch nicht sonderlich kompliziert, im Gegenteil. Den Netzwerk/Input-Teil kann man z.B. von der Q2-Engine abgreifen oder man baut diese entsprechend um. Fertig ist der Q3-Klon..


Ich fände es ziemlich cool, wenn sich ein paar Profis hinsetzten würden und ein D3/UE3 Konkurrent basteln würden. :tongue:
Was ist an D3 so schwer? Die papers zu den Stencil Shadows gibts im Netz, Bump Mapping genau so und die restlichen Effekte auch. Aus Sicht eines Programmierers nicht sonderlich kompliziert (ok ok, John Carmack hatte es damals schwerer weil die ganzen Stencil Shadow Technologien noch nicht vorlagen). Was den meisten Hobby-/OS-Projekten fehlt, sind (sehr) gute Modeller (inkl. Grafikern und Level Designern)!!

Das würde IMO der Spieleindustrie ganz gut tun...
Inwiefern???

Eine Engine definiert sich heutzutage viiiiel weniger über graphische Möglichkeiten (analog dazu Sound, Netzwerk, etc.), sondern nur über die Tools dazu und vll. noch KI...

[micki]

Da wäre z.B. OpenSceneGraph (sehr geiles Teil), Ogre3D, CrystalSpace. Die Q3-Engine an sich ist kein Problem (Ok, ok, der Grafikteil!): Das wichtigste an diesem Paket ist Map Compiler vom gtkradiant und da wiederum die Beleuchtungslösung. Der restliche Grafikteil ist auch nicht sonderlich kompliziert, im Gegenteil. Den Netzwerk/Input-Teil kann man z.B. von der Q2-Engine abgreifen oder man baut diese entsprechend um. Fertig ist der Q3-Klon..
jap, solche versuche gab es auch zuhauf, leider haben die meißtens nichtmal 50% der performance der Q3 engine, dabei sind viele nur aufs rendering beschränkt und der ganze rest fehlt ja noch, trotzdem viel langsammer.


Was ist an D3 so schwer? Die papers zu den Stencil Shadows gibts im Netz, Bump Mapping genau so und die restlichen Effekte auch. Aus Sicht eines Programmierers nicht sonderlich kompliziert (ok ok, John Carmack hatte es damals schwerer weil die ganzen Stencil Shadow Technologien noch nicht vorlagen). Was den meisten Hobby-/OS-Projekten fehlt, sind (sehr) gute Modeller (inkl. Grafikern und Level Designern)!!
ja, das denkt sich jeder der ein buch über spieleprogrammierung gelesen hat. eigentlich ist es doch sau einfach z.b. battlefield zu coden. ein bissl heightmap rendern, ein paar gegenstände fest reinsetzen. kollisionsabfrage mit terrain und boundingboxen, netzwerkcode, fertig.

die meisten, die solche engines anfangen, egal ob anfänger oder studierte informatiker, machen sich ja noch nichtmal die mühe bestehende engines zu inspizieren und deren designlösungen zu verstehen. Es wird sich irgend ein algorithmus geschnappt und drauflosegecodet ohne planung.




Eine Engine definiert sich heutzutage viiiiel weniger über graphische Möglichkeiten (analog dazu Sound, Netzwerk, etc.), sondern nur über die Tools dazu und vll. noch KI...
ja ganz mein reden ;), das ganze Konzept muss stimmen, davon ist die "core engine" die dann auch ausgeliefert wird sicherlich <25% der arbeit.

MfG
micki

[Corrail]

Was ist an D3 so schwer? Die papers zu den Stencil Shadows gibts im Netz, Bump Mapping genau so und die restlichen Effekte auch.

Ähm...
Ich programmiere grad im Rahmen eines Uni-Projektes ein Computerspiel (Ein (http://stud4.tuwien.ac.at/~e0326156/42/Screenshots/2005_05_04__01.png) paar (http://stud4.tuwien.ac.at/~e0326156/42/Screenshots/2005_05_04__02.png) Screen (http://stud4.tuwien.ac.at/~e0326156/42/Screenshots/2005_05_05__01.png)-Shots (http://stud4.tuwien.ac.at/~e0326156/42/Screenshots/2005_05_05__02.png)) und verwende hierfür das MD5 Format für die Models. Und wenn du meinst, dass das nicht so schwer sein kann irrst du dich gewaltig!! Ich hab mir am Anfang auch gedacht: Ok, cool. Hab schon ein paar Bump Mapping Demos geschrieben, ein paar Shadow Demos, ... Das wird shcon nicht so schwer sein. Das Problem an dem ganzen sind allerdings weniger die Effekte. Davon gibt es genug Papers. Das Problem ist eher alles unter einen Hut zu bekommen und noch zu schaun, dass das ganze perfomant ist.
Ein kleines Beispiel: Als ich den MD5 Loader geschrieben hab, hat alles schön funktioniert. Framerate jenseits der 500, keine Probleme. Als ich dann aber die Animationen dazugeschrieben hab ist auf einmal die Framerate auf 10 FPS runtergefallen, weil ich pro Animationsupdate für jeden Vertex des Models die Transformation für Eckpunkt, Normal, Tangent und Binormal auf der CPU berechnen muss. Das ganze auf die Grafikkarte zu verlagern hätte nicht viel genützt, da ich bis zu 3*6=18 3D-Vektoren pro Vertex an den Vertex Shader schicken müsste. Dazu jetzt noch die in Doom 3 verwendeten Shadow Volumes, die John Carmack auch auf der CPU berechnen lässt...

(ok ok, John Carmack hatte es damals schwerer weil die ganzen Stencil Shadow Technologien noch nicht vorlagen)

Für Shadow Volumes (Stencil Shadows) brauchst du nicht mehr als einen 8Bit Hardware Stencil Buffer (Software geht natürlich auch, ist aber nicht sehr zu empfehlen *gg*) und den gibt es mindestens seit der GeForce 256 (wenn nicht sogar schon länger, weiß es nicht so genau).
Und das Tech-Paper ist im Jahre 1991 (Tim Heidmann, "Real Shadows", http://developer.nvidia.com/attach/6833).

[micki]

Ähm...
Ich programmiere grad im Rahmen eines Uni-Projektes ein Computerspiel (Ein (http://stud4.tuwien.ac.at/~e0326156/42/Screenshots/2005_05_04__01.png) paar (http://stud4.tuwien.ac.at/~e0326156/42/Screenshots/2005_05_04__02.png) Screen (http://stud4.tuwien.ac.at/~e0326156/42/Screenshots/2005_05_05__01.png)-Shots (http://stud4.tuwien.ac.at/~e0326156/42/Screenshots/2005_05_05__02.png)) und verwende hierfür das MD5 Format für die Models.

wow, das schaut ja wie ein battlefield clone aus ;)


Das ganze auf die Grafikkarte zu verlagern hätte nicht viel genützt, da ich bis zu 3*6=18 3D-Vektoren pro Vertex an den Vertex Shader schicken müsste. Dazu jetzt noch die in Doom 3 verwendeten Shadow Volumes, die John Carmack auch auf der CPU berechnen lässt...
wenn man ein geskinntes objekt zeichnet, muss man normalerweise nur die bones als konstanten in den shader geben, der rest der berechnungen läuft dann im VS.
ich hab es gemacht und es bringt sehr viel performance, genau so langsam wie die berechnungen, sind die bufferlocks die man hat wenn man es auf der cpu macht. mag sein dass JC das auf der cpu macht, aber es gibt auch einige engines die das auf der GPU machen. und im polygonreichtum der figuren hinkt Doom3 anderen engines sehr hinterher. aber JC macht das deswegen mit der cpu, weil er die polygongenaue kollisionsberechnung auf der cpu machen muss und deswegen eh die meisten berechnungen schon durchführt, da kann es ökonomischer wirken den rest dann gleich mitzumachen.



Für Shadow Volumes (Stencil Shadows) brauchst du nicht mehr als einen 8Bit Hardware Stencil Buffer (Software geht natürlich auch, ist aber nicht sehr zu empfehlen *gg*) und den gibt es mindestens seit der GeForce 256 (wenn nicht sogar schon länger, weiß es nicht so genau).
Und das Tech-Paper ist im Jahre 1991 (Tim Heidmann, "Real Shadows", http://developer.nvidia.com/attach/6833).aber erst durch carmacks revers trick wurden die doch praktikabel, oder sehe ich da was falsch?

MfG
micki

[Corrail]

wow, das schaut ja wie ein battlefield clone aus ;)

Danke für die Blumen ;)
Soll aber ein Adventure werden.


wenn man ein geskinntes objekt zeichnet, muss man normalerweise nur die bones als konstanten in den shader geben, der rest der berechnungen läuft dann im VS.
ich hab es gemacht und es bringt sehr viel performance, genau so langsam wie die berechnungen, sind die bufferlocks die man hat wenn man es auf der cpu macht. mag sein dass JC das auf der cpu macht, aber es gibt auch einige engines die das auf der GPU machen. und im polygonreichtum der figuren hinkt Doom3 anderen engines sehr hinterher. aber JC macht das deswegen mit der cpu, weil er die polygongenaue kollisionsberechnung auf der cpu machen muss und deswegen eh die meisten berechnungen schon durchführt, da kann es ökonomischer wirken den rest dann gleich mitzumachen.

Das Problem bei MD5 ist allerdings, dass ein Vertex in bis zu 6 Bones sein kann. Und das wird dann ein wenig problemtisch am Vertex Shader... ;)

aber erst durch carmacks revers trick wurden die doch praktikabel, oder sehe ich da was falsch?

Normale Shadow Volumes machen Probleme mit der Near und mit der Far Plane. John Carmack hat dann (unter anderem) die "Carmacks Reverse" entdeckt. Ich bild mir aber ein mal wo gelesen zu haben, dass auch wer anderer das schon gemacht hat, also dass dieser Trick nicht von ihm kommt (auch wenn er selbst draufgekommen ist, siehe http://developer.nvidia.com/attach/6832).

[catamaran]

Für Shadow Volumes (Stencil Shadows) brauchst du nicht mehr als einen 8Bit Hardware Stencil Buffer (Software geht natürlich auch, ist aber nicht sehr zu empfehlen *gg*) und den gibt es mindestens seit der GeForce 256 (wenn nicht sogar schon länger, weiß es nicht so genau).


AFAIK gibt es einen 8 Bit Stencil bereits seit der TNT1. Tim Sweeny hatte es bezüglich Unreal damals schon angedacht (in irgendeinem Interview hatte er es jedenfalls erwähnt).

Papers bezüglich Stencil-Shadows gibt es schon seit Urzeiten. Die Frage ist vielmehr, wie verpacke ich alles sinnvoll in eine sinnvolle Struktur, einen Scenegraphen, Materialmanagement (shader etc..), Optimierungen (Quadtree, BSP, etc..), Kollission... die Liste kann man ewig fortführen.
Es ist kein großes Problem einen 3D Loader zu schreiben und ein Modell anzuzeigen - vom Spiel ist man aber immer noch so unglaublich weit entfernt.

[micki]

Das Problem bei MD5 ist allerdings, dass ein Vertex in bis zu 6 Bones sein kann. Und das wird dann ein wenig problemtisch am Vertex Shader... ;)
geht eigentlich recht gut im shader. man hat ja nicht pro vertex individuelle 6bones, sondern shared sie für das ganze mesh, sodass man dann vielleicht auf 100 einträge im constantregister für die matritzen kommt. das geht recht gut.


Normale Shadow Volumes machen Probleme mit der Near und mit der Far Plane. John Carmack hat dann (unter anderem) die "Carmacks Reverse" entdeckt. Ich bild mir aber ein mal wo gelesen zu haben, dass auch wer anderer das schon gemacht hat, also dass dieser Trick nicht von ihm kommt (auch wenn er selbst draufgekommen ist, siehe http://developer.nvidia.com/attach/6832).
ja sowas hatte ich auch irgendwo mal gehört, aber fakt ist, dass er sich die arbeit machte es praktikabel zu machen u.a. durch seinen reversetrick.

MfG
micki

[Gast]

Auf Sourceforge gibts 3D-Engines wie Sand am Mehr, alleine 3 in C#, ca. 20 in C++.

[Gast]

Eine sehr gute Engine ist auch Irrlicht http://irrlicht.sourceforge.net/

Zwar nicht OpenSource aber sehr günsting(bedenkt man den günstigen $ Kurs) ist auch Torque. http://www.garagegames.com/
Die Engine rennt unter Win, Mac & Linux.
Besonders die TSE (demächst wird Meinestein 2 erreicht) mit der neuen
Landscape Engine (Bilder dazu sollten in den nächsten Tagen kommen) ist genial.

lg Mario

[LordMarshal]

http://www.nexuiz.com

modifizierte quake-engine, content ebenfalls gpl. sollte (d)einem q3-clone schon ziemlich nahe kommen...

edit: habe gerade den nexuiz-link auf der haupt-seite gesehen, gar nicht weit vom forum-news link ;)