Suchergebnisse
Suchergebnisse 1-20 von insgesamt 53.
naja, es ist nicht schön, wenn man bei einer kollisionsabfrage ins ruckeln kommt. habt ihr keine vorschläge ? mfg soxx
hmm die frage ist dann, wie man diese performanter machen können - bessere implementierungen habe ich bislang noch nicht gesehen... mfg soxx
hallo ! nein, dort kann man nichts angeben - die funktion arbeitet mit den bounding boxes des octree´s. ich arbeite aber prinzipiell ohne die tribase engine. mfg soxx
Hallo ! ich habe mal eine prinzipielle frage zur performance einer kollisionserkennung: ich verwende derzeit folgende "module" - die octree geschichte von david - obb intersection abfrage von gomez (vgl. boxhitsbox2 von david) - triangle-triangle intersection von Tomas Moeller - ich erstelle auch eigene kollisionsmodelle mittels simplify mesh trotzdem dauern meine kollisionsabfragen unheimlich lange. ich überprüfe derzeit 2 modelle auf kollision - einen zylinder (mit ca. 360 faces und 222 vertiz...
hmm... nur mal auf die schnelle: dein gesaeubertes mesh ist ja tmptmpMesh, warum laesst du dann m_pmesh vereinfachen ? (es ist ja nicht gesaeubert worden). mfg soxx
hallo ! habe leider auch noch nicht mit shadern gemacht. hier gabs eine diskussion bei gamedev.com: http://www.gamedev.net/community/forums/topic.asp?topic_id=389954&whichpage=1� habs mir mal durchgelesen - vielleicht hilt dir das etwas. jedenfalls die idee mit der textur, die jemand dort hatte klingt etwas komisch - wenn die kamera sich bewegt hat man damit ein problem. ( aber man kann das sicher relativ leicht modifizieren und implementieren ) ich meine, wenn die kamera sich bewegt, be...
ich hab da mal schnell was "rausgemergelt". ergebnis des tests mit 2 dreiecken: die kollisionsabfrage funktioniert mit 2 dreiecken immer (egal wie ausgerichtet) ABER NUR ( :lol: ) WENN sich dreieck A nach rechts und B nach links bewegen. vice versa funktioniert NICHT ! kann also nur an der matrix liegen !?! mfg soxx
Zitat von »"Spik)evil("« Eine komplette Codeanalyse ist für Unbeteiligte einfach zu viel Arbeit... da hast du absolut recht. bez. neuanfang. habe heute angefangen, alle bereiche die anscheinend nicht funktionieren, wieder neu von der tribase zu importieren. diese musste ich natürlich wieder anpassen -> aus tbvector3 => d3dxvector3 etc. -> das resultat ist immer noch das selbe :? wenn man sich nun die dreiecke anguckt, die bei der kollision verglichen werden, findet man auch keinen fehler -> hab...
wieder mal ich habe mich jetzt die letzten 2 tage von dem problem mit der kollisionserkennung distanziert heute habe ich nochmals den code, den ich mit der tribase engine vergleichen kann, verglichen. auch diesmal keinen fehler gefunden. kann mir wirklich KEINER einen RAT geben, woran die kollisionstests scheitern können ????? mfg
hallo ! aus dem zfx-forum: Zitat ToyToy: Du könntest z.B. 2D-Polygone für die offen gelegten Bereiche speichern. Mit denen könntest du dann auch gleich das Culling machen. Desweiteren sind Effekte wie das langsame Verkleinern des Bereiches einfach zu implementieren. Maxible: In WarCraft 3 wird das Gebiet vom Nebel des Krieges etwas dunkler gemacht und man sieht keine Bewegungen und keine Objekte / Einheiten ausser der Landschaft und den Bäumen.
der debugger ist mein bester freund. das problem ist, dass ich alles und auch wirklich alles unabhängig von tribase geschrieben habe - ich habe nur die kollisionserkennung von der tribase entnommen. ich kann nicht einschätzen, wie viel aufwand es jetzt wäre, das programm (ATL) kompatibel mit der tribase engine zu machen - wahrscheinlich würde das wieder ein paar tage dauern... bez. dem problem: es ist wirklich sehr sehr sehr sehr komisch, ich habe aktuell nur die dreieckskollisionserkennung an ...
Zitat von »"DarkRaider"« Sind wir hier bei Beepworld.de oder was? hehe, nein aber ich wollte nur andeuten, dass ich hilfe bei der kollisionserkennung benötige - ich weiß leider absolut nicht wo der fehler (einer/mehrere) sein könnte - ist irgendwie relativ unmotivierend, wenn man schon 1 woche bei der kollisionserkennung rumackert. mfg soxx
@david: in tbUtils.cpp kann es sein, dass du in der funktion tbTriangleHitsTriangle im 6ten fall: C-/C++-Quelltext 1 2 3 4 5 6 else if(fL2A >= 0.0f && fL2B <= 1.0f) { // Fall 6! if(pvHitStart) *pvHitStart = vL2A; if(pvHitEnd) *pvHitEnd = vL2B; } ein "return TRUE" vergessen hast ? mfg soxx
D3DFVF_TEX1 sagt soviel aus: es ist ein textur-koordinaten-paar einem vertex zugeteilt. bei tex0 kann ich nur mal spekulieren - ich glaube, dass du dann quasi kein textur-koordinatenpaar verwendest bzw. es nicht benutzt wird. google: D3DFVF_TEX0 indicates that you are not sending any texture co-ordinates at all mfg soxx
Hallo ! anbei die render states, die du für das rendern einer textur mit einem dreieck benötigst (bzw. vice versa) SetRenderState(D3DRS_CULLMODE, D3DCULL_CCW); // äußere seiten sind sichtbar SetRenderState(D3DRS_LIGHTING, FALSE ); SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_SELECTARG1); // textur auf dem 0ten index wird gerendert SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE); SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA); SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA); SetFVF(D3DFVF...
... :roll: nun ja, wenn man weiß, dass man bei der invertierung der matrix, die determinaten auf NULL gesetzt hat... dann wird wohl die rotation nicht mitberücksichtigt ganz perfekt läuft die kollisionsabfrage trotzdem noch nicht - tbBoxHitsBox - plagiat reagiert zu früh und tbBoxHitsBox2 plagiat reagiert überhaupt nicht. C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 ...
ich habe gerade versucht boxhitsbox in der kollisionserkennung auszuschalten -> somit wird quasi jeder quader (aus dem octree) durchprobiert. das lustige ist, dass, wenn die 2 objekte noch weit auseinander sind, schon eine kollision auf dreiecksbasis erkannt wird. (den fehler zu suchen, ist schon langsam nicht mehr lustig :? ) keine ahnung wo sich der fehler versteckt... mfg
Hallo ! vielen dank dass du dir die arbeit angetan hast (durchlesen des codes) Habe gestern nochmals den code mit davids engine verglíchen - es ist einfach nichts auffindbar... *edit*: bin mir zu 99% sicher das der code bei boxhitsbox/2 stimmt -> weggelöscht. habe noch einen fehler gefunden - und zwar wurde der zylinder nicht richtig eingelesen - hatte zuerst mit clonemeshfvf versucht, das mesh in das richtige format zu zwingen - hier gab es aber anscheinend einen fehler. den eigentlichen fehler...
das mit den matrizen ist reine gewöhnungssache kommt alles mit der übung. mfg soxx
23.04.2024, 10:29
Zum Seitenanfang
