spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

natürlich, ich meinte natürlich anders herum :-)) ;D :jojo:

David, ich bin eben hängen geblieben und würde es Dir nicht übel nehmen, wenn Du mal den Thread um die zwei letzten Einträge von mir kürzen könntest.
Danke

bin ja selber schuld. Ist manchman so, wenn man zwischen verschiedenen Projekten hin und herspringen muss. Da negiere ich Zahlen usw. Es gab ganz sicher eine Verbesserung! ;-)

Aber wenn ich noch weiterreden darf...
Auch die Methode BoxHitsBox hat bei mir Probleme ergeben, wenn ein Körper um ein mehr als vierfaches kleiner war, als der andere.
In dem Fall musste ich den Parameter iSamples erhöhen. Doch es haben nicht alle Körper dieses Verhältnis. Die Erhöhung der Samples erhöht die Ablaufzeit drastisch.
Also habe ich mir gedacht, dass nicht die Eckpunkte, sondern die Linien die Box schneiden müssen, um eine Boxkollision als wahr zu erkennen.
Dummerweise funzt die Methode LineHitsBox auch nicht viel schneller.
Kann man die noch optimieren.
So, dass kein Kollisionspunkt ausgerechnet wird.
So ähnlich wie LineHitsPlaneFast, nur dass diese Funktion in diesem Fall natürlich falsch ist, denn das Dreieck ist schon begrenzt...

Sag mir ruhig, wenn ich zu viel rede.

danke erst mal für Deine Bemühungen.
Spheretest kann ich vergessen.
Die Spheren sind komischerweise so groß!!!
Ich weiß nicht, warum. Irgendwie muss hier die Funktion D3DXComputeBoundingSphere... Oder besser irgendwie mache ich hier noch was falsch.
Also auf deutsch: Der Spheretest hilft wirklich nur fürs erste Erbrechen.

Die BoxBox-Funktionen zu optimieren incl. OcTree halte ich für besser.
Ist es Dir schon aufgefallen, dass ein ziemlich kleiner Körper beim Durchwandern eines größeren immer Kollision nicht Kollision, Kollision nicht Kollision anzeigt... und das, bis er aus dem anderen Käörper herausgewandert ist. (natürlich bei deaktivierter React-Funktion, der physikalischen Einheit der Tribase ;-) )

Mit LineHitBox funzt das immer richtig.
Muss mal nachsehen, wass es da anderes gibt...
Aber Du meinst jetzt nicht etwa die Bibo von magic-software mit der Berücksichtigung der Zeit (der Geschwindigkeit)?

Bis später
Jens

z. B. das MS Sample heli.x.
Da ist ein toller Rotor oben dran.
Der Radius ist demzufolge riesengroß.
Aber ich habe auch noch den Verdacht, dass sich die DX-Funktion bei der Berechnung des Radius im Mesh tyni.x verrechnet.
Ich finde bei mir keinen Fehler und trotzdem ist der Radius viel größer, als die größte Ausdehnung.
OK, ich bin gespannt auf die Methoden, die Du findest...
Viel Erfolg.