Naja... da sind ja nicht nur die GML Aspekte des Games vorhanden, die Grundengine an sich ist in einer Stunde betriebsbereit
Die Models, Texturen, Sounds etc. verschlingen die meiste Zeit bei solch einem großen Projekt.
Also...
"Its done, when its done"

MfG Shadow

Ich hab zwar noch nie 3D gemacht aber ich denke ma es wär möglich aber mit sehr lowen FPS bei den meisten 3D Games wird nämlich draufgesetzt mit möglichst wenig Bildern den grösst möglichen effekt zu erzielen(z.b. wie bei Wolfenstein ET) oder HALO das ist eig nicht viel wenn man hinter die fassade gugt egal welches 3D game man nimmt die engines sind so bestückt wie zahnräder sie lösen sich gegenseitig aus.

Bei dem GM ist es naja anders es arbeitet über ein Basis Starter Kit er läd auch sachen die man vllt. grade mal nicht braucht und erhöht somit die gebrauchte zahl an kraft und sinkt in der Qualität;

Fazit:
Ja schon aber sehr langsam und wenn es schnell gehen soll mit low Frame(wenig Formen)

Meines Wissens nach unterstützt der Game Maker (zumindest der jetzige) 3D.
Es gibt auch Programme (z.B. Marzipan), die .obj-Dateien in GML umwandeln; du modellierst also in einem Programm wie Blender, speicherst dein Projekt als obj-Datei, konvertierst mit Marzipan und packst den erhaltenen Code in ein Script in Game Maker.
Wie das genau funktionier weiß ich nicht, aber guck mal unter der Suche, da findest du bestimmt etwas!
Theoretisch wäre es also schon möglich ein akzeptables 3D-Game zu erstellen. Wie lange das dauern würde...
Nun ja, guck dir mal die großen Firmen an. Selbst die brauchen so ein Jahr, wenn nicht länger, für einen Kassenschlager. Und da sehe ich noch das Problem mit dem Room-Editor, der ja leider 2D ist.
Aber befass dich erstmal mit den Grundlagen von GML (lohnt sich bestimmt) und mit den ganzen Topics, die es über 3D-Projekte mit GM gibt.

Edit: Mist, da waren die andern mal wieder schneller

Also, 3D an sich ist möglich, ja.
Aber der Gamemaker Enginesind Grenzen gesetzt, da sie meines Wissens nach z.b. kein Bump-oder Normalmapping unterstützt und keine Shader. D.h., dass du Effekte wie in FEAR oder so schlichtweg vergessen kannst.
Desweiteren ist die Engine nicht gerade performant wenn ich das mal äußern darf. Aber kleinere 3D Games sind möglich.
Aber auch da muss erstma mit kleinen Sachen Erfahrung gesammelt werden.

@domimah:
Die "Kassenschlager" haben eine deutlich höhere Entwicklungszeit, z.b. WoW, Starcraft 2 und Shenmue liegen bei im Schnitt 5 Jahren Entwicklungszeit (ohne die Designphase) und z.B. Shenmue hat über 100Mio$ Kosten gehabt. Also, ma eben in nem Jahr geht das nicht.

Es ist möglich gute 3D-Spiele zu machen, die auch flüssig laufen...
Guck mal im englische Forum, dort sind eingige angefangene(mit Demo) oder scon fertige zu finden...

gamer

Original von domimah
Es gibt auch Programme (z.B. Marzipan), die .obj-Dateien in GML umwandeln; du modellierst also in einem Programm wie Blender, speicherst dein Projekt als obj-Datei, konvertierst mit Marzipan und packst den erhaltenen Code in ein Script in Game Maker.

Das will ich sehen!

@ Topic: Achja, es gibt einen guten 3D Editor, der wurde auch mit dem GM gemacht, und der is gut: Smart Poly (3d tool)

Original von copyboy

Original von domimah
Es gibt auch Programme (z.B. Marzipan), die .obj-Dateien in GML umwandeln; du modellierst also in einem Programm wie Blender, speicherst dein Projekt als obj-Datei, konvertierst mit Marzipan und packst den erhaltenen Code in ein Script in Game Maker.

Das will ich sehen!

@ Topic: Achja, es gibt einen guten 3D Editor, der wurde auch mit dem GM gemacht, und der is gut: Smart Poly (3d tool)

Bitteschön
Smart3D - The Model Exporter
SuFu ist zum Suchen da...

MfG Shadow

Original von gamer
Es ist möglich gute 3D-Spiele zu machen, die auch flüssig laufen...
Guck mal im englische Forum, dort sind eingige angefangene(mit Demo) oder scon fertige zu finden...

gamer

Flüssig ja, aber er fragte ja nach games wie FEAR oder so. Sowas ist NICHT möglich im GM.

Original von Shadowheart

Original von copyboy

Original von domimah
Es gibt auch Programme (z.B. Marzipan), die .obj-Dateien in GML umwandeln; du modellierst also in einem Programm wie Blender, speicherst dein Projekt als obj-Datei, konvertierst mit Marzipan und packst den erhaltenen Code in ein Script in Game Maker.

Das will ich sehen!

@ Topic: Achja, es gibt einen guten 3D Editor, der wurde auch mit dem GM gemacht, und der is gut: Smart Poly (3d tool)

Bitteschön
Smart3D - The Model Exporter
SuFu ist zum Suchen da...

MfG Shadow

Er meinte die 3D-Projekte auf der GMC. In diesem Falle brauchst du also nicht auf die SuFu verweisen.

Solche Sachen wie Bumpmapping werden in der Tat nicht unterstützt. Da muss man sich schon selber den Kopf zerbrechen und tricksen.
An sich finde ich nicht, dass die 3D-Engine unbedingt schlecht ist. Man muss sie nur zu nutzen wissen, viele Projekte beweisen es ja. Der 3D-Bereich ist nunmal kompliziert und gerade am Anfang wird man nicht darauf achten, die Polygonzahl gering zu halten. Dann ist es auch verständlich, dass die ersten Resultate vom Gegenteil zeugen.

Mario Golf und andere N64 Games kannst du definitiv sogar toppen. Hier hab ich dir mal einen Screenshot gemacht, dass du sehen kannst, was auf jeden Fall möglich ist:

Unmöglich ist es nicht, nur schwerer als in anderen Programmiersprachen bzw. Programmierumgebungen. Am Anfang freust du dich noch das du dich um kaum was kümmern musst und direkt 3D Befehle verwenden und 3D Objekte machen kannst. Aber irgendwann wirst du dich stark ärgern, weil der Game Maker in 3D nicht besonders schnell ist. Je weiter und moderner (d.h. mehr Objekte und Polygone) du da ein 3D Spiel gestaltest, umso langsamer wird das ganze.

Da stimme ich Windapple voll und ganz zu.
Die Verwaltung einer riesigen Anzahl an Objekten wie bei Zelda erfordert Datenstrukturen die im GM einfach nicht möglich sind. Zumindest nicht effizient.
Es fehlt Polymorphismus, Pointer, Threading, etc.
Und bei Projekten dieser Größe solltest du ein verdammt gutes Wissen über 3D-Grafik haben. Also z.b. dieses Paper gelesen und verstanden haben.
Besonders solltest du ne solide Grundlage in Linearer haben. Solltest also z.B. die Seiten 213-215 der PDF gut verstehen können.

Mich würde ja mal brennend interessieren, wie man so etwas mit der OGRE-Engine machen könnte. Die wäre definitiv um einiges schneller und damit könntest du mit viel Können und Geschick auch FEAR nachprogrammieren.

Also, Ogre3D ist ne verdammt mächtige Engine, das muss man sagen. Jedoch ist Ogre für Einsteiger kaum geeignet, da sie komplex zu bedienen ist.
Ne gute Engine für Einsteiger, die ebenfalls verdammt geile Resultate erzielt, ist die Irrlicht-Engine

Original von mauge
Der 3D-Bereich ist nunmal kompliziert und gerade am Anfang wird man nicht darauf achten, die Polygonzahl gering zu halten.

Das stimmt nicht, wo ich nochmal dieses Dingens... *such*
Hier: Speicher sparen in großen 3D-Landschaften zweiter Post!

@ mauge: 3D Projekte? Hä? Nein, stimmt schon so, was Shadowheart gesagt hat.

Original von rootnode
Da stimme ich Windapple voll und ganz zu.
Die Verwaltung einer riesigen Anzahl an Objekten wie bei Zelda erfordert Datenstrukturen die im GM einfach nicht möglich sind. Zumindest nicht effizient.
Es fehlt Polymorphismus, Pointer, Threading, etc.
Und bei Projekten dieser Größe solltest du ein verdammt gutes Wissen über 3D-Grafik haben. Also z.b. dieses Paper gelesen und verstanden haben.
Besonders solltest du ne solide Grundlage in Linearer haben. Solltest also z.B. die Seiten 213-215 der PDF gut verstehen können.

Das sehe ich anders. Die Zelda-Version, von der wir sprechen, stellt kein Problem dar. Du zeichnest ja nicht ständig alle Polygone, sondern nur die aktuell sichtbaren. Natürlich erfordert das einiges Wissen im Umgang mit 3D-Programmierung, da hast du vollkommen Recht.
Was ein wichtiger Punkt ist, ist dass man darauf achten muss, mit möglichst wenigen Objekte zu arbeiten. Die meisten erstellen für jedes noch so kleine Hinderniss ein eigenes Objekt. Nehmen wir zB. GTA - das ist ja immer beliebt: Statt jeden Hydranten usw einzeln zu erstellen, sollte man komplette Häuserblocks in ein Objekt packen. Die 2D-Collision Engine des GM sollte man ohnehin umgehen. Das allein macht schon sehr viel aus.

@copyboy: Was soll an meiner Aussage nicht stimmen?

Original von mauge
Das sehe ich anders. Die Zelda-Version, von der wir sprechen, stellt kein Problem dar. Du zeichnest ja nicht ständig alle Polygone, sondern nur die aktuell sichtbaren. Natürlich erfordert das einiges Wissen im Umgang mit 3D-Programmierung, da hast du vollkommen Recht.
Was ein wichtiger Punkt ist, ist dass man darauf achten muss, mit möglichst wenigen Objekte zu arbeiten. Die meisten erstellen für jedes noch so kleine Hinderniss ein eigenes Objekt. Nehmen wir zB. GTA - das ist ja immer beliebt: Statt jeden Hydranten usw einzeln zu erstellen, sollte man komplette Häuserblocks in ein Objekt packen. Die 2D-Collision Engine des GM sollte man ohnehin umgehen. Das allein macht schon sehr viel aus.

@copyboy: Was soll an meiner Aussage nicht stimmen?

Also, das Weglassen der nicht sichtbaren Polygone ist ein ganz normaler Vorgang. ViewFrustum-Culling sollte noch halbwegs im GM implementierbar sein. Aber sobald es um größere Ausschlussverfahren wie Octrees oder Quadtrees, z.B. für große Außenlandschaften, geht, is der GM fast am Ende.
Auch das Zusammenpacken sich wiederholender Objekte ist natürlich Standard. Für sowas hat man uns mit DisplayLists gesegnet, etc.
Jedoch, allein durch das Fehlen von Pointern sind viele Algorithmen oder Datenstrukturen einfach nicht realisierbar oder wenn überhaupt, dann mit ziemlich dicken Laufzeiten.

Und das Posting, das du vorgeschlagen hast, ist halber Schmarn. Für Welten mit vielen animierten Objekten macht dies absolut keinen Sinn. Damit zwingst du die Engine, mehrere Objekte zu mergen, was sie als ein Objekt auch intern darstellen würde. Das wäre bei größeren Sektoren ein evtl. Swappingaufwand was dann den Rechner in die Knie zwingt.
Und andere Algorithmen, wie z.B. BSP-, Oc-oder Quadtrees bräuchten einen Zugriff auf mathematische Funktionen mit einer möglichst geringen Laufzeit.
Und auch das bietet der GM in der Hinsicht nicht. Man kann z.B. nicht die Arithmetik-Einheiten der CPU (sprich: SSE, SSE2, MMX, etc) direkt ansprechen, was das ganze wieder verlangsamt.

Es gibt zu viele Faktoren, die den GM davon abhalten für größere 3D-Projekte geeignet zu sein:

• Keine Pointer, ergo: weniger Möglichkeiten effiziente Datenstrukturen zu erstellen
  
• Kein direkter Zugriff auf Grafik-API's. Höchstens mittels DLL, was das Ganze dann wieder verlangsamt.
  
• Ineffizient gecodeter GM; schlampiges 3D-Interface
  
• Fehlender Direktzugriff auf ALU der CPU
  

So, ich hoffe die Liste reicht.

Für kleinere bis (je nach Erfahrung im GM) mittlere Projekte im 3D Bereich sollte der GM aber reichen.
Wer jedoch mehr will, muss auf anderes zurückgreifen.

Nein, du hast mich nicht ganz verstanden. Die zu vielen Objekte sind nicht auf D3D bezogen, sondern auf den GM allgemein. Das macht sich nur eben im 3D Modus stark bemerkbar. Ich experimentiere nun seit einem guten Jahr damit herum und hab schon dementsprechend viel getestet. Fakt ist, dass ich jedem, der etwas halbwegs zeitgemäßes auf die Beine stellen will, leider vom GM abraten muss. Man sollte sich aber auf jeden Fall mal Extreme3D anschauen. Ich war echt verblüfft, als ich die Resultate gesehen habe, wozu Reflexionen und Schatten gehören - und das bei annehmbarer Geschwindigkeit.
Dennoch, N64 Zelda ist definitiv machbar, und darum ging es ja.

Achso, was mir grad noch einfällt. Die angesprochenen großen Außenlandschaften mit halbwegs akzeptabler Weitsicht zwingt den GM in der Tat in die Knie. Sicher kann man das umgehen, aber muss unschöne Ergebnisse in Kauf nehmen.

Was meintest du dann mit Objekten? Ich habe die auch nicht direkt auf D3D bezogen, sondern allgemein als 3D Objekt aufgefasst.
Ein Game in der Art von Zelda64 könnte evtl. möglich sein, jedoch nur in einer stark minimierten Variante.
Es sind meist nicht die Renderpasses die den Rechner in die Knie zwingen, sondern das Framework drumherum, sprich: Management, Culling, Trees neu berechnen und andere Berechnungen.
Auf jeden Fall hast du es erfasst: 3D Games mit dem GM sind zwar möglich, haben aber dann den Stand eines Games von 1998.

Bezüglich Performance im 3D-Bereich gibts es zur Zeit 3 große Ikonen:

• C++
  
• D (Ja, hätte ich nicht gedacht, echt. Aber bei der nVidia DemoCompetition haben 2 Herren eine recht ansehnliche und performante Engine in D auf die Beine gestellt)
  
• Java (auch wenn ichs nicht mag)