Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 24

Thema: [3D-Engine][veraltet][siehe 3D Engine aktive Projekte]

  1. #1
    Registered User
    Registriert seit
    May 2000
    Beiträge
    905
    Renommee
    10

    [3D-Engine] Update Klassenkonstrukt

    Moinsen Leutz ...
    Da sonst der andere Thread einfach zu voll wird hier ein neuer und hoffentlich übersichtlicherer ...
    Ich habe jetzt das Klassenkonstrukt fertig geschrieben, leider ist der ftp von Sensenmann gerade down, also lade ich es hier hoch.
    Es sind insgesamt 3 DLL's 1 Exe und der Source zu allem ...
    Wer den VC++ hat kann unter \KLassenkonstrukt2\ den Workspace öffnen und findet alle benötigten Files vor sich ...
    Sollte ohne Umstände kompilieren.

    So, nun zum eigentlichen. Ich hab das ganze Teil jetzt dürftig kommentiert und hoffe ihr kommt damit klar. Ich habe keine Ahnung ob das "wie" ich es mache gut oder schlecht ist, aber Tatsache ist, es funktioniert, es sollte keinen merklichen Geschwindigkeitsverlust geben und auch sonst keine merklichen Designfehler enthalten *hoff*.

    Es gibt 3 DLL's:
    • -CoreEngine
      Hier werden alle Basisfunktionen der Engine geschrieben.
      Ausserdem alle sonstigen Api-abhängigen Basisklassen (Texturen, Map, Objekte, etc...) geschrieben.
    • -OpenGLEngine
      Diese Engine erbt von der CoreEngine und implementiert alle nötigen OpenGL Funktionen.
      Ausserdem werden alle Api-abhängigen Basisklassen aus der CoreEngine hier um ihre OpenGL Funktionen erweitert.
      Diese DLL linkt die CoreEngine.dll statisch !
    • -Direct3DEngine
      Das gleiche in Grün Gelb und Rot
      Diese DLL linkt die CoreEngine.dll statisch !

    Diese 3 DLL's haben eine gemeinsame Datei "DLLInterfaces.h" .
    Diese liegt ausserhalb der jeweiligen Engine Ordner und sollte nachdem das Interface steht nicht mehr geändert werden.
    Darüber erfahren die Api-spezifischen Engines wie ihre Basisklassen aussehen und welches Interface sie bedienen müssen.


    Nun zur Exe.
    Dies ist die Hauptanwendung welche entweder die OpenGL oder Direct3D DLL dynamisch lädt.
    Die ENGINE ist Singleton und wird durch den Header DLL.h implementiert. Man kann ohne Bedenken mit ENGINE-> darauf zugreifen. Fall sie nicht initialisiert sein sollte tut sie dies automatisch (Standartmässig OpenGL).
    Um die Api zu wechseln benutzt man die Singleton der DLL.
    DLLLoader->SetApi("D3D");
    Durch die Angabe von "D3D" oder "OpenGL" wird die jeweilige DLL gewechselt, die ENGINE zeigt jetzt auf die jeweils andere abgeleitete Klasse.
    Alle Objekte die Ordnungsgemäss erstellt wurden (dazu später mehr) wechseln automatisch ! ihre Klasse. Man kann also weiterhin durch den gleichen Basispointer auf sie zugreifen und es werden die neuen Api-spezifischen Funktionen genutzt.

    Das Ordnungsgemässe erstellen einer Instanz eines Objektes klingt schwerer als es eigentlich ist.

    Mit

    SmartPointer<Object> Instanz;

    Erstellt man eine Instanz des Types Objekt mit dem einzigen Unterschied das man auf diese Instanz nun wie auf einen Pointer zugreift.
    Also:

    Instanz->Test();
    oder auch
    (*Instanz).Test();

    Der SmartPointer sichert den Api-Switch. Dank friend Konstruktor sollte es auch nicht anders möglich sein eine Instanz zu erstellen.

    Tja, ich denke das war es dann auch schon ...


    Nun sollten wir ein Interface für die Engine festlegen, ich hab schonmal angefangen soetwas zu implementieren bin aber noch nicht weit gekommen.

    Da das geschehen innerhalb des Draw aufrufes von der Exe aus gesteuert werden soll wird diese Routine logischerweise nicht in den Api-spezifischen DLL's implementiert sondern:
    Denkvorgang von mir, kann beliebig geändert werden:
    Man hat ein BasisObjekt Graphic welches Alle GraphicObjekte dazu auffordert Methoden wie
    • DrawBegin()
    • Draw()
    • DrawEnd();

    zu implementieren.

    Dann könnte man einfach alle GraphicObjekte bei der Engine registrieren lassen und die Engine ruft dann in ihrer eigenen Draw Routine ungefähr das auf:
    Code:
    for(allObjects i)
    i->DrawBegin();
    
    for(allObjects i)
    i->Draw();
    
    for(allObjects i)
    i->DrawEnd();
    Diese Idee habe ich aus irgendeinem Artikel über die Quake2 Engine, wo Carmack das Spiel Quake2 genommen haben soll und einfach seine Objekte der Quake3Engine damit gezeichnet hat.
    Simple and it works ...
    Andere Vorschläge bzw. Erweiterungen sind willkommen und erwünscht.

    Macht euch nen Kopf Jungs...
    Angehängte Dateien Angehängte Dateien
    Geändert von ChaosAngel (23.03.2002 um 17:19 Uhr)
    Hiermit möchte ich mich in aller Form für diesen Beitrag entschuldigen.
    Ich verspreche, es kommt nie wieder vor !


    Life Suckz !!!

  2. #2
    Registered User
    Registriert seit
    Feb 2001
    Beiträge
    230
    Renommee
    10
    Ok, sieht klasse aus..

    Von mir gibts noch keinen Download, kommt aber auch bald. Ich arbeite im Moment an den Klassen, die die Geometrie halten und vor allem bearbeiten sollen. Wenn das geschafft ist, kann auch mit dem Editor begonnen werden. Nunja, ist schwer zusammenzufassen, ohne zu sehr ins Deteil zu gehen, aber ich versuch es einfach mal :

    Ein leeres Level besteht später im Editor aus purem solid space, d.h. "gefüllter" Raum. Aus diesem "schneidet" man nun das Level aus. Man kann sich das so vorstellen, dass man sich anfangs unter der Erde befindet und dann das Level aus der Erde heraus stanzt. Dieses Stanzen geschieht mit Hilfe von Brushes, eine art 3 dimensionalen Stiften in Form von z.B. Würfeln oder Zylindern, sprich berechenbaren, vordefinierten Grundobjekten. Jeder Brush schneidet einen Teil des Levels aus und lässt so nach und nach ein immer komplexeres Level entstehen.
    Wie genau das geschieht ist später im Spiel vollkommen irrelevant, da dort das Level fest als bereits berechnetes 3D Objekt vorliegt. Aber im Editor muss das Level bearbeitbar sein, also liegt es dort noch in Form einer Liste an Brushes vor.

    Sooo, und genau die Klasse für ein Brush programmiere ich gerade. Klingt vielleicht einfacher als es ist, sie muss aber Funktionen bieten, mit denen ich ein Brush aus einem anderen ausschneiden kann, der solid BSP Compiler muss eingebaut werden, Funktionen des Raytracers der Lightmaps müssen rein und dann noch ein Haufen kleinerer Sachen wie z.B. das Laden/Speichern eines Meshes.

    Wie auch immer, ihr werdet es ja sehen, wenn ich es fertig habe... *weiterprogrammierengeh*

    P.S.: Du hast meinen Namen falsch geschrieben *g*.. "senseNmann.rar"

  3. #3
    Registered User
    Registriert seit
    May 2000
    Beiträge
    905
    Renommee
    10

    CollisionManager

    OK, i hab mal schnell nen CollisionManager gebastet der das Multi-Dispatching Problem löst.
    Ist nur der reine BasisSource, also ohne Beispiel Objekte etc... schwer zu verstehen, aber das kommt alles später ...
    Angehängte Dateien Angehängte Dateien
    Hiermit möchte ich mich in aller Form für diesen Beitrag entschuldigen.
    Ich verspreche, es kommt nie wieder vor !


    Life Suckz !!!

  4. #4
    Registered User
    Registriert seit
    Feb 2001
    Beiträge
    230
    Renommee
    10
    Ooookkkk,

    Da wir in letzter Zeit mehr in ICQ als über das Board "besprechen", aber wohl keiner will, dass irgendwelche PHP Coder ihren Thread vor unseren setzen, fasse ich n bissel was von heute zusammen :

    Punkt 1: Partikelsystem

    Unerlässlich in jedem halbwegs guten Code, der sich 3D Grafik Engine schimpfen will, also auch bei uns irgendwann mal zu finden =)
    Um ein Partikelsystem zu programmieren, muss man sich erstmal um verschiedene Punkte Gedanken machen. Da wären "Wozu braucht man Partikel?", "Wie soll die Position festgelegt werden, wo die Partikel erstellt werden?", "Wie sollen sich Partikel bewegen?", "Mit was sollen sie alles kollidieren?" und "Wie werden Partikel überhaupt gezeichnet"

    Fangen wir mal damit an, was Partikel sind und wozu man sie braucht. Partikel sind kleine Sprites, welche z.B. Glitzer, Wassertropfen, Glühwürmchen, Splitter von Einschusslöchern oder was auch immer für kleine Teilchen noch in einem Level rumschwirren können. Außerdem noch größere Objekte, die aber gleich aufgebaut sind, wie z.B. Rauch, Blut oder Schmutz, welcher an Hinterreifen eines Autos aufgewirbelt wird, das durch trockene Steinwüste jagt lol... Ich denke, jeder hat solche Partikel schonmal gesehen und weiß, was sie sind.
    Da es keine echten 3D Objekte sondern 2D Bilder sind, sind sie sehr schnell zu rendern und können zu tausenden über den Bildschirm huschen.. (natürlich versucht man auch deren Zahl durch diverse kleine Tricks möglichst gering zu halten...). Sie dienen dazu, das Level komplexer erscheinen zu lassen, als es in Wirklichkeit ist =), mit ihnen kann man wirklich nette Grafikeffekte basteln..

    Nun, wie und wo werden sie erstellt?...
    Natürlich sollen die Partikel weder bunt irgendwo im Level erstellt werden, noch nur aus einem einzigen Punkt strömen. Bei einer undichten Decke einer Kanalisation z.B. müssen Tropfen (Partikel) überall von der Decke tropfen, nicht nur an einem Punkt. Andererseits dürfen die Partikel nicht einfach so im Raum auftauchen (bei diesem Beispiel).
    Anderes Beispiel: Der Spieler läuft durch einen Schneesturm, um ihn Schneeflocken ohne Ende (Typisch für einen Schneesturm eben). Diese fegen um ihn und bilden kleine Luftwirbel. Diese Partikel fallen nicht merh schlaff von der Decke herab, sondern bewegen sich schier zufällig um den Spieler herum.. (mit ein bisschen Fantasie *g*) Jedenfalls starten die Schneeflocken, welche wie bemerkt die Partikel sind, nun zufällig an einer beliebigen Stelle um dem Spieler herum.
    3. Beispiel: Eine Rakete fliegt durch die Lüfte und zieht eine Rauchschwade hinter sich her. All diese Smoke Partikel entstehen an einem einzigen Punkt am Triebwerk der Rakete.

    Lange Rede kurzer Sinn, Partikel können also entweder in einem Punkt, entlang Geometrie, also aus Geometrie heraus oder zufällig in einem bestimmten Bereich entstehen.

    Und jetzt zum technischen Teil:
    Das Objekt, welches Partikel erstellt nennt sich Partikelemitter. Nun gibt es, wie gesagt, verschiedene Möglichkeiten wie solch ein Emitter aussieht..
    a) Entweder lässt er Partikel aus Vertices von beliebigen Objekten heraus entstehen, so meint der Betrachter diese kämen direkt aus dem Objekt heraus, oder
    b) Zufällig in einem begrenzten Raum, vielleicht innerhalb eines Würfels oder einer Kugel.

    Erstmal zu a) Der Emitter bekommt also ein gewisses Objekt zugewiesen (oder mehrere) und erstellt von nun an, eine gewisse Anzahl an Partikeln pro Sekunde an zufällig gewählten Positionen von Vertices der Objekte. Das wäre dann auch schon alles.
    Zu b) Die Idee hier ist, nicht einen komplett neuen Emitter zu tippen, sondern den Emitter aus a) weiterzubenutzen.. Der Emitter muss also Partikel innerhalb eines gewissen Raums erstellen. Der Emitter bon b erstellt dazu einen normalen Partikelemitter von a) und ein unsichtbares Objekt, welches nur aus Vertices, nicht aus Polygonen besteht. Der neue Emitter bewegt nun die Vertices zufällig in dem vom Coder/Leveldesigner vorgesehenen Raum und das bei jedem Frame. Der echte Emitter erstellt jetzt wie gehabt Partikel an den Vertex Positionen, da diese sich aber immer ändern, sieht es so aus, als ob die Partikel zufällig im Raum erstellt werden und eine neue Möglichkeit an Effekten ist geschaffen...

    "Wie sollen sich Partikel bewegen?"..
    Hmm, dazu gibt es viele Möglichkeiten. Entweder sie fallen plump wie Regentropfen bei Windstille zu Boden, folgen also der Erdanziehungskraft, oder sie steigen wie Rauch auf, fliegen im Kreis, bilden eine Bindhose aus vielen kleinen und größeren Smoke Partikeln, eigentlich alles wäre denkbar.. Nur wie setzt man das am dümmsten um?
    Mir kommen da 2 Ideen.
    1. man erstellt Zonen, in denen bestimmte physikalische Kräfte auf die Partikel wirken, so z.B. global im ganzen Level erstmal die Gravitation, dann in einem Windtunnel zusätzlich eine Kraft entlang der Windrichtung, dann vielleicht noch eine weitere Kraft die die Partikel auf eine Kreisbahn zwingen...
    Jedes Partikelchen müsste dann in jedem Frame auf die genaue Position hin untersucht werden und es müsste grprüft werden, in welchen Zonen es sich befindet.. Daraus errechnet sich eine neue Kraft, welches den Partikel in eine bestimtme Richtung treibt. Natürlich kommen noch Störeffekte wie ein gewisser Grad an Zufallsbeewegung hinzu, das dürfte klar sein...

    2. Jeder Partikel bekommt direkt eine mathematische Formel zugewiesen, die die Bewegung in jedem Frame berechnet. Ein kleiner Mini Compiler könnte ähnlich wie in z.B. WinAmp die Formel in Code umwandeln und damit stark beschleunigen... Vorteil wäre, dass nicht mehr verschiedene Zonen existieren würden und die Berechnung schneller von statten lief.

    Ich aber denke, Weg 1 ist der bessere und auch später schönere, da er eine Reihe an grafischen Zusatzeffekten bieten würde:
    Egal was für ein Typ an Partikel, alle würden auf bestimmte Kräfte reagieren. So würde Regen, der in einen Windkanal fällt, mit beschleunigt werden, Rauch von Smokegranaten würden in engen windigen Tunneln einfach weg geblasen werden und eine Rakete mit einer bewegten Gravitationszone könnte Rauch beim Durchfliegen aufwirbeln. Dies würde wirklich sehr viele Effektmöglichkeiten bieten..

    Ok, wäre das Thema auch abgehakt *g*

    "Mit was sollen sie alles kollidieren?"..
    Das lässt sich wieder etwas einfacher und vor allem kürzer beantworten: Nur mit der Welt und mit bewegten Objekten der Welt (z.B. Türen, Aufzüge..), eine Kollision von Regen mit dem Spieler wäre Rechenzeitverschwendung und kaum erkennbar. Aber damit alles schön variabel bleibt, wäre es denkbar dem Emitter eine Eigenschaftsvariable hinzuzufügen, mit welchen Objekten dessen Partikel alle kollidieren sollen...

    "Wie werden Partikel überhaupt gezeichnet"
    Juhuuu, auch schnell zu beantworten: Partikel sind Sprites/Billbords, also mehr oder weniger kleine, mit dem Normal immer in Richtung Camera gedrehte, texturierte und halb transparente Quadrate.. Dadurch, dass sie immer Richtung Camera "blicken", sehen sie bei genauerer Betrachtung wie 2D Objekte aus. In Hoher Anzahl und mit der richtigen Verwendung fällt dieser negative Nebeneffekt aber kaum auf...

    Punkt 2: Kollisionsabfrage:
    Eben schon kurz angesprochen, bildet das Thema Kollision ein weiteres größeres Problemchen, welches aber relativ schnell gebändigt sein sollte. ChaosAngel hat auch schon den ersten Code dazu gepostet, welcher jetzt aber unter der Masse meines Postings untergehen wird lol...
    Grundsätzlich läuft unsere art der Kollisionsabfrage über solide BSP Bäume, also ähnlich wie die Grafik auch... Kollisionsabfrage und das Eliminieren von Polygonen haben auf den ersten Blick wenig miteinander zu tun, aber der BSP Tree macht ja nichts anderes als das genaue Prüfen der Spielerposition im Level.. Es kann festgestellt werden, in welchem Raum er sich befindet und ob er überhaupt innerhalb der Levelgeometrie steht. Aha, innerhalb der Levelgeometrie.. solange das erfüllt ist, gibt es ja keine Probleme, sobald er sich aber aus dem Level heraus bewegen will, muss die Kollisionsabfrage eingreifen und die Bewegung abblocken oder umleiten.
    Ein komplexes Level aber, mit vielen Objekten im Level wie z.B. Stühle, Blumen, Kugelschreiber auf einem Schreibtisch *übertreib*, besteht aber auch vielen hundert Polygonen, für all diese eine Kollisionsabfrage durchzuführen, ist einfach zu viel. Daher besitzt auch fast jedes professionell entwickelte Spiel für Leveldekoration entweder garkeine Kollisionsabfrage, oder eine, welche auf einer Bounding Box basiert. Also statt einer exakten Kollisionsabfrage, nur ein Kasten um das Objekt... (Siehe CS, BBoxes um Arme, Kopf, Beine etc.. dort aber ZIEMLICH buggy *g*) Diesen Kasten darf man aber nicht sehen, daher wird er als ein nicht-zu-renderndes Objekt markiert, verfolgt das eigentliche Objekt, welches es umgibt aber auf Schritt und Tritt, auch in der Ausrichtung im Raum. Dadurch wird die Rechendauer ohne einem zu starken Qualitätsverlust drastisch herab gesetzt
    Jedes Objekt besitzt also einmal die eigentlich zu rendernde Geometrie und außerdem noch eine Kollisionsgeometrie. Beide können wie im Fall des Levels identisch sein.

    Hmm.. ich glaub das wars.. Was wir so alles an einem Tag schaffen, was? *g* Wow, 9371 Zeichen in dem Posting hier *protz*!

    So long, Sensemann

    P.S.: Ich glaub das war zu ausführlich erklärt, oder? lol.. Mir war langweilig *rausred*

  5. #5
    Member
    Registriert seit
    Jan 2001
    Beiträge
    267
    Renommee
    10
    Hi,

    Also statt einer exakten Kollisionsabfrage, nur ein Kasten um das Objekt...
    Warum eigendlich ein Rechteck? Wären nicht auch andere
    'primitive' Körper geeignet? Für die Kollisionsabfrage von einem Kopf stell ich mir z.b. ein Kugel viel genauer vor als ein Rechteck,
    oder bei einem Arm(-teil :) einen Zylinder.

    grüsse knut

  6. #6
    Registered User
    Registriert seit
    May 2000
    Beiträge
    905
    Renommee
    10
    @Sensemann
    2:23 Man man man, ich hab dich echt unterschätzt.
    Das erste was mir aufgefallen ist, wäre das du nicht aufgepasst hast.
    Partikel brauchen keine MemberVariable die sagt mit wem sie kollidieren können und mit wem nicht. Das passiert ganz automatisch durch meinen KollisionsManager. Wenn keine Kollisionsfunktion für Partikel<->Spieler vorhanden ist, können sie auch nicht Kollidieren. Eine einfachere Möglichkeit wäre diese Partikel bei der Kollision einfach zu eliminieren, spart Rechenzeit ...

    @Sonstige PartikelAusführungen
    Hey, verdammt !
    Schraub mal deine Fantasie etwas runter, ich habe gestern gerade angeboten das Teil zu schreiben und jetzt kommst du mir mit Luftwirbeln etc...
    Also, ich würde sagen jegliche Einwirkungen auf Partikel ausser Kollision sind Gravitation, nen Windhauch dann halt auch !
    Am liebsten würde ich ja die statischen Auswirkungen auf die Partikel vorberechnen. Was aber net möglich sein wird, da diese Abhängig von der Position der Partikel sind. Eine Möglichkeit eine Annäherung zu schaffen wäre den Raum um den Emitter in Zonen aufzuteilen und dort jeweils vorberechnungen zu treffen. Aber ich glaube das würde zwischen den Zonen untereinander zu abgehackt aussehen.

    Einen grossteil der Berechnungen kann ich durch das Fading Elemenieren. Jeder Partikel hat ne Liste mit SubPartikeln die ihm einfach hinterherfliegen, sie nehmen also einfach immer die Position des Vorgängers an ... Die SubPartikel selbst sind dann natürlich farblich abgeschwächt (fade out)

    Den Vorschlag mit den Zonen den du gebracht hast ...
    Man könnte die Zonen wieder unterteilen, bzw. an den Überschneidungen neue Zonen bilden. Dies wäre ein Art des vorberechnens...
    Naja, erstmal muss ich so nen Partikel überhaupt in die Luft bekommen ...


    @Kollisionen allgemein...
    Für bewegte Objekte (Player,Rocket etc...) würde ich Spheres (Kugeln) vorschlagen. Zur Not mehrere damit sie sich der Geometrie angeleichen. Man kann auch um Rechenzeit zu sparen mit einer Ellipse arbeiten, allerdings ist das ziemlich kompliziert da man eigentlich immernoch mit einer Kugel arbeitet, nur eben in einer verzerrten WorldMatrix Hab da mal irgendwo nen Tut zu gelesen *kram*
    Tja, das wars erstmal ..
    ich glaube wir sollten weniger träumen und mehr coden
    Aber ich muss jetzt erstmal einkaufen ...

    PS: Wir brauchen immernoch dringen das Interface für die Engine (CEngine) !!!
    Hiermit möchte ich mich in aller Form für diesen Beitrag entschuldigen.
    Ich verspreche, es kommt nie wieder vor !


    Life Suckz !!!

  7. #7
    Registered User
    Registriert seit
    May 2000
    Beiträge
    905
    Renommee
    10
    Also leute, da ich gerade 4h debugged habe und keine Partikel mehr sehen kann, dachte ich ich zeig sie euch ...

    Nichts besonderes, nur ne Exe, den Source möchte ich euch noch nicht zumuten ...

    Also, keine speziellen vorraussetzungen ausser na 3D-Karte ....
    Probierts auch mal auf euren schlechten Rechnern aus, ich möchte mal wissen wieviel Performance ich noch Platz hab ...
    Angehängte Dateien Angehängte Dateien
    Hiermit möchte ich mich in aller Form für diesen Beitrag entschuldigen.
    Ich verspreche, es kommt nie wieder vor !


    Life Suckz !!!

  8. #8
    Registered User
    Registriert seit
    Feb 2001
    Beiträge
    230
    Renommee
    10
    Juhuuu, hat zwar länger gedauert als ich dachte (7 Uhr *schluck*), aber nun ist es soweit =) Der erste public Code Drop vom BSP Compiler!!! Er enthält 2 Compiliermodi, einen relativ schnellen der in etwa noch 1.5mal mehr Zeit braucht, als der Unreal BSP Compiler, aber immerhin... Der 2. berechnet einen qualitativ besseren BSP, brauch aber extrem viel mehr Zeit... ich schätze nen Tag oder so lol... könnte man berechnen, wie viel in etwa.. (bin aber im Moment zu faul dazu)

    Der Code ist noch nicht kommentiert und es dürfte schwer sein, sich dort zurecht zu finden *g*.. Außerdem ist der Zugriff auf Memberfunktionen von Klassen unschön.. noch Aber wer will, kann ja mal rein schnuppern.. Es wird eine (noch?) besser programierte Version folgen.. Es liegt außerdem eine stark optimierte EXE Version des Codes bei (Ich mag den neuen VC++.NET Compiler immer mehr *g*)...
    Ausgegeben werden im Moment noch nur ein "paar" Debug Msgs in einem Consolenfenster, eine SaveToFile Funktion dürfte aber nicht allzu schwierig sein...
    Ich werde morgen die exakte Berechnung weiter optimieren (erstaunlich, was man hier alles machen kann..) und anfangen ein TestProgramm zu schreiben, mit dem man durch ein einfaches noch untexturiertes Level fliegen kann... dürfte nicht allzu schwer sein, eines der D3D Samples hierzu zu modifizieren...

    NEIN! Das ACE Archiv ist doch glatt 2K zu groß um aufs Board zu passen lol... Dann gibts eben nur Source.. Wer die EXE will, kann kurz mailen (DerSensemann@FreakConnection.de) und ich schick sie ihm + aktuellem Code =)

    @knt:
    Es wäre wieder jeder Körper geeignet, der in einen BSP Baum passt... Am besten aber nur welche, die schon konvex sind.. würde ich echte Kugeln nehmen, könnte das die Kollisionsabfrage durcheinanderwerfen.. BSP<-> BSP, BSP<->Kugel und Kugel<->Kugel Kollision... naja, mal schauen, bis zur Kollisionsabfrage wird noch ein bissel Zeit vergehen...

    So long, Sense

  9. #9
    Registered User
    Registriert seit
    Feb 2001
    Beiträge
    230
    Renommee
    10
    Stop, hier nochmal schnell n Update, welches die Berechnung des exakten BSPs um einige Stündchen verringern dürfte lol... Nichtsdestotrotz wird sie immernoch mehrere Stunden in Anspruch nehmen, wie lange genau, werde ich gleich mal testen, wenn ich ins Bett geh ..

    @Moderator: Angang des letzten Postings löschen, am besten das Posting hier löschen aber vorher den Anhang ins letzte Posting verschieben.. oder so ähnlich *g*... thx
    Angehängte Dateien Angehängte Dateien

  10. #10
    Registered User
    Registriert seit
    May 2000
    Beiträge
    905
    Renommee
    10

    Uston, we've got a problem ...

    moi moi erstmal ....

    Also, ich habe die Grundrisse des PartikelViehs fertig.
    Nicht viele funktionen, nichts was man irgendwo dynamisch einbinden könnte etc...
    Das Problem ist das wir die CoreEngine um ein grosses Stück erweitern müssen und um einiges statischer konstruieren müssen.
    Der BSP-Tree müsste zum Beispiel erstmal fest in die Engine eingebunden werden und nicht mehr als freies Objekt existieren, da ja fast alles was die Engine macht auf dem BSP-Tree basiert. (KollisionDetection, Gravitiy etc....)
    Ausserdem müssen basisklassen für Mesh's, Polygone, Gravitoren, Graphicals, Colliders, bewegte Objekte etc.... geschaffen werden. Ich bezweifle das ich das alles alleine schaffe ...
    Ausserdem brauchen die Api-Engines noch nen guten Trick um ihre Extensions einzubinden ...
    Ich weiss nicht wie man in D3D die Extra Fähigkeiten der Grafikkarte benutzt, sowas wie CompiledVertices, Mutlitexturing etc...
    Das ganze muss so organisiert werden das man bei den Graphik Objekten nur sagt zeichne dieses Array, und falls die entsprechenden Extensions verfügbar sind benutzt er sie automatisch, dazu musst du mir aber noch etwas mehr über den Aufbau von D3D erklären ...

    Tja, ich denke das ist das wichtigste um das wir uns als nächstes kümmern sollten !!! Also wieder zurück zur Planung und weg vom BSP. (die Beispiel Demo kannste natürlich trotzdem basteln )

    Also ... es steht uns einiges ins Haus ... *heul*

    Wäre über Hilfe in der Planung wie gesagt nicht abgeneigt ...
    @all
    Hey, wir brauchen noch gute Leute Meldet euch ...
    Hiermit möchte ich mich in aller Form für diesen Beitrag entschuldigen.
    Ich verspreche, es kommt nie wieder vor !


    Life Suckz !!!

  11. #11
    Registered User
    Registriert seit
    May 2000
    Beiträge
    905
    Renommee
    10
    Da der shit nicht richtig dargestellt werden kann im Anhang: Betrachtung mit NotePad !!!

    PS: Letzte Seite is auch noch'n Post !!!
    Angehängte Dateien Angehängte Dateien
    Hiermit möchte ich mich in aller Form für diesen Beitrag entschuldigen.
    Ich verspreche, es kommt nie wieder vor !


    Life Suckz !!!

  12. #12
    Registered User
    Registriert seit
    Feb 2001
    Beiträge
    230
    Renommee
    10
    Klar muss der BSP später fest in die Engine eingebaut werden, dafür baue ich ja eben diese Klassen.. Später benutzt du genau diese Klassen zum Erstellen eines BSPs, zum Rendern und zur Kollision! Aber erstmal muss ich die Korrektheit des BSPs testen =)
    Ich werde übrigens noch ein klein wenig umbauen am BSP Compiler, damit er schneller läuft, die Delphi Version läuft 5x schneller... Es ist gar nicht notwändig, immer dyn. Arrays zu nutzen, einige können ruhig statisch sein...
    Wenn das Testprogramm fertig ist, werden schon die Rendering Funktionen im BSP eingebaut sein, die du dann einfach in die Engine verbauen kannst. Naja, du wirst (hoffentlich) sehen =)

    Naja, in D3D wird das mit deinen "Extensions" letztendlich ähnlich gehandled. Bei der Initialisirung kann ich mir alle Funktionen der Graka auslesen und daraus entscheiden, was gerendert werden kann und was nicht.. Das alles sollte aber intern in den einzelnen Treibern ablaufen, bekommt mein D3D Modul z.B. den Befehl ein Polygon mit 4 Texturen zu zeichnen, prüft es erstmal, wie viele Texturen überhaupt auf einmal von der Graka gezeichnet werden können (Multitexturing). Sind es genug, werden alle in einem Zyklus gezeichnet, andernfalls werden sie manuell übereinander gelegt. Es muss nur am Anfang die Möglichkeit bestehen, Grafikkarten mit zu niedriger Funktionalität nicht zu akzeptieren und z.B. nur Software anzubieten...

  13. #13
    Registered User
    Registriert seit
    May 2000
    Beiträge
    905
    Renommee
    10
    @BSP
    Ist schon klar das das Teil erstmal fertig gestellt werden muss. Ich wollte damit nur andeuten das wir ohne nen grossen Schritt in Richtung Planung das nicht einbinden können, da die Gravitation einer Rakete (Luftzug) zum Beispiel nicht durch die Wände wirkt etc...
    Wir brauchen also für fast alles was im Level passiert den BSP-Tree, deshalb kann er nicht als eigenständiges, austauschbares Objekt bestehen.

    Naja, in D3D wird das mit deinen "Extensions" letztendlich ähnlich gehandled. Bei der Initialisirung kann ich mir alle Funktionen der Graka auslesen und daraus entscheiden, was gerendert werden kann und was nicht.. Das alles sollte aber intern in den einzelnen Treibern ablaufen, bekommt mein D3D Modul z.B. den Befehl ein Polygon mit 4 Texturen zu zeichnen, prüft es erstmal, wie viele Texturen überhaupt auf einmal von der Graka gezeichnet werden können (Multitexturing). Sind es genug, werden alle in einem Zyklus gezeichnet, andernfalls werden sie manuell übereinander gelegt. Es muss nur am Anfang die Möglichkeit bestehen, Grafikkarten mit zu niedriger Funktionalität nicht zu akzeptieren und z.B. nur Software anzubieten...
    Das will ich ja sagen, aber fällt dir dazu ne vernünftige Idee ein ? Mir nicht ! (noch nicht)


    die du dann einfach in die Engine verbauen kannst
    Darauf wollte ich auch hinaus ... Es ist leider weder einfach noch denke ich das ich alleine schaffen werde ...
    Wenn der Anhang mal freigeschaltet werden solle (2Posts dadrüber): Da steht drin was ungefähr geplant werden muss und einige Abhängigkeiten ...
    Hiermit möchte ich mich in aller Form für diesen Beitrag entschuldigen.
    Ich verspreche, es kommt nie wieder vor !


    Life Suckz !!!

  14. #14
    Registered User
    Registriert seit
    Feb 2001
    Beiträge
    230
    Renommee
    10
    Stimmt.. vielleicht sollten wie ein neues Projekt starten (natürlich in VC++ *g*), das dann jeder von uns immer erweitert! Ich würde dann schonmal die Klassenstrukturen schreiben, die zum Rendern notwändig sind, wärend du dann z.B. versuchen könntest, den OGL Renderer anzufangen...
    Das Rendern des BSPs wird letztendlich so aussehen, dass ich für jedes zu rendernde Polygon eine Funktion des Renderers aufrufe, und diesem die Indexnummer des Polygons übergebe. Mehr als eine Indexnummer brauch der Renderer auch nicht, da er ja ebenfalls vollen Zugriff auf die Daten des BSPs hat.
    Jedes Polygon enthält dann Informationen wie Vertices, Textur(en) und deren Position auf dem Polygon, Informationen darüber, wie die Texturen gezeichnet werden sollen...
    In D3D gibt es wie wohl in OGL auch verschiedene Methoden, wie mehrere Texturen zusammengesampled werden. z.B. durch Multipliziernen (Modulate), Addieren etc etc.. da gibt es eine ganze Reihe... ich schick dir dazu mal ein Beispiel aus dem DX SDK, wie das Zusammenstellen mehrerer Texturen aussieht...

    Natürlich müssen wir vorher ausmachen, dass niemand die Dateien des anderen ändert, bzw wenn doch Änderungen vorgenommen müssen, dann nur in Absprache...
    Ich denke das wäre ein wichtiger Schritt, damit wir mal weiter kommen.. so könnte ich z.B. den BSP weiter coden und du könntest beim Testen helfen, indem du schonmal mit dem OGL Modul anfängst, welches so oder so geschrieben werden muss..

    Damit wir das ganze auch starten können, sollte die Engine erstmal in EXE Form geschrieben werden, der Aufbau aber zur späteren Umstellung auf DLL geplant werden... So brauchen wir uns auch erst später wirklich Gedanken über die Schnittstelle zu machen, was wie ja sowieso erst dann können, wenn die Engine fertig ist...

    Also, was nehmen wir als Basis? Schick mal eine aktuelle Version des Klassenkonstrukt Teils als EXE Projekt, das dürfte eine gute Basis sein..

    P.S.: @all: Sorry, dass sich oben der Code nur mit ein paar kleinen Änderungen in VC++6.0- compilieren lässt, ich habe erst später gemerkt, dass VC++.NET und VC++6.0 nicht ganz kompatibel sind (sich dies aber erzwingen lässt). Alle zukünftigen Versionen werden kompatibel sein

  15. #15
    Registered User
    Registriert seit
    May 2000
    Beiträge
    905
    Renommee
    10
    Shit, also ich binn zwar im Moment viel zu angetrunken um da rauf eine adequate(wow) Antwort zu geben aberich versuchs einfach mal ...

    Stimmt.. vielleicht sollten wie ein neues Projekt starten (natürlich in VC++ *g*), das dann jeder von uns immer erweitert! Ich würde dann schonmal die Klassenstrukturen schreiben, die zum Rendern notwändig sind, wärend du dann z.B. versuchen könntest, den OGL Renderer anzufangen...
    hmm, ich weiss jetzt net ob du das Problem richtig verstanden hast, aber wir brauchen die Struktur, den Renderer zu entwickeln, das ist ne Sache von 5min. Das ganze zu optimieren kann schonmal 1-2 Tage dauern. Aber nichts was wirklich zu schwer sein sollte. Allerdings nützt uns das ganichts wenn wir nicht ein Klassenkonstrukt haben worin wir das alles einfügen können und *blup#* vergessen was ich sagen wollte, ?egal .

    Wir brauchen erst das Konstrukt ! Fertig. (morschen mehr)

    @Demo
    hmm, das Teil kann ich erstmal garnet starten ...
    Irgendwas mit meinem oder deinem D3D stimmt da wohl net ...
    naja, egal ...
    Darauf kommt es auch garnicht an ... Es geht wie gesagt nicht um spezifische Probleme wie nun Texturen übereinander geblendet werden etc... sondern um das generelle Verwalten dieser SpezialFunktionen. Ich kann später nicht für jede neue ModelKlasse 10 ifs machen ob den nun MultiTexturing oder CompiledVertices Verfügbar sind. Oder doch nur ne alte SGI Extension oder vielleicht T&L oder was es auch immer noch für praktische Extensions gibt...


    @Exe
    Das gleiche Problem, wenn das ganze Teil nachher als Exe + 3 DLL's laufen soll können wir das net ohne Probleme auf einer Exe entwickeln ... Das umschreiben würden nachher vielleicht nicht mehr klappen, da unsere Strukturen in der Exe dies Unmöglich machen ....

    PS: Die momentane Version mit den DLL's funktioniert wunderbar ...
    Also daran könnten wir den BSp auch schon testen, wennde rfagen hast wie, dann frag *ggg*
    Ich hab das Teil auch schon etwas weiter geschrieben so da das window in der CoreEngine erstellt wird, den Context darauf legen sollte dann einfach die jeweilige Api DLL übernehmen ...
    Dann kannste auch schon dein BSP Dingda darauf rendern ... In D3D und OGL dürfte dann auch eine Sache von 5seks sein ...

    So, bevor ich jetzt weiter diese leicht hin und herschwingen Buchstaben sehen muss geh ich doch noch lieber aus und sauf mir richtg einen an ....
    Man sieht sich ..
    BYe
    Hiermit möchte ich mich in aller Form für diesen Beitrag entschuldigen.
    Ich verspreche, es kommt nie wieder vor !


    Life Suckz !!!

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. 2D - Engine
    Von ChickenInvader im Forum Algorithmen und sonstige Programmiersprachen
    Antworten: 3
    Letzter Beitrag: 06.08.2006, 11:52
  2. HTML Engine
    Von TMoS im Forum Pascal / Delphi
    Antworten: 12
    Letzter Beitrag: 12.10.2005, 14:48
  3. Engine und 3DSM
    Von holzhacker im Forum C / C++
    Antworten: 8
    Letzter Beitrag: 13.08.2003, 18:45
  4. 3d-Engine
    Von tobi im Forum VisualBasic / VBScript
    Antworten: 1
    Letzter Beitrag: 22.10.2001, 19:04

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •