zu mir:
najo, ich bin nicht so netzaktiv und meine mathematischen kenntnisse sind auch nicht sooo die geilsten.
ich habe zuhause ne 3D engine (delphi, opengl) am start und bin grad dabei ne collision detection zu implementieren. die engine selber ist bis jetzt so optisch auf dem stand von Q2.
gfx/snd/input engine ist von der gameengine sauber getrennt.
ich kann in gewissen zeitzyklen die engine mit sourcecode online stellen. der ei oder andere wird da sicher schöne sachen für sich finden
najo... zurück zum problem. hat jemand ne idee, wie man eine abfrage ob eine traceline ein polygone schneidet sinnvoll gestalten kann ?
bisher benutze ich was selbstgedrehtes, was ich so noch nirgends gefunden habe. ich nehme die POLY-endpunkte und nehme für den ersten durchgang nur die x und z coods. von denen bekomme ich dann einen winken zu den x und z coords des tracestartpoints. und dann muss ich nur noch den winkel von tracestart und traceend wissen und kann fragen ob der winkel zwischen den beiden äussersten winkeln des polys liegt. danach das ganze nochmal mit y und ich habe eine test-scene mit 200.000 polys auf ca. 0.01% colltests geschrumpft.
funzt! ich ahbe es ausgiebig getestet. auch wenn tracestart ganz nahe vorm poly ist.
weiss jemand was besseres ?
ich würde mich freuen, von euch mal was schönes zu hören
Registriert: Sa Nov 02, 2002 18:06 Beiträge: 299 Wohnort: Dresden
*box*
Guck mal bei sulaco.co.za da gibts ein komplettes Beispiel für Line-Tri-Intersections.
*nochmal box*
Edit: Ach ja, wofür ist das da? Kollision? Dann würde ich's anders machen. (Kollision mit BSP abprüfen). Weil sowas doch ganz schön aufwendig ist (Line-Triangle Intersection)
_________________ "Ich würde ja gern die Welt verändern, aber Gott gibt mir den Quelltext nicht"
aha... wenns läuft bin ich schonmal etwas glücklicher. meine derzeitige abfrage funzt via matrix. und wenn ich auch den code zeige, erschlagt ihr mich sicher mit was ganz hartem
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
@HomerS :
Bitte poste keine so großen Quellcodes mehr,zumal obiger ja identisch mit dem von Sulaco ist,da das die Foren-DB nicht mag.
@Cyanide :
Wenn du Spieler-Landschaftskollision machen willst,dann benötigst du definitiv eine Routine die nur die in der Nähe des Spielers liegende Geometrie für einen Kollisionstest in Betracht ziehst.Dazu empfiehlt sich bei einer Landschaft übrigens ein Octree,denn man dafür sowieso bereits zum Rendern nutzen sollten.Danach reicht es wenn du den Spieler als 3 Linien darstellst (seine drei Achsen) und diese dann mit der umliegenden Geometrie auf Kollision testest.Alternativ kannst du den Spieler auch als eine Kugel beschreiben lassen und diese gegen die Polygone testen,was auch recht häufig gemacht wird.
das ist falsch. ich habe teilweise tests, die von einem ende bis zum anderen ende der map reichen.
meine maps unterteile ich aber später mit einem neuen system. das stelle ich dann hier auch vor. ich will versuchen den skybackground interaktiv zu halten und da dann die weltteile reinrendern, die zu weit entfernt liegen. hierbei ist aber wichtig, dass spieler die hinter der map stehen trotzdem ganz oder durch verdeckung theoritisch daseiender wände nur halb oder garnicht gezeichnet werden. und figuren sollen ab einer gewissen reichweiter nur noch als sprites dargestellt werden. die engine rechnet beim laden einer map die sprites selber aus, indem die die figuren von allen seiten zeichnet und texturen draus macht. ab den entfernungen, wo diese dann statt der normalen figuren gezeichnet werden, merkt man das nicht mehr
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Und trotzdem wäre ein Octree doch ne gute Alternative,selbst wenn du den nicht für dein LODding benutzt.Viele Spiele nutzen ihre BSP-Bäume auch nur zur Kollisionserkennung und nutzen fürs Rendern andere LOD-Techniken.
Denn durch nen Octree kannst du doch ganz einfach testen welche Boundingbox dein Strahl geradet durchschneidet und musst dann nur gegen die zu dieser Box gehörenden Polygone testen.
Ansonsten ist das was du da vorhast recht unklar.Erklär das mal etwas genauer.
ok... ich weiss jetzt nicht genau, was unklar ist. deswegen werde ich jetzt mal etwas ausholen:
start der entwicklung war vor ca. 4 wochen. ich code aber schon sehr lange, wodurch die engine einen schon recht guten status hat.
ich muss mich aber derzeit leider mit allem beschäftigen, da ich ganz alleine an dem projekt arbeite und unbedingt alle ideen umsetzten will. dadurch sind einige schönheiten auf der strecke geblieben. angefangen hat alles mit einem tutorial von NEHE. darauf habe ich erstmal einen landscapegenerator gesetzt. sah dann alles ganz nett aus und ich war motiviert genug ne gameengine zu schreiben. aös nächstes kam dann ein MD3 modelloader und kurz danach ne (wenn auch total blöde) KI. jetzt konnte ich mich schonmal mir doofen MD3-schwertkämpfern mit toll aussehenden raketen um frags streiten.
toll
naja... dann kam ich da irgendwie in das ganze rein und habe alles erstmal getrennt. alles was irgendwie nicht so richtig mit einem spielregelwerk zusammenhängt auf die hostseite und die gameengine samt den regeln und co in dei gameengine. ähnlich wie bei Q3/Q2.
grafik:
texturen sind, wenn nicht selbst gemacht, erstmal von anderen spielen geklaut. ebenso wie die MD3 models (irgendwie ansich logisch).als beruflicher grafikdesigner mache ich aber auch vieles schon selbst (aber mir fehlt die zeit). das landscape besteht derzeit aus ca. 80.000 polygonen. ich habe eine Gef2MX und einen AMD950 MHz prozessor. ist immer recht scheisse, wenn ich mir ein schönes tutorial runtergeladen habe und nette fehlermeldungen bekomme, dass meine GraKa zu blind dafür ist
sound:
OpenAL. ich bin definitiv begeistert, was da geht. davor habe ich mit Direct Sound gebastelt und somancher weiss wie frustrierend die teilweise nicht nachvollziehbaren fehlermeldungen seien können. SDKs habe ich mir bisher nicht holen können, weil ich erst wieder seit kurzem zugang zum i-net habe. ich hoffe jetzt wird alles besser
netz:
ich habs mal kurz versucht... aber mit nur einem rechner sind die resultate nicht so doll... kann ja nicht wirklich testen, ob die coordinaten syncronisiert werden, wenn ich das spiel nur einmal laufen lassen kann........ und wenn.... ist die durchsatzrate ok? übermittelt er durchgängig daten? ich lass es erstmal
input:
naja... keine grosse aufgabe... und das mausrad bekomm ich auch noch abgefragt... (das doofe) ..... vorher brauche ich aber ne maus mit mausrad *grml*
colldet:
hehe... wer DEN code sieht wird mich erschlagen! definitiv...
ich habe ein matrixsystem benutzt, dass ganz toll alles ausrechnet. ich bekomme den genauen schnittpunkt und allesfunktiert super! einziges manko: mehr als 5000 pro sekunde sind nicht drin... dafür sorgen 400 zeilen 'EquationSolver' code. najo, das ganze konnte ich auch etwas drosseln. mit dem winkelabfragen von möglichen testflächen habe ich einiges rausgeholt. aber die 80.000 polygone schaff ich damit trotzdem nicht wenn ich dabei an eine akzeptable framerate denken will.
noch fragen offen?
grx_cyan
ps: ich bekomme die oben vorgeschlagene abfrage definitiv nicht zum laufen. muss ich noch wirgendwas beachten? ich habe bislang noch nicht mit 'normalen' getestet... kann ich nachher ja nochmal probieren.
pps: meine rechtschreibfehler basieren zumeist darauf, dass ich schneller schreibe als ich mit den augen das geschriebene korrigieren kann. manchma lesen sich meine sätze auch etwas strane... bin zu faul mir das ganze hinterher nochmal durchzulesen. wenn ihr mich genug boxt, dann kann ich mir das mal angewöhnen ^^
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Hab doch bereits mehrere Male erwähnt das ein Octree die beste und performanteste Lösung für das Geschwindigkeitsproblem deiner Kollisionsabfrage sein könnte.Wie gesagt testes du halt nur die Polygone die zu der Octree-Boundingbox gehören durch die dein "Strahl" verläuft.Einfacher und besser gehts nicht.
P.S. : Dein obiger Text war echt quallvoll zu lesen.Die deutsche Sprache bietet dir doch sowas wie Groß-/Kleinschreibung an.
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.