3D coder für Projekt gesucht

    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

    A shell, an imp.

    Deine Screenshots geben schon was her, Hut ab :thumb:
    Hast du schon diverse CG-LVAs besucht? Wenn nicht, wäre das vielleicht eine Überlegung Wert. Dort würdest nämlich recht schnell ein paar Leute kennenlernen, die vielleicht auch bei deinem Projekt mitmachen.

    mfG Fup

    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

    A shell, an imp.

    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.
    - Als 3D-Format würde ich auch OBJ unterstützen, da sehr leicht zu parsen und ziemlich weit verbreitet.
    - Sieh dir mal PhysicsFS an ( http://www.icculus.org/physfs/ ), ein recht gutes VFS für Spiele.

    tips meinerseits:

    Zitat von sqrt(-1)


    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.

    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. und grad bei neueren effekten ist *extrem* viel content zu erstellen.
    weiters sollte man nicht vergessen, dass kommerzielles interesse meist nur multiplattform-engines hervorrufen.

    nichtsdestotrotz viel erfolg mit deinem vorhaben! wenn's dich interessiert, können wir gerne mal bzgl. engine-architektur und graphischen dingen quatschen - beim coden kann ich dir leider nicht helfen, dazu fehlt einfach die zeit.

    Zitat von sqrt(-1)


    Dann wären Leute für die Physik (ODE-Integration scheint eine gute Wahl zu sein) und den Game code notwendig.

    ich würde novodex verwenden. ist für nicht-kommerzielle zwecke gratis.


    -tiv

    Stefan Reinalter
    Lead Programmer @ Sproing Interactive

    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

    A shell, an imp.

    Zitat von Wolfman

    Also 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

    A shell, an imp.

    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...

    A shell, an imp.

    Zitat von sqrt(-1)

    Soviel ich weiss ist Newton nicht unter der LGPL?

    Korrekt. Aber mit so gut wie allen anderen Physikengines lässt sich angenehmer arbeiten als mit ODE. ODE kann sehr leicht ein absoluter Alptraum werden. 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". Die einzigen Vorteile sind die BSD-Lizenz und die Geschwindigkeit. Newton ist closed-source, aber frei für alles (auch für kommerzielle Sachen). Und sobald du die treecollision- und convexhull-Funktionalitäten erstmal verwendet hast, willst du nicht mehr zu ODE zurück.

    EDIT:
    Die Cubemapreflection ist sehr interessant, aber für kommerzielle Interessen brauchst du mehr. Stichworte: 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). 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...

    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 sondern das du den code nur für ein format drinnen hast und dann kannst auch deine TBN Matrixen und andere sachen in drin Format einbauen...

    @tiv
    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?

    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. Trotzdem, viel Glück :thumb:

    mfG Fup

    Naja OGRE ist ja keine Spiele Engine so wie Sinbad es immer sagt ist es ja eine reine Graphik Render Engine und das Material System von OGRE ist ein wahnsinn und jetzt gibts da noch so ein schönes 3rd Oarty Tool wie oFusion das die Content erzuegung ziemlich erleichtert...Naja aber in Ogre stecken ja 5 Jahre drin :)

    Zitat von Wolfman


    @tiv
    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?

    nein, ich dachte da eher an GC, XBox, PS2 bzw. schon XBox360, PS3.
    für die meisten studios ist es interessant eine lösung zu haben, die alles "aus einer hand" bietet. deshalb wurde auch RenderWare von extrem vielen studios verwendet - gebitcht hat jeder, aber verwendet hats auch jeder.

    wenn man nicht gerade ein riesenstudio ist, kann man es sich halt nicht leisten (finanziell und zeitlich gesehen) für eine bestimmte plattform eine eigene engine in-house zu entwickeln.

    -tiv

    Stefan Reinalter
    Lead Programmer @ Sproing Interactive

    Zitat von sqrt(-1)

    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.

    genau hier liegst du meiner meinung nach falsch.
    um eine engine zu entwickeln, die wirklich *verwendbar* ist, gehört sehr, sehr viel dazu. da reden wir schon von *sehr* erfahrenen teammitgliedern, denn auch kommerzielle engines leiden unter der tatsache, dass sie von designierten engine-codern und nicht von spiele-entwicklern geschrieben worden sind. das führt dann meistens dazu, dass irgendwelche tech-demos nach außen hin brillieren und der code totaler müll und dadurch unverwendbar ist.

    außerdem solltest du nicht vergessen, dass niemand geld für ein eventuelles spiel investieren wird, wenn die technologie dahinter nicht future-proof bzw. sinnvoll verwendbar ist.

    ich lass mich aber gern in 4 monaten überraschen ;)

    -tiv

    Stefan Reinalter
    Lead Programmer @ Sproing Interactive

    Zitat von sqrt(-1)

    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...

    dein team kann es sich nicht erlauben, dein team *muss* es sich erlauben. ein artist will in max/maya/lightwave einen exporter, von wo aus sämtlicher content in deiner engine landet.
    eine engine darf den workflow nicht vorschreiben, sondern muss sich vielmehr an den workflow eines studios anpassen können.

    -tiv

    Stefan Reinalter
    Lead Programmer @ Sproing Interactive

    Zitat

    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 :)

    Zitat

    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).

    Zitat

    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...

    Zitat

    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)...

    Zitat

    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 ;)

    Zitat

    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...

    A shell, an imp.

    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.

    A shell, an imp.

    Problem ist halt, dass zB für PS2 keine guten C++-Compiler existieren, und daher zB RenderWare afaik reines C ist. Diese Tatsache allein macht aber 90% aller PC-Engines unbrauchbar für Konsolen. Am PC-nächsten sehe ich die XBox, bei der hat man wohl am wenigsten Probleme. Schlimm wird die PS3, bei der man anders an die Sachen rangehen muss. Bei Revolution weiss ich nix.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden