Zitat von tivolo
eine engine darf den workflow nicht vorschreiben, sondern muss sich vielmehr an den workflow eines studios anpassen können.
-tiv
Ja, und genau das tut sie eindem sie ein eigenes Dateiformat hat und nicht die Dateformate von obengenannten Tools unterstützt.
Ich hab damit ein Rennspiel geschrieben, und die Physik hat mit Abstand am meisten Zeit gefressen, vor allem weil weder für Heightmaps noch für Meshes/konvexe Hüllen was vernünftiges da war. Darüberhinaus entstehen in ode sehr leicht Situationen, in der die Physik auf einmal "hängenbleibt"
Ich gebe zu, ich hab mich nicht viel mit Physik"engines" auseinandergesetzt, aber ich glaube dir natürlich, wenn du ein komplettes Spiel damit geschrieben hast und mit jedem kleinen Problem der Implementation zu kämpfen hattest. Newton wird's wahrscheinlich sein 
subdivided shadow mapping, depth impostors, soft shadows, multiple zur laufzeit einbindbare Shader etc. Humus' 3D-Seite ( http://www.humus.ca/index.php?page=3D ) ist da interessant, sehr gute Ideen in den Techdemos (zB 3D-Lightmaps)
Das sind alles Sachen, die sehr leicht implementiert werden können, wenn wir sie überhaupt brauchen, sobald die Architektur einmal steht.
Ah ja, und 3D lightmaps hat schon Quake 3 vor 5 Jahren gehabt. (LIGHTGRID lump in den BSPs).
Hauptproblem ist es, ne Engine so zu designen, dass in ihr all das reinpasst, ohne alles umstellen zu müssen. Führt dazu, dass man 90% der Zeit an abstrakten Sachen ohne visuelles Feedback codet Aber wenns soweit ist, zahlt es sich aus...
Exakt...
Naja es geht ja nicht darum das du schneller laden kannst sondern darum das du nicht 5 modell formate unterstützt und den ganzen müll code in deiner Engine is
Ich sehe das als Vorteil, wenn du mehr Formate unterstützt. Wenn du den code nicht sehen willst, mach dir z.B. einfach ein paar DLLs. Ausserdem hast du eine breitere Unterstützung von der "Szene" (es gibt genug Leute, die nicht die Geduld haben, ihre Models durch einen converter rennen zu lassen)...
Welche Plattformen sind den interessant für GameEngines ausser Windows? Ich persönlich denk da an Mac...weil man mit Cedega die meisten games unter Linux rennen lassen oder lieg ich mit meiner annahme falsch?
Diese Frage würde sich nicht ergeben, wenn du portablen code schreiben würdest 
Ich schließe mich tivolo's Aussage an, die Zeit wird für deine Vorhaben nicht reichen. Du solltest unter anderem auch Test- und Debuggingzeiten miteinbeziehen. So wie es aussieht willst du die Funktionalitäten einer guten Engine (wie z.B. Ogre3D) sprengen.
Wenn sich Leute finden, geht es sich aus - ich habe schon fast die ganze Architektur, und wie gesagt, es geht meistens um features, die leicht implementiert werden können.
Ich könnte falsch liegen, aber das letzte Mal als ich was mit OGRE zu tun hatte (nicht so lang her), unterstütze es nicht einmal shadowmaps und der source war ein Alptraum. Letzteres ist natürlich eine persönliche Meinung, aber ich würde nie im Leben damit arbeiten wollen...
Leute sorry für die 20,000 posts
Zitat von dv_
- Sieh dir mal PhysicsFS an ( http://www.icculus.org/physfs/ ), ein recht gutes VFS für Spiele.
Viele von den features hab ich schon, sogar ein eigenes compress() komprimiertes PAK file Format (Wolfmann wird sich freuen ;)...
Zitat von dv_Ein paar Tips:
- Erwäge, Newton statt ODE zu nehmen. Integration geht viel leichter, und es ist wesentlich stabiler. Ausserdem kanns mit Meshes VIEL besser umgehen.
Soviel ich weiss ist Newton nicht unter der LGPL?
Zitat von dv_
- Als 3D-Format würde ich auch OBJ unterstützen, da sehr leicht zu parsen und ziemlich weit verbreitet.
Hehe MD2/MD3 würden auch in die Kategorie fallen. Einen Model-loader zu schreiben ist einfach, interessant wirds wenns um die Details geht
Zitat von dv_
- Sieh dir mal PhysicsFS an ( http://www.icculus.org/physfs/ ), ein recht gutes VFS für Spiele.
Noch nie davon gehört, werde ich machen, danke für den tipp...
Zitat von WolfmanAlso als format würd ich ein eignes binär format wählen und einen extra importer/exporter coden dem man schön plugin base konzepiert oder du codest dir einen exporter für dein lieblings 3D Tool
Ich glaube nicht dass das einen Sinn hat... Das *einzige* was du damit erreichen kannst sind ~0.005 Sekunden schnellere Ladezeiten per Model, was sich als ganzes (Tools etc) nich auszahlt. Wenn du einfach nur Tangenten etc. speichern willst, dann ist es wahrscheinlich besser die Daten in eine separate Datei zu speichern, es sei denn dein Team kann sich erlauben die Extrazeit zu investiren, um 3ds/maya plugins oder converter zu schreiben...
-phil
Zitat von tivolo
es ist immer gut sich ziele zu setzen, doch man sollte dabei nicht über das ziel hinausschiessen. in 3-4 monaten ein tech-demo auf die beine zu stellen, das kommerziell von interesse sein soll, wird *äußerst* schwierig. vor allem deshalb, weil in einem tech-demo auch der content stimmen muss. der schönste effekt bringt nichts ohne entsprechenden content.
Ich weiss ganz genau was du meinst; der Zeitplan gilt nur wenn ich erfahrene, motivierte Teammitglieder finde. Glaube mir, wenn sich 5 Leute 4 Monate lang ins Zeug hauen, und noch dazu eine soldie Basis für den Renderer da ist, *ist* das möglich. Wenn das aber so eine "ja ich lerne jetzt c++ und würde euch gern helfen" - Sache ist, dann sicherlich nicht...
Um Content überhaupt machen zu können, ist meiner Meinung nach eine fertige Engine von Vorteil. Sicherlich, man kann den Level-designern sagen, "ok, verwendet einfach die Textur für environment mapping und die da für cone step mapping, es ist doch wurscht dass ihr keine Ahnung habt wie das letzlendlich ausschauen wird", aber ich glaube nicht, dass das der richtige Ansatz ist. Deswegen bin ich derzeit nur auf der Suche nach Codern, um möglichst eine solide Basis für die Designer bereitstellen zu können.
Mit kommerziell meine ich nicht dass ich das Demo verkaufen will, sondern einfach nur nach Möglichkeiten suchen, die weitere Entwicklung eines eventuellen Speils zu finanzieren.
Zitat von tivolo
wenn's dich interessiert, können wir gerne mal bzgl. engine-architektur und graphischen dingen quatschen...
-tiv
Gerne ICQ/MSN screenname hab ich angegeben...
-phil
Heh, schon, aber im dritten Semester gibt es leider nicht viele Leute die einmal wissen was ein Z Buffer ist Ich werd mich in höheren Kursen umschauen müssen, hab aber gehofft dass es vlt. hier jemanden gibt...
-phil
Hallo,
Derzeit arbeite ich an einer 3d engine und versuche ein Team aus 4-5 Leuten zusammenzustellen, um in 3-4 Monaten ein Tech-demo mit kommerziellem Interesse vertigzustellen zu können. Unter anderem wäre ein halbwegs erfahrener 3d programmierer von Vorteil, der mir bei diversen Kleinigkeiten aushelfen könnte, da die ganze restliche Rendering- Architektur viel zu viel Zeit in Anspruch nimmt und ich nicht alles bis aufs keinste Detail optimieren kann.
Die Engine ist in reinem C unter der Verwendung von OpenGL (hehe was sonst geschrieben, hat aber auch ein C++ Interface für den Game code. Die Aufgaben würden sich derzeit auf Shaderprogrammierung (Cg, Relief mapping, etc.) und Model-support (ASE, Cal3D) beschränken.
Dann wären Leute für die Physik (ODE-Integration scheint eine gute Wahl zu sein) und den Game code notwendig.
Hier ist meine Seite, die Screenshots sollten euch aber nicht täuschen - das ist halt "testing data"
stud3.tuwien.ac.at/~e0427091
Wenn sich irgenwer interessieren sollte und sich in den obengenannten Gebieten auskennt, melde sich einfach bei mir (cyberdemon@gmx.at).
Danke,
-phil
