Pivot als Waypoint: Ist Objekt schon vorbei?

Übersicht

BlitzBasic

Blitz3D

	barratator Betreff: Pivot als Waypoint: Ist Objekt schon vorbei?	Mi, Jan 21, 2009 15:03 Antworten mit Zitat
Hallo, ich habe ein kleines Problem: Ich habe in meiner Map Waypoints (Pivots) für eine Eisenbahn-Strecke, die Waypoints werden mit einer Schiene verbunden. Jedesmal, wenn der Zug an dem Waypoint ist wird der nächste Waypoint gesucht und die Richtung geändert. Jetzt das eigentliche Problem: Im moment überprüfe ich einfach mit EntityDistance, ob der Zug schon am Punkt ist oder nicht. D.h. Code: [AUSKLAPPEN] [EINKLAPPEN] If EntityDistance(waypoint,train) < 10 Then [...] Wenn der Zug jetzt aber z.B. zu schnell fährt (z.b. mit 30 Einheiten/Frame) dann wird der Zug nicht immer 10 Einheiten nahe sein. Wie könnte ich das Problem jetzt am besten lösen? Danke im vorraus! Gruß Bastian

barratator

Betreff: Pivot als Waypoint: Ist Objekt schon vorbei?

Mi, Jan 21, 2009 15:03
Antworten mit Zitat

Hallo,
ich habe ein kleines Problem:
Ich habe in meiner Map Waypoints (Pivots) für eine Eisenbahn-Strecke, die Waypoints werden mit einer Schiene verbunden. Jedesmal, wenn der Zug an dem Waypoint ist wird der nächste Waypoint gesucht und die Richtung geändert.
Jetzt das eigentliche Problem:
Im moment überprüfe ich einfach mit EntityDistance, ob der Zug schon am Punkt ist oder nicht. D.h.
Code: [AUSKLAPPEN]

If EntityDistance(waypoint,train) < 10 Then [...]

Wenn der Zug jetzt aber z.B. zu schnell fährt (z.b. mit 30 Einheiten/Frame) dann wird der Zug nicht immer 10 Einheiten nahe sein.
Wie könnte ich das Problem jetzt am besten lösen?

Danke im vorraus! Smile

Gruß
Bastian

	FreetimeCoder	Mi, Jan 21, 2009 15:39 Antworten mit Zitat
Du könntest statt den Zug um 30 Einheiten auf einmal zu bewegen, den Zug in einer For Next Schleife 3 mal um 10 Einheiten bewegen und dann immer abfragen. Die Schleifendurchläufe machste dann abhängig von der Geschwindigkeit. MfG
"Wir haben keine Chance, aber wir werden sie nutzen!" Projekte: Dexterity Ball (100%) Aquatic Atmosfear (22 % ca 4700 Zeilen) eingefrohren mangels OOP Fähigkeiten von Blitz (ehemals Uboot) PC: Intel D 3 GHz \| NVidiaGforce 6700 256 Mb \| 1024 Mb DDR RAM 400 Mhz \| 2x160 GB S-ATA

FreetimeCoder

Mi, Jan 21, 2009 15:39
Antworten mit Zitat

Du könntest statt den Zug um 30 Einheiten auf einmal zu bewegen, den Zug in einer For Next Schleife 3 mal um 10 Einheiten bewegen und dann immer abfragen.

Die Schleifendurchläufe machste dann abhängig von der Geschwindigkeit.

MfG

"Wir haben keine Chance, aber wir werden sie nutzen!"
Projekte:
Dexterity Ball (100%)
Aquatic Atmosfear (22 % ca 4700 Zeilen) eingefrohren mangels OOP Fähigkeiten von Blitz
(ehemals Uboot)
PC: Intel D 3 GHz | NVidiaGforce 6700 256 Mb | 1024 Mb DDR RAM 400 Mhz | 2x160 GB S-ATA

	The_Nici	Mi, Jan 21, 2009 15:42 Antworten mit Zitat
Hallo, man könnte das ganze auch mit Kollision prüfen. Du machst einfach eine genug Grosse EntityBox um den Waypoint, und wenn er damit kollidiert, schaltet sich die Box selbst weg und der Zug wechselt zum nächsten Waypoint.

The_Nici

Mi, Jan 21, 2009 15:42
Antworten mit Zitat

Hallo,
man könnte das ganze auch mit Kollision prüfen. Du machst einfach eine genug Grosse EntityBox um den Waypoint, und wenn er damit kollidiert, schaltet sich die Box selbst weg und der Zug wechselt zum nächsten Waypoint.

	barratator	Mi, Jan 21, 2009 15:49 Antworten mit Zitat
@FreetimeCoder: Joa, das wär vielleicht ganz gut... @The_Nici: An kollisionen habe ich auch schon gedacht...Aber dann bleibt der Zug doch kurz stehen, oder?

barratator

Mi, Jan 21, 2009 15:49
Antworten mit Zitat

@FreetimeCoder: Joa, das wär vielleicht ganz gut...

@The_Nici: An kollisionen habe ich auch schon gedacht...Aber dann bleibt der Zug doch kurz stehen, oder?

	The_Nici	Mi, Jan 21, 2009 16:00 Antworten mit Zitat
Sollte eigentlich nicht, nein, denn man kann ja im gleichen Frame noch EntityType auf 0 setzen.

The_Nici

Mi, Jan 21, 2009 16:00
Antworten mit Zitat

Sollte eigentlich nicht, nein, denn man kann ja im gleichen Frame noch EntityType auf 0 setzen.

	peacemaker	Mi, Jan 21, 2009 17:15 Antworten mit Zitat
Nein, lass das mit den Kollisionen. Du müsstest einfach anstatt EntityDistance(waypoint,train) < 10, den Wert 10 variabel, und Zuggeschwindigkeitsabhängig machen. Z.B. immer 5 mal grössere Distanz, als die Zuggeschwindigkeit, oder so. Musst du ausprobieren. mfG
~Tehadon~ www.tehadon.de http://www.blitzforum.de/worklogs/14/

peacemaker

Mi, Jan 21, 2009 17:15
Antworten mit Zitat

Nein, lass das mit den Kollisionen.

Du müsstest einfach anstatt EntityDistance(waypoint,train) < 10, den Wert 10 variabel, und Zuggeschwindigkeitsabhängig machen.
Z.B. immer 5 mal grössere Distanz, als die Zuggeschwindigkeit, oder so. Musst du ausprobieren.

mfG

~Tehadon~
www.tehadon.de
http://www.blitzforum.de/worklogs/14/

	FreetimeCoder	Mi, Jan 21, 2009 17:20 Antworten mit Zitat
Je nach Geschwindigkeit des UserPc könnte der Zug trotzdem stocken, da ja die Kollision das Objekt ersteinmal anhalten muss bevor man abfragen kann ob eine Kollision besteht. Je schneller die Framerate desto weniger fällt das ruckeln auf, je langsamer die Bilder berechnet werden desto mehr sieht man allerdings das Stoppen des Zuges. MfG
"Wir haben keine Chance, aber wir werden sie nutzen!" Projekte: Dexterity Ball (100%) Aquatic Atmosfear (22 % ca 4700 Zeilen) eingefrohren mangels OOP Fähigkeiten von Blitz (ehemals Uboot) PC: Intel D 3 GHz \| NVidiaGforce 6700 256 Mb \| 1024 Mb DDR RAM 400 Mhz \| 2x160 GB S-ATA

FreetimeCoder

Mi, Jan 21, 2009 17:20
Antworten mit Zitat

Je nach Geschwindigkeit des UserPc könnte der Zug trotzdem stocken, da ja die Kollision das Objekt ersteinmal anhalten muss bevor man abfragen kann ob eine Kollision besteht. Je schneller die Framerate desto weniger fällt das ruckeln auf, je langsamer die Bilder berechnet werden desto mehr sieht man allerdings das Stoppen des Zuges.

MfG

	Noobody	Mi, Jan 21, 2009 18:41 Antworten mit Zitat
Man könnte es auch mit einem simplen TFormPoint lösen. Ich gehe mal davon aus, dass bei deinem Zug die Z - Achse nach vorne zeigt. Per TFormPoint mit den Koordinaten des Wegpunktes transformierst du die Koordinaten des Wegpunktes in den Raum des Zuges. Ist seine neue Z - Koordinate kleiner als 0, so liegt er hinter dem Zug - was heissen muss, dass der Zug den Punkt bereits passiert hat. Das ist völlig unabhängig von der Geschwindigkeit und funktioniert in den meisten Fällen (ist sogar noch relativ performanceschonend ) - würde ich nur empfehlen.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Mi, Jan 21, 2009 18:41
Antworten mit Zitat

Man könnte es auch mit einem simplen TFormPoint lösen.
Ich gehe mal davon aus, dass bei deinem Zug die Z - Achse nach vorne zeigt.
Per TFormPoint mit den Koordinaten des Wegpunktes transformierst du die Koordinaten des Wegpunktes in den Raum des Zuges.
Ist seine neue Z - Koordinate kleiner als 0, so liegt er hinter dem Zug - was heissen muss, dass der Zug den Punkt bereits passiert hat.
Das ist völlig unabhängig von der Geschwindigkeit und funktioniert in den meisten Fällen (ist sogar noch relativ performanceschonend Razz

) - würde ich nur empfehlen.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	FreetimeCoder	Mi, Jan 21, 2009 22:58 Antworten mit Zitat
Wobei es natürlich darauf ankommt wie genau die Abfrage sein muss. Also wenn wir folgende 2 Frames haben: ZUG>..................O.................. ...........................O.................. ZUG> ( O = Wegpunkt) Dann wird der Zug eventuell nach der Schiene eine sehr unschöne Kurve machen. Löst man das ganze in Schritten, kann man zum richtigen Zeitpunkt den Kurs korrigieren. Gegen TForm spricht natürlich nichts, vllt ja eine kombinierte Methode MfG
"Wir haben keine Chance, aber wir werden sie nutzen!" Projekte: Dexterity Ball (100%) Aquatic Atmosfear (22 % ca 4700 Zeilen) eingefrohren mangels OOP Fähigkeiten von Blitz (ehemals Uboot) PC: Intel D 3 GHz \| NVidiaGforce 6700 256 Mb \| 1024 Mb DDR RAM 400 Mhz \| 2x160 GB S-ATA

FreetimeCoder

Mi, Jan 21, 2009 22:58
Antworten mit Zitat

Wobei es natürlich darauf ankommt wie genau die Abfrage sein muss.
Also wenn wir folgende 2 Frames haben:

ZUG>..................O..................
...........................O.................. ZUG>

( O = Wegpunkt)

Dann wird der Zug eventuell nach der Schiene eine sehr unschöne Kurve machen.
Löst man das ganze in Schritten, kann man zum richtigen Zeitpunkt den Kurs korrigieren. Gegen TForm spricht natürlich nichts, vllt ja eine kombinierte Methode Wink

MfG

	D2006 Administrator	Do, Jan 22, 2009 10:56 Antworten mit Zitat
Aaaaalso ich hab sowas schonmal versucht in 2D zu machen. Kollisionen würde ich lassen, unsinnig. Sich schrittweise zu nähern und immer den Kurs zu korrigieren klingt, als müsste das ja funktionierten. Wird es aber nicht. Ich hab das in 2D mit ATan2 probiert. Im großen und ganzen klappt das zwar schon, aber es treten einige unschöne Nebeneffekte auf. Ich hab mir ein neues System überlegt, kam aber nicht richtig dazu, es zu testen. Dennoch oder gerade deswegen will ich es vorschlagen: Du baust deine Strecke mit Vektoren auf. Das ist bei deiner Ausgangslage nicht mal schwer, denn die Vektoren gehen halt von Wegpunkt zu Wegpunkt. Für jeden Streckenabschnitt, also Vektor, muss die Länge errechnet werden (ist ja billig). Die Position des Zuges bestimmt sich nun durch den Verweis auf einen Wegpunkt und einer Floatzahl, welche quasi den Abstand vom Wegpunkt entlang des Vektors zum nächsten Wegpunkt darstellt. Wenn diese Floatzahl größer ist als die Länge des Vektors, rutscht der Zug einen Wegpunkt weiter und von der Floatzahl wird die Länge des eben passierten Vektors abgezogen. Vorteil: Der Zug ist immer(!) auf der Strecke und dank der Abhängigkeit der Floatzahl von der Länge des Vektors, bewegt sich der Zug auf jedem Abschnitt immer gleich schnell, wenn man besagte Floatzahl konstant erhöht. Nachteil: Man muss ein wenig mit den Richtungen aufpassen, dass der Vektor immer in die korrekte Richtung zeigt und wenn doch mal nicht, dass dann halt mit Subtraktion statt Addition gearbeitet wird. Nett wie ich bin, verlange ich keine Credits für diese geniale Idee
Intel Core i5 2500 \| 16 GB DDR3 RAM dualchannel \| ATI Radeon HD6870 (1024 MB RAM) \| Windows 7 Home Premium Intel Core 2 Duo 2.4 GHz \| 2 GB DDR3 RAM dualchannel \| Nvidia GeForce 9400M (256 MB shared RAM) \| Mac OS X Snow Leopard Intel Pentium Dual-Core 2.4 GHz \| 3 GB DDR2 RAM dualchannel \| ATI Radeon HD3850 (1024 MB RAM) \| Windows 7 Home Premium Chaos Interactive :: GoBang :: BB-Poker :: ChaosBreaker :: Hexagon :: ChaosRacer 2

D2006

Administrator

Do, Jan 22, 2009 10:56
Antworten mit Zitat

Aaaaalso ich hab sowas schonmal versucht in 2D zu machen.

Kollisionen würde ich lassen, unsinnig. Sich schrittweise zu nähern und immer den Kurs zu korrigieren klingt, als müsste das ja funktionierten. Wird es aber nicht. Ich hab das in 2D mit ATan2 probiert. Im großen und ganzen klappt das zwar schon, aber es treten einige unschöne Nebeneffekte auf.

Ich hab mir ein neues System überlegt, kam aber nicht richtig dazu, es zu testen. Dennoch oder gerade deswegen will ich es vorschlagen:
Du baust deine Strecke mit Vektoren auf. Das ist bei deiner Ausgangslage nicht mal schwer, denn die Vektoren gehen halt von Wegpunkt zu Wegpunkt. Für jeden Streckenabschnitt, also Vektor, muss die Länge errechnet werden (ist ja billig). Die Position des Zuges bestimmt sich nun durch den Verweis auf einen Wegpunkt und einer Floatzahl, welche quasi den Abstand vom Wegpunkt entlang des Vektors zum nächsten Wegpunkt darstellt. Wenn diese Floatzahl größer ist als die Länge des Vektors, rutscht der Zug einen Wegpunkt weiter und von der Floatzahl wird die Länge des eben passierten Vektors abgezogen. Vorteil: Der Zug ist immer(!) auf der Strecke und dank der Abhängigkeit der Floatzahl von der Länge des Vektors, bewegt sich der Zug auf jedem Abschnitt immer gleich schnell, wenn man besagte Floatzahl konstant erhöht. Nachteil: Man muss ein wenig mit den Richtungen aufpassen, dass der Vektor immer in die korrekte Richtung zeigt und wenn doch mal nicht, dass dann halt mit Subtraktion statt Addition gearbeitet wird.

Nett wie ich bin, verlange ich keine Credits für diese geniale Idee Wink

	Noobody	Do, Jan 22, 2009 13:59 Antworten mit Zitat
hust An sich läuft das auf dasselbe raus wie meine Idee, nur komplizierter Zu schauen, ob man den Vektor auf der vollen Länge abgefahren hat, kommt nämlich auf das selbe raus, wie wenn man schaut, ob der nächste Wegpunkt hinter einem liegt. Selbstverständlich verlange ich auch keine Credits
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Do, Jan 22, 2009 13:59
Antworten mit Zitat

*hust* An sich läuft das auf dasselbe raus wie meine Idee, nur komplizierter Wink

Zu schauen, ob man den Vektor auf der vollen Länge abgefahren hat, kommt nämlich auf das selbe raus, wie wenn man schaut, ob der nächste Wegpunkt hinter einem liegt.

Selbstverständlich verlange ich auch keine Credits Wink

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	barratator	Fr, Jan 23, 2009 16:59 Antworten mit Zitat
Danke für die vielen Antworten Die Methode von D'06 klingt ganz gut, dass werde ich mal versuchen. Bisher ging das ganze nämlich nur bis ca. 20m/s gut Gruß Bastian

barratator

Fr, Jan 23, 2009 16:59
Antworten mit Zitat

Danke für die vielen Antworten Smile

Die Methode von D'06 klingt ganz gut, dass werde ich mal versuchen.
Bisher ging das ganze nämlich nur bis ca. 20m/s gut Smile

Gruß
Bastian

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

Pivot als Waypoint: Ist Objekt schon vorbei?

Betreff: Pivot als Waypoint: Ist Objekt schon vorbei?