Ja, lässt sich drüber nachdenken. Ich kann die Tage ja mal ein paar Bilder online stellen. Den Qualcode gebe ich erst raus, wenn ich der Meinung bin, dass Jemand der ihn sich runterläd auch tatsächlich etwas damit anfangen kann. Ausserdem sollen keine Borlandunits benutzt werden. Eigene 'tList' & co kg...
Kann mir zudem einer einen Tipp geben, wie die CollisionDetections bei einem BSP-Teil funzten? Ich habe etliche kilo Papier verschwendet und bin trotzdem nicht auf die Lösung gekommen. Als Informationsquelle diente ledigtlich der Q2 source (in c). Seit ein paar Tagen habe ich das teil als Delphisource vorliegen und bin eher verwirrter als das mir das ersehnte Licht aufgeht.
Octrees... Ich dachte, dass das die Rendertechnik ist, die bestimmt, welche Flächen ich von MEINEM Ocrteefragment aus sehen kann und welche nicht. Das was Octree eigentlich darstellt, wird von mir dann auch benutzt!
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
cyanide hat geschrieben:
Octrees... Ich dachte, dass das die Rendertechnik ist, die bestimmt, welche Flächen ich von MEINEM Ocrteefragment aus sehen kann und welche nicht. Das was Octree eigentlich darstellt, wird von mir dann auch benutzt!
Octree ist keine Rendertechnik, sondern genauso wie BSP einfach eine Raumunterteilungstechnik, bloß mit nem anderen CPU/GPU-Ration (für moderne Systeme also besser). Ob du nen nen BSP oder nen Octree für deine Kollisionsabfrage/Rendering nutzt ist doch im Endeffekt egal...
Wobei, wenn du eh nur auf einer Landschaft rumläufst, ein QuadTree die selbe Funktionalität bietet - und eventuell etwas einfacher in die Landschaftsgeneration eingebaut werden kann, wenn du die Tesselation der Landschaft entfernungsabhängig machst.
P.S. hast du als Grafikdesigner nicht jede Menge ganz tolle Eingabegeräte, dass dir eine Maus mit Scrollrad abgeht?
Registriert: Di Feb 25, 2003 15:10 Beiträge: 147 Wohnort: Koblenz a. Rhein
@SoS: das 3. mal um genau zu sein
Also... Der Sache mit den Octrees muss ich zustimmen...
Die dinger sind genial ! Haben bei mir die Performance um ca 40% gesteigert ...
Beim Rendern guckst mit Frusum Culling welche Octrees in deiner Sicht sind und eichnest nur die und bei der Kollision musst die hinter dir auch noch einbauen ( nicht vergessen hab ich ma.. da konnte man dann rückwärts durch wände gehen 8D )...
Die sind einfach zu errechnen ( kannst auch statische machen im Prinzip ) und einfach zu behandeln... kannst z.B. einfach alles in einen Array aus Displaylisten packen, aber da du ja anscheinend öfter mal die Matricen ändern willst in Vertex-Arrays... da kannst fummeln wie du willst dann machs am besten mit Triangle_Strip... die haben die höchste Performance ( wie eine Demo von SoS zeigt... ((die war doch von dir oder ??)) da werden Displaylisten mit Arrays (Tris, und Strips) verglichen.. hatte bei mir gut das doppelte als die displaylisten)...
Und wenn du dann noch optimieren willst musst dynamische Octrees oder BSP-Trees benutzen ( Die belasten die CPUs aber stark... heute nur noch für Kollision zu gebrauchen, aber da sehr effektiv.. )
Für die Player würde ich persönlich die Kugel empfehlen.. ungefähr gleiche Rechenzeit ( nur Mittelpunkt und Radius benötigt ) und wesendlich einfacher zu implementieren... ( die Linien zu drehen fällt mir persönlich schwer da hatte ich vor kurzem ma ein Thema hier im Forum... mit der Trigonometrie oder wie das heißt )
Vorallem bei Player-Player-Kollision sehr vorteilhaft und genau ! sonst duckt sich der eine und kann schräg halb in den anderen reinlaufen das willst du bestimmt nicht... ( das lässt sich aber auch vermeiden )...
viel Spaß am Coden und viel Erfolg !!!
CyA !!
NiGhTmArE
_________________ mir fällt kein Spruch mehr ein für meine Signatur naja...
Ja...
Das muss ich mir alles mal genau zu Gemüte führen.
Ich habe keine Zeit mir noch einen Leveleditor zu schreiben. Hat einer einen Link von einem Guten, den man Übergangsweise benutzen könnte?
Die Sache mit den Geo-Formen für die CollisionDetection ist nicht so einfach. Aber im Grunde habt ihr vollkommen recht. Ich hatte vorallem vor, Vehicles in die Gameengine einzubauen und irgendwie aber garkeine lust daraus ein Spiel zu coden *lol*... Wenn jemand lust hat, kann ich ich ihm die Gameengine (wenn der host halbwegs tut) zur Verfügung stellen und schonmal ein wenig damit rumbasteln. Ich habe für ALLES definitiv zuwenig Zeit
Und die 'Octrees' schaffe ich heute Abend hoffentlich fertig.
Ich habe noch ein problem mit OpenGL:
hab mir son kleines Spritesystem geschreiben. Hat ansich nicht viel mit dem folgenen Fehler zu tun, wurde mir da aber erst bewust, dass ich so einen habe... Ganz egal, wie oft ich die Farbe von einem Sprite (ihr nennt die glaub ich Partikel) änder - es passiert nichts. Wenn ich jedoch die Alphaintensität verstelle, werden sie tatsächlich nach gewünschtem Wert durchsichtiger. Ich habe mir andere Tutorials angeschaut, wo Polygone mit Textur eingefärbt werden und mit meinem Code vergleichen. Eigentlich keine Differenz festzustellen, ausser das ich teilweise mehr Code benutzt habe, um andere Sachen darstellen zu können. Wie kann man das Einfärben von Objekten generell ausstellen und wie wieder an, so dass ich vielleicht ne Idee bekomme, was nicht funzt... Oder anders gesagt: Nach welchen Befehlen bleiben 'weisse' Polys mit vorgesetztem glColor3f( 0.5, 0.5, 0.5 ) doch weiss?
* Materialfarbe auf weiß setzen
* Beleuchtung einschalten
* mit glDisable(GL_COLOR_MATERIAL); sicherstellen, dass keine Materialkomponenten verändert werden - damit ist glColor3f de facto ausgeschaltet.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Bist du dir auch ganz sicher, das du die Beleuchtung nicht doch aktiviert hast?Wenn ja,dann wird ein Aufruf an glColor nämlich ignoriert, solange du nicht über glEnable(GL_COLOR_MATERIAL) das Color-Tracking aktiviert hast. Denn ansonsten gibts keinen Befehl der die Farbgebung behindert.
Ah... Ich hab noch eine Stelle gefunden, wo ich ein LIGHT in der Map habe. Ich versuche das nachher Zuhause mal ohne das Licht... Obwohl... Eine Beleuchtete Scene sollte auch verschiedenfarbige Objekte beinhalten können
Materialien habe ich noch nicht benutzt. Ich bin mir zudem auch noch nicht ganz so sicher, ob ich Die überhaupt brauche.
Wofür sind Materials eigentlich gut, ausser für Specular Highlight?
Wenn du keine eigenen Materialparameter spezifizierst, sind halt die OpenGL Standardparameter aktiv.
Zitat:
Wofür sind Materials eigentlich gut, ausser für Specular Highlight
Um das OpenGL Beleuchtungsmodell auszunutzen, du kanst Farben für die Ambient, Diffuse, Specular und Emission Komponenten vergeben, außerdem noch den Shininess Faktor.
mit glLightModel kannst du außerdem noch zusätzlich bestimmen, ob z.B. die specular Highlights erst nach der Texturierung aufgetragen werden.
Im Endeffekt sind Materiale und das OpenGL Beleuchtungsmodell also gar nicht mal schlecht - es lassen sich sogar unterschiedliche Materiale für Vorder- und Rückseiten festlegen! Ich finde sie jedenfalls sehr praktisch, zumal sie auch recht gut von der Hardware beschleunigt werden und mit wenig Aufwand implementierbar sind.
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.