kollisionsverhalten bei Steigungen

Übersicht

BlitzBasic

Blitz3D

	Ana Betreff: kollisionsverhalten bei Steigungen	Mi, Jul 07, 2010 15:44 Antworten mit Zitat
Hallo zusammen, ich möchte manuell bestimmen können welche steigungen eine Entity noch mit moveentity schaft und welche nicht, normaler weise ist das ja geschwindigkeitsabhängig(?), nun verrecken mir beim langsamen gehen die objekte halt an jedem Sand haufen wo ich sie gern drüber laufen lassen würde. Kann man das irgendwie einstellen oder sowas?

Ana

Betreff: kollisionsverhalten bei Steigungen

Mi, Jul 07, 2010 15:44
Antworten mit Zitat

Hallo zusammen,

ich möchte manuell bestimmen können welche steigungen eine Entity noch mit moveentity schaft und welche nicht, normaler weise ist das ja geschwindigkeitsabhängig(?), nun verrecken mir beim langsamen gehen die objekte halt an jedem Sand haufen wo ich sie gern drüber laufen lassen würde. Kann man das irgendwie einstellen oder sowas?

	ToeB	Mi, Jul 07, 2010 16:21 Antworten mit Zitat
Ja, liegt an dem wert, mit dem du das Object nach unten bewegst (-> Gravitation) mfg ToeB
Religiöse Kriege sind Streitigkeiten erwachsener Männer darum, wer den besten imaginären Freund hat. Race-Project - Das Rennspiel der etwas anderen Art SimpleUDP3.0 - Neuste Version der Netzwerk-Bibliothek Vielen Dank an dieser Stelle nochmal an Pummelie, welcher mir einen Teil seines VServers für das Betreiben meines Masterservers zur verfügung stellt!

ToeB

Mi, Jul 07, 2010 16:21
Antworten mit Zitat

Ja, liegt an dem wert, mit dem du das Object nach unten bewegst (-> Gravitation)

mfg ToeB

Religiöse Kriege sind Streitigkeiten erwachsener Männer darum, wer den besten imaginären Freund hat.
Race-Project - Das Rennspiel der etwas anderen Art
SimpleUDP3.0 - Neuste Version der Netzwerk-Bibliothek
Vielen Dank an dieser Stelle nochmal an Pummelie, welcher mir einen Teil seines VServers für das Betreiben meines Masterservers zur verfügung stellt!

	Ana	Mi, Jul 07, 2010 18:17 Antworten mit Zitat
Hm ja das hatte ich fast erwartet, aber das heißt ja das sie dann relativ langsam fallen wenn sie hohe Steigungen schaffen oder nicht? Diese Beziehung gefällt mir ja gerade nicht^^

Ana

Mi, Jul 07, 2010 18:17
Antworten mit Zitat

Hm ja das hatte ich fast erwartet, aber das heißt ja das sie dann relativ langsam fallen wenn sie hohe Steigungen schaffen oder nicht? Diese Beziehung gefällt mir ja gerade nicht^^

	PacMani	Mi, Jul 07, 2010 18:54 Antworten mit Zitat
Also mit sowas habe ich mich verdammt lange rumgeschlagen. Dann hatte ich eine Lösung gefunden, mit einem zweiten Kollisionsentity immer die Steigung zu überprüfen, bevor ich das eigentliche Entity da hin bewege. Je nach Stärke der Steigung habe ich dann das Hauptobjekt überhaupt oder garnicht bewegt. Würde dir gerne den Code geben, aber er ist mir verloren gegangen, als meine Festplatte den Geist aufgegeben hat.

PacMani

Mi, Jul 07, 2010 18:54
Antworten mit Zitat

Also mit sowas habe ich mich verdammt lange rumgeschlagen. Dann hatte ich eine Lösung gefunden, mit einem zweiten Kollisionsentity immer die Steigung zu überprüfen, bevor ich das eigentliche Entity da hin bewege. Je nach Stärke der Steigung habe ich dann das Hauptobjekt überhaupt oder garnicht bewegt.

Würde dir gerne den Code geben, aber er ist mir verloren gegangen, als meine Festplatte den Geist aufgegeben hat.

	Ana	Mi, Jul 07, 2010 20:16 Antworten mit Zitat
Nette idee wie hält sich das dann mit dem rechen aufwand?

Ana

Mi, Jul 07, 2010 20:16
Antworten mit Zitat

Nette idee wie hält sich das dann mit dem rechen aufwand?

	mpmxyz	Mi, Jul 07, 2010 20:34 Antworten mit Zitat
An sich sollte da nicht all zu viel zu berechnen sein, da Blitz3D die Flächenausrichtung an dem Kollisionspunkt automatisch berechnet. An die entsprechenden Werte kommst du mit CollisionNX, CollisionNY und CollisionNZ. Davon brauchst du nur den Wert des nach oben zeigenden Anteils. (Welcher das genau ist muss aber jetzt jemand anderes sagen.) Zur Bestimmung des Steigungswinkels setzt du diesen Wert in ACos ein. (zum Rückgabewert: 0=eine Ebene, 90=eine Klippe) mfG mpmxyz
Moin Moin! Projekte: DBPC CodeCruncher Mandelbrot-Renderer

mpmxyz

Mi, Jul 07, 2010 20:34
Antworten mit Zitat

An sich sollte da nicht all zu viel zu berechnen sein, da Blitz3D die Flächenausrichtung an dem Kollisionspunkt automatisch berechnet.
An die entsprechenden Werte kommst du mit CollisionNX

, CollisionNY

und CollisionNZ

.
Davon brauchst du nur den Wert des nach oben zeigenden Anteils. (Welcher das genau ist muss aber jetzt jemand anderes sagen.)
Zur Bestimmung des Steigungswinkels setzt du diesen Wert in ACos

ein. (zum Rückgabewert: 0=eine Ebene, 90=eine Klippe)
mfG
mpmxyz

Moin Moin!
Projekte: DBPC CodeCruncher Mandelbrot-Renderer

	PacMani	Mi, Jul 07, 2010 21:25 Antworten mit Zitat
Genau, vor allem CollisionNY wird dich interessieren. Es gab bei der Programmierung ohne zweites Testentity ein paar Anfänger-Fallen die ich gemacht habe, um die ich nicht herumkam (meist durch miese Umsetzung von Schwerkraft). Wenn du jetzt etwas eigenes startest, wird dir folgendes möglicherweise auch in die Quere kommen: 1. Wenn du mit CollisionNY überprüfst, ob das Spielerentity auf einer Ebene steht (CollisionNY > 0.7 ungefähr), setzt du die Gravity auf 0, damit das Objekt nicht nach unten rutscht. Jetzt besteht im nächsten Frame aber garkeine Kollision mehr und dein Programm geht davon aus, das der Spieler sich in der Luft befindet und erhöhst die Gravity. Dadurch verschiebst du den Spieler aber wieder auf eine Ebene - und somit leicht nach unten, weshalb dein Spieler trotz Überprüfung auf Ebene (> 0.7) rutscht. 2. Das Herunterlaufen einer Schräge (auf der man nicht rutscht) erweist sich als Huppelpartie. Dein Spieler bewegt sich nach vorne, wird von der Gravity nach unten gezogen, aber weniger als die Schräge. Somit schwebst du kurz in der Luft, setzt danach wieder auf dem Boden auf, gehst wieder einen Schritt nach vorne und bewegst dich wieder kurz in der Luft, das würde von der Seite so aussehen: Code: [AUSKLAPPEN] [EINKLAPPEN] \- \ \ \ \| \- \ \ 3. Vor dem Springen (beim Jump'n'Run) überprüfst du natürlich, ob ein Spieler auf dem Boden steht und überhaupt springen darf. Wenn du jetzt aber einen Hang heruntergehst, kannst du nicht immer springen, da der Spieler immer wieder kurze Zeit in der Luft ist.

PacMani

Mi, Jul 07, 2010 21:25
Antworten mit Zitat

Genau, vor allem CollisionNY wird dich interessieren.

Es gab bei der Programmierung ohne zweites Testentity ein paar Anfänger-Fallen die ich gemacht habe, um die ich nicht herumkam (meist durch miese Umsetzung von Schwerkraft). Wenn du jetzt etwas eigenes startest, wird dir folgendes möglicherweise auch in die Quere kommen: Smile

1. Wenn du mit CollisionNY überprüfst, ob das Spielerentity auf einer Ebene steht (CollisionNY > 0.7 ungefähr), setzt du die Gravity auf 0, damit das Objekt nicht nach unten rutscht. Jetzt besteht im nächsten Frame aber garkeine Kollision mehr und dein Programm geht davon aus, das der Spieler sich in der Luft befindet und erhöhst die Gravity. Dadurch verschiebst du den Spieler aber wieder auf eine Ebene - und somit leicht nach unten, weshalb dein Spieler trotz Überprüfung auf Ebene (> 0.7) rutscht.
2. Das Herunterlaufen einer Schräge (auf der man nicht rutscht) erweist sich als Huppelpartie. Dein Spieler bewegt sich nach vorne, wird von der Gravity nach unten gezogen, aber weniger als die Schräge. Somit schwebst du kurz in der Luft, setzt danach wieder auf dem Boden auf, gehst wieder einen Schritt nach vorne und bewegst dich wieder kurz in der Luft, das würde von der Seite so aussehen:
Code: [AUSKLAPPEN]

\-
\ \
\ |
\-
\ \

3. Vor dem Springen (beim Jump'n'Run) überprüfst du natürlich, ob ein Spieler auf dem Boden steht und überhaupt springen darf. Wenn du jetzt aber einen Hang heruntergehst, kannst du nicht immer springen, da der Spieler immer wieder kurze Zeit in der Luft ist.

	Ana	Fr, Jul 09, 2010 0:40 Antworten mit Zitat
So geht das bestimmt auch, mein gedanke wäre eher sowas wie Code: [AUSKLAPPEN] [EINKLAPPEN] moveentity test 1,0,0 positionentity test,entityx(test),terrainy t,entityx(test),0,entityz(test),entityz(test) ;Dann schauen wie das testobjekt höhenmäßig zum normalensteht Steigung = entityy(test) - entityy(normal) If abs(Steigung) <= maxSteigung then positionentity normal,entityx(test),entityy(test)entityz(test) Wie das mit den normalen aussieht versteh ich nicht ganz was mit dem kollidieren gemeint ist? eigentlich müsste doch nur der Winkel zwischen normalenvektor und xz - Ebene ausreichen an dem vorliegenden Punkt reichen oder nicht? Wie man den Punkt außer über die Kürke von moveentity bekommt ist mir allerdings nicht klar, da man ja den drehwinkel beachten muss und dann normieren damit der vekotr die länge 1 hat oder sowas?

Ana

Fr, Jul 09, 2010 0:40
Antworten mit Zitat

So geht das bestimmt auch, mein gedanke wäre eher sowas wie

Code: [AUSKLAPPEN]

moveentity test 1,0,0
positionentity test,entityx(test),terrainy t,entityx(test),0,entityz(test),entityz(test)
;Dann schauen wie das testobjekt höhenmäßig zum normalensteht
Steigung = entityy(test) - entityy(normal)
If abs(Steigung) <= maxSteigung then positionentity normal,entityx(test),entityy(test)entityz(test)

Wie das mit den normalen aussieht versteh ich nicht ganz was mit dem kollidieren gemeint ist? eigentlich müsste doch nur der Winkel zwischen normalenvektor und xz - Ebene ausreichen an dem vorliegenden Punkt reichen oder nicht?
Wie man den Punkt außer über die Kürke von moveentity bekommt ist mir allerdings nicht klar, da man ja den drehwinkel beachten muss und dann normieren damit der vekotr die länge 1 hat oder sowas?

	PacMani	Fr, Jul 09, 2010 15:42 Antworten mit Zitat
Also mit dem Code berechnest du den Höhenunterschied, beachtest aber nicht die Schräge / Steigung der Oberfläche. Da würden folgende Beispiele komplett gleich behandelt werden: Deine Variable "Steigung" ist hier gleich. Aber ich glaube nicht, dass der 3te Ball noch fähig sein soll, diese Steigung hochkraxeln zu können Du musst einfach CollisionNY benutzen. Es beißt auch nicht

PacMani

Fr, Jul 09, 2010 15:42
Antworten mit Zitat

Also mit dem Code berechnest du den Höhenunterschied, beachtest aber nicht die Schräge / Steigung der Oberfläche.
Da würden folgende Beispiele komplett gleich behandelt werden:
user posted image

Deine Variable "Steigung" ist hier gleich. Aber ich glaube nicht, dass der 3te Ball noch fähig sein soll, diese Steigung hochkraxeln zu können Wink

Du musst einfach CollisionNY benutzen. Es beißt auch nicht Wink

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

kollisionsverhalten bei Steigungen

Betreff: kollisionsverhalten bei Steigungen