der obige thread ist übrigens von mir, hab nicht gecheckt, dass ich gar nicht eingeloggt bin

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

ist zwar nicht wirklich ne Antwort, aber ich habe da ne Frage: ab wann werden denn Modells als Highpolygonmodells gezählt??

_________________
. . .

Ein Highpolymodell ist es für mich dann, wenn die Vertices so dicht zusammen liegen, dass ich keine speziellen Texturtricks mehr brauche, um schöne Specular Highlights zu bekommen. Solche Modelle haben dann bei Rundungen auch eine stimmige Silhouette.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Hier ist die goldene Mitte der richtige Weg.Ein Game soll zum einen gut aussehen, und zum anderen auch mit annehmbarer Geschwindigkeit laufen.Um dies zu erreichen gibts ja bekannterweise recht viele Techniken wie LOD, Octrees und Portale.


Eindeutig lowpolygon Modelle, wobei der Begriff "Lowpolygone" ja von der momentenen Rechnerbasis abhängt.Ich definiere hier mal z.B. Für Spielfiguren einen Polycoung von 1200-1500Tris als niedrig.Das diese allerdings mit den richtigen Techniken wie z.B. Bumpmapping und specular Lighting per Textur kaum von Highpoly-Modellen zu unterscheiden sind, zeigt u.a. dieses von einem deutschen Team (die momentan an dem äusserst vielversprechenden "Far Cry" arbeiten) entwickelte Tool names Polybump : <a href='http://crytek.com/polybump/index.php?sx=polybump' target='_blank'>http://crytek.com/polybump/index.php?sx=polybump</a>
So ähnlich geht ja bekannterweise auch ID-Software mit DoomIII vor.Die dort verwendeten Modelle haben kaum mehr Polygone als ihre Quake3-Adäquate und sehen dank geschicktem Bumpmapping ein gutes Stück besser aus.


Hier sollte man (habe ich DoomIII schon erwähnt ) ganz einfach mehrere Renderpfade entwickeln (falls nötig) die verschiedene Features auf verschiedenen Grafikkarten ermöglichen.Ist ein Feature wie z.B. ein Pixelshader auf der genutzten Hardware nicht realisierbar, so sollte man trotzdem versuchen einen ähnlichen Effekt zu realisiern, denn wenn auf der Packung bzw. der Homepage die tollsten Screenshots mit den neusten Features zu sehen sind, und ein Großteil der Nutzer diese nicht zu Gesicht bekommt, weil die Graka diese nicht unterstützt, macht sich schnell Unmut breit.


Die Frage ist ja eigentlich schon mit Antwort 1 bzw. 3 beantwortet.Natürlich sollte man drauf achten das ein Programm/Spiel auch auf alten Rechner läuft, da besonders Freeware auch mal von Gelegenheitsspielern angetest wird, deren Hardwarebasis nicht gerade Highend ist.Dafür gibts aber wie gesagt jede Menge Techniken wie LOD, geringere Texturenauflösung für altere Grafikkarten, weglassen von Effekten die für das Spielgeschehen nicht so wichtig sind.


Eine generelle Engine zu schreiben, die man in jedem Projekt nutzen kann, halte ich für eine schlechte Idee.Die wird mit der Zeit nämlich einfach zu fett, und eine einzelne Person würde bei der Programmierung fast verzweifeln.Die Engine sollte schon ungefähr auf ein Genre (z.B. Ego-Shooter) ausgerichtet sein.Wenn man sie dann einem breiteren Spielespektrum öffnen will, so sollte man entweder den Source rausgeben oder die Engine leicht anpassbar machen (gute Beispiele sind die Quake/Unreal-Engines auf deren Basis sogar Rennspiel-MODS entwickelt wurden).
Der Vorteil einer angepassten Engine ist meiner Meinung nach, das sie durch ihre Ausrichtung auf ein bestimmtes Ziel ganz einfach leichter zu überschauen, besser zu handhaben und schlanker ist.


Das wichtigste an einer Engine sind und waren bis her immernoch die mitgelieferten Tools.Die Engine kann so toll sein wie sie will, ohne gute Tools mit denen man jeden Aspekt des Spiels einfach und ohne großen Lernaufwand verändern kann, nützt einem die Engine garnichts.Das ist meiner Meinung nach der Fehler den viele Hobbyentwickler machen.Sie basteln ne Engine mit allen modernen Features, und stehen später ohne Tools da mit denen sie entsprechenden Inhalt für ihre ach so tolle Engine machen können, und daran scheitern sie dann oft.

Auch noch wichtig sind neben den grafischen Gesichtspunkten auch die Soundengine.Denn wer wie ich z.B. nen Dolby 5.1-Sourrundverstärker an seinem Rechner mit 5.1-Soundkarte hängen hat, der legt da viel Wert drauf.Es macht schon nen Unterschied, ob man die Sounds nur vorne hört oder diese auch wie z.B. bei Battlefield1942 von hinten kommen.Dadurch wird man nämlich komplett in die Spielwelt hineinversetzt.Die Soundengine ist meiner Meinung nach ein viel zu oft vernachlässigtes Thema.Schlecht umgesetzt ist sie z.B. bei Need For Speed : HPS2, wo man nur Stereo-Sound hat, obwohl es grade bei einem Rennspiel sehr toll ist wenn man die von hinten anbrausenden Konkurrenten hört.

Weiterhin ist eine mächtige Skriptengine ein wichtiger Gesichtspunkt bei der Betrachtung einer Engine.Ohne aufwendige Skript läuft heute kaum noch ein kommerzielles Spiel.Was wären z.B. Rollenspiele ohne geskriptete Ereignisse?Ganz genau : Gähnend langweilig.Ein gutes Beispiel für eine mächtige Skriptengine ist Dungeon Siege (Stichwort : SKRIT).

Die Dokumentation spielt dann eine wichtige Rolle, wenn man die Engine nicht nur selbst verwenden will, weshalb dieser in meinen Augen auch eine sehr wichtige Rolle zukommt.

So....das war jetzt erstmal das was mir zu ner Engine spontan eingefallen ist.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich war auch nicht eingeloggt...

Stimmt.Allerdings sollte man sich bei der Projektkonzeption eine bestimmte Hardwaregeneration als Grundlage setzten, so daß man davon ausgehen kann das bestimmte Extensions auf jeden Fall unterstützt werden.Diese Entscheidung sollte natürlich auch unter dem Standpunkt der geplanten Veröffentlichung des Projektes stattfinden.Wenn ich jetzt mit einem Projekt beginne dessen Entwicklungszeit knapp 2 Jahre beträgt, kann ich davon ausgehen das zum Termin der Veröffentlichung Grafikkarten mit Pixelshader auf jeden Fall sehr weit verbreitet sind.Dann kann ich ohne Gewissensbisse also Pixelshader in meiner Engine verwenden.Das ist natürlich ne andere Sache, wenn man nur ein kleines Projekt entwickelt.Mein NapalmBomber3D (siehe Offtopic) hatte nur ne kurze Entwicklungszeit, und sieht trotzdem recht gut aus.Aufgrund der Tatsache das bis auf Displaylisten und Vertexbuffer keine spezifischen OpenGL-Extensions genutzt werden, läuft es selbst noch auf Vodoo3-Karten.


Q3 Radiant ist zwar keine schlechte Alternative, allerdings legt man sich damit auf ein fremdes Dateiformat fest, das zudem noch recht schlecht erweiterbar ist, da diese Erweiterungen ja keine Berücksichtigung im Editor finden.Bei meiner ZornGL-Engine bin ich z.B. so vorgegangen, das ich zuerst den Editor und gleichzeitig die Engine programmiert habe.Somit war nach der Fertigstellung der Engine auch mein Editor fertig.Um jetzt auf Basis der Engine dann ein Spiel zu basteln fehlen nur noch wenige Dinge, und man hat von Anfang an ein Tool mit dem man Maps machen kann.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Erstmal möchte ich mich bei SoS und LarsMiddendorf für die ausführlichen, fundierten und gut begründeten Antworten bedankten (was jetzt nicht heißen soll, dass ich an weiteren Meinungen nicht interessiert bin).

Die Polybump Screenshots sind cool, man muss schon sehr genau hinsehen, um zu erkennen, dass es sich eigentlich um recht grob auflösende Modelle handelt.

Wenn ich bei Antworten auf die folgenden Aussagen teils eine andere Meinung vertrete, möchte ich noch einmal klar stellen, dass dies keine Wertung, sondern nur meine Sichtweise der Dinge darstellt, die für jemanden der unter anderen Voraussetzungen als ich programmiert suboptimal oder sogar falsch sein kann (und ist).



Und wenn du jetzt tatsächlich spielst, was stört dich mehr: dass du dir sagst, dass die Grafik eines Spieles doch recht hausbacken wirkt (kennt jemand eigentlich Might & Magic IX ?), oder dass ein Spiel jedesmal ins Stottern gerät, sobald auch nur von Ferne der volumetrische Nebel im Sumpf zu sehen ist, den du auch nicht abstellen kannst ?





Das ist sicherlich beste Lösung, die aber im privaten Bereich nur schwer zu verwirklichen ist. Neben der schwierigeren Wartbarkeit des Codes ist insbesondere die Fehlersuche erschwert, da man kaum eine Menge Computer mit unterschiedlicher Konfiguration zuhause herumstehen haben wird.
Man kann sich allerdings mit dem MesaGL Treiber behelfen, einem Software OpenGL Treiber, der sehr viele, auch herstellerspezifische, Features moderner Grafikkarten emuliert.
Mir ist das aber ehrlich gesagt zu aufwendig, weswegen ich mich auf die reine OpenGL-Spezifikation beschränke, mit der man ja ab Version 1.3 (Multitexture, Cubemaps) auch schon recht viel anfangen kann.
Da Mcad auf sehr vielen unterschiedlichen Systemen eingesetzt wird, die teils sogar so aktuelle "3D-Beschleuniger" wie die ATI-Rage-Pro (man würde es kaum für möglich halten, aber diese Museumsstücke werden z.B. in Firmenpcs tatsächlich noch in großem Ausmaß eingesetzt) ist es mir tatsächlich wichtiger, die Gewißheit zu haben, im Notfall auch mit dem Microsoft Software Renderer auszukommen, als die neuesten Grafikkartenfeatures auszunützen.
Gerade bei performanceorientierten Features, wie der Ausnutzung des Grafikkartenspeichers für Geometriedaten, bin ich auch der Ansicht, dass dies ein gut programmierter OpenGL Treiber selbst erledigen sollte (z.B. während der Erstellung einer DisplayList) anstatt dass ich mich als Programmierer damit herumschlagen muss, welche kartenspezifische Performancesteigerung ich noch nutzen könnte.




Ja ... . Wenn man genau weiß, was man für eine Applikation entwickeln möchte, ist es auf jeden Fall geschickter eine Engine speziell dafür zu schreiben. Anderenfalls muss man halt darauf achten, eine Grundlagenbibliothek so allgemein zu halten, dass sie leicht auf ein spezielles Anwendungsgebiet hingetunt werden kann. Bestimmte Techniken sind ja auch überall gleich (Frustumculling, Stencilshadows, man wird auch nicht in jedem Programm ein völlig anderes Animationsformat verwenden)






Eigentlich unnötig hierauf noch zu antworten, hier kann ich nur vorbehaltlos zustimmen. (Obwohl ich Sound und Grafik lieber getrennt halte und erst in der fertigen Applikation zusammenfüge).



Interessanterweise bin ich z.B. wieder davon abgekommen, eigene Skriptsprachen zu entwickeln. Vielmehr erstellen schreibe ich lieber Tools, die direkt Sourcecode erstellen, der dann sofort als Bibliothek eingebunden werden kann.
Der Vorteil liegt auf der Hand - alles ist aus einem Guss und die Ausführung ist schneller - der Nachteil natürlich, dass man zum Erweitern des Programms ebenfalls die entsprechende Programmiersprache benötigt (und das Ganze als Sourcecode vorliegen muss).


Ich möchte diese Aussage noch insofern erweitern, dass eine ordentliche Dokumentation (evtl. in Form von Hilfedateien oder html-Help) es auch dem Programmierer sehr erleichtern den Code zu organisieren und zu strukturieren - viele Zusammenhänge fallen einem erst dann auf, wenn man sich selber "zwingt" zu erklären, was man da eigentlich macht. Dann hat man nach mehreren Änderungen aus einem Sammelsurium von mehr oder weniger unstrukturierten Routinen und Klassen, mit denen man diesen oder jenen Effekt erreichen wollte, eine zusammenhängende und aufeinander aufbauende Bibliothek erstellt, die dann auch leichter erweiterbar ist.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/