flippern in 3d

Übersicht

BlitzBasic

Blitz3D

	GERMAX Betreff: flippern in 3d	Sa, März 27, 2010 3:59 Antworten mit Zitat
Hallo erstmal! Ich wusste gar nicht, ob Sie es schon wussten... (somit begrüsse ich mich im Forum gleichmal selber). Jetzt Schluß mit lustig und Butter an den Fischkopf!!! Gegeben sei ein Flippertisch, der aus verschiedenen Modellbauteilen besteht (genauer handelt es sich um den Bally Mystic). Und dann kommt was kommen muß! Worin liegt eigentlich genau die Schwierigkeit an einem Flipper? Genau! Die Kugel muß rollen. Rollen tut sie auch so lala. Aber jetzt wird es tatsächlich interessant: Wenn die Kugel in Richtung auf den/die Schläger rollt bewegt der Spieler bekanntlich den Flipperfinger, der um eine konkrete Achse herum vom unteren Totpunkt bis zum oberen rotiert (oder umgekehrt). In meinem Fall sind das 60 Grad (und zwar 512 Grad, weil das Teil genau auf 60FPS eingestellt ist). Dabei darf die Kugel natürlich nicht durch den Schläger gehen (was in meinem Fall vllt schon zu 99% funktioniert). Das wirkliche Problem sind die vielen verschiedenen Winkel an dem Flipperfinger selber, denn der hat am Ende einen vollen Halbkreis und mindestens 2 längere Gerade (nämlich unten und oben). Durch die zusätzliche Bewegung desselben ändern sich diese Winkel auch noch ständig (also zumindest 5). Wie prüft man die Kollisionen und die Winkel bzw auch die Geschwindigkeit am Kollisionspunkt, sodaß das Ganze möglichst glaubwürdig rüberkommt? wer nicht weiß, was MYSTIC sein soll: http://www.ipdb.org/machine.cgi?gid=1650 Der Flipperfinger selber hat natürlich eine eigene Kollsioinsnummer, aber das reicht natürlich überhaupt nicht! Bild von dem Teil werde ich bald in die Galerie reinstellen, denn gfx-mässig ist das Ding so gut wie fertig. (wenigstens etwas) THX
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Betreff: flippern in 3d

Sa, März 27, 2010 3:59
Antworten mit Zitat

Hallo erstmal! Ich wusste gar nicht, ob Sie es schon wussten... (somit begrüsse ich mich im Forum gleichmal selber).

Jetzt Schluß mit lustig und Butter an den Fischkopf!!!

Gegeben sei ein Flippertisch, der aus verschiedenen Modellbauteilen besteht (genauer handelt es sich um den Bally Mystic). Und dann kommt was kommen muß!
Worin liegt eigentlich genau die Schwierigkeit an einem Flipper? Genau! Die Kugel muß rollen. Rollen tut sie auch so lala. Aber jetzt wird es tatsächlich interessant:

Wenn die Kugel in Richtung auf den/die Schläger rollt bewegt der Spieler bekanntlich den Flipperfinger, der um eine konkrete Achse herum vom unteren Totpunkt bis zum oberen rotiert (oder umgekehrt). In meinem Fall sind das 60 Grad (und zwar 5*12 Grad, weil das Teil genau auf 60FPS eingestellt ist). Dabei darf die Kugel natürlich nicht durch den Schläger gehen (was in meinem Fall vllt schon zu 99% funktioniert). Das wirkliche Problem sind die vielen verschiedenen Winkel an dem Flipperfinger selber, denn der hat am Ende einen vollen Halbkreis und mindestens 2 längere Gerade (nämlich unten und oben). Durch die zusätzliche Bewegung desselben ändern sich diese Winkel auch noch ständig (also zumindest 5*). Wie prüft man die Kollisionen und die Winkel bzw auch die Geschwindigkeit am Kollisionspunkt, sodaß das Ganze möglichst glaubwürdig rüberkommt?

wer nicht weiß, was MYSTIC sein soll:
http://www.ipdb.org/machine.cgi?gid=1650

Der Flipperfinger selber hat natürlich eine eigene Kollsioinsnummer, aber das reicht natürlich überhaupt nicht!
Bild von dem Teil werde ich bald in die Galerie reinstellen, denn gfx-mässig ist das Ding so gut wie fertig.
(wenigstens etwas)

THX Cool

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	Midimaster	Mo, März 29, 2010 9:18 Antworten mit Zitat
Das geht sicherlich eleganter zu lösen, als ich hier gleich schreibe, aber eine unprofessionelle Antwort ist immer noch besser als gar keine: Ich würde 4 Fälle unterscheiden: 1.A Kugel kommt von oben und von links 1.B Kugel kommt von oben und von rechts 2.A Kugel kommt von unten und von links 2.B Kugel kommt von unten und von rechts Ich lege 0° so fest, das es genau nach oben zeigt. 90° zeigt nach rechts, 180° nach unten... Die Kugel Die Kugel kann z.b wenn sie von oben kommt jede Flugbahn (KugelW) von 90° (fliegt nach rechts) über 180° (kommt direkt von oben) bis 270° (fliegt nach links) einnehmen. Der Finger Der (z.B. linke) Finger hat einen Bewegungs-Bereich (Winkel FingerW), sagen wir zwischen 40° und 150° Die Mittelsenkrechte auf diesen Winkel läuft dann von 130° bis 240° (90° mehr) Aufgrund dieser Mitellsenkrechten kannst du nun entscheiden, ob der Ball sich vom Schläger aus gesehen "von links" oder "von rechts" nähert: Beträgt die Flugbahn weniger als die akt. Mittelsenkrechte, dann kommt der Ball von links, sonst von rechts. Bemerkung: Es kann gut sein, dass die Berechung der Mittelsenkrechte gar nicht nötig sein wird. Teste einfach mal alle Kombinationen von Winkeln durch. Und wenn da irgendwann Quatsch rauskommt, liegt es wahrscheinlich an einem "von links/von rechts"-Problem. Dabei könnte dann dieses Feature helfen. Für den Fall "von oben" gilt nun: NeuerWinkel = 2x FingerW - KugelW Beispiel Finger hat die Stellung 120°, Kugel kommt von oben links mit 160° 2x120-160=80 Kugel fliegt also in Richtung 80° von Finger wieder weg Das "von unten" müsste man ebenso ableiten können.

Midimaster

Mo, März 29, 2010 9:18
Antworten mit Zitat

Das geht sicherlich eleganter zu lösen, als ich hier gleich schreibe, aber eine unprofessionelle Antwort ist immer noch besser als gar keine:

Ich würde 4 Fälle unterscheiden:

1.A Kugel kommt von oben und von links
1.B Kugel kommt von oben und von rechts

2.A Kugel kommt von unten und von links
2.B Kugel kommt von unten und von rechts

Ich lege 0° so fest, das es genau nach oben zeigt. 90° zeigt nach rechts, 180° nach unten...

Die Kugel
Die Kugel kann z.b wenn sie von oben kommt jede Flugbahn (KugelW) von 90° (fliegt nach rechts) über 180° (kommt direkt von oben) bis 270° (fliegt nach links) einnehmen.

Der Finger

Der (z.B. linke) Finger hat einen Bewegungs-Bereich (Winkel FingerW), sagen wir zwischen 40° und 150°
Die Mittelsenkrechte auf diesen Winkel läuft dann von 130° bis 240° (90° mehr)

Aufgrund dieser Mitellsenkrechten kannst du nun entscheiden, ob der Ball sich vom Schläger aus gesehen "von links" oder "von rechts" nähert: Beträgt die Flugbahn weniger als die akt. Mittelsenkrechte, dann kommt der Ball von links, sonst von rechts.

Bemerkung:
Es kann gut sein, dass die Berechung der Mittelsenkrechte gar nicht nötig sein wird. Teste einfach mal alle Kombinationen von Winkeln durch. Und wenn da irgendwann Quatsch rauskommt, liegt es wahrscheinlich an einem "von links/von rechts"-Problem. Dabei könnte dann dieses Feature helfen.

user posted image

Für den Fall "von oben" gilt nun:

NeuerWinkel = 2x FingerW - KugelW

Beispiel

Finger hat die Stellung 120°, Kugel kommt von oben links mit 160°

2x120-160=80

Kugel fliegt also in Richtung 80° von Finger wieder weg

Das "von unten" müsste man ebenso ableiten können.

	Mr.Keks	Mo, März 29, 2010 11:53 Antworten mit Zitat
Eine Abprall-Kollision kann man unabhängig von Winkeln auch so verstehen, dass der Vektor, mit dem sich dein Objekt auf die Oberfläche zu bewegt hat, an der Oberfläche gespiegelt wird. (Man nennt das ja auch Reflexion...) Dazu benötigst du dann wirklich nur die Richtung der Oberfläche, also die Normale, ermittelbar mit CollisionNXYZ(), und die Ballbewegungsrichtung als Vektor. Das kannst du entweder mit TFormPoint oder aber auch gleich mit folgender Formel umsetzen, Code: [AUSKLAPPEN] [EINKLAPPEN] ballrichtung = alteballrichtung - 2 (oberflächennormale * alteballrichtung) * oberflächennormale Achtung, alle "Variablen" in dieser Formel sind normierte Vektoren und das erste * steht fürs Skalarprodukt! Ich weiß nicht, wie viel Plan du von Vektorzeugs hast. Sollten dir all dies Worte nicht sagen, liefere ich auf Anfrage auch gerne nach, was das in Code bedeutet. Ein weiteres spaßiges Problem bei einem Flipper ist, wie du schon erwähntest, dass die Kugel natürlich nicht durch den Flipperfinger gehen darf und sie ja auch nicht nur reflektiert, sondern vor allen Dingen auch beschleunigt wird von dem Teil. Es empfiehlt sich unter Umständen, gerade bei einem Flipper, die Kollisionen mit mehreren Zwischenschritten zu berechnen, also mehr Kollisionszwischenschritte zu machen, als tatsächlich Frames gerendert werden. Für das zweite Problem musst du wohl rumprobieren, ob du einfach immer etwas Beschleunigung in Flipper-Richtung hinzuaddierst, wenn die Finger gerade nach vorne schnellen oder du die Kugel für die Zeit des Nachvorneschnellens einfach sozusagen an den Finger pinnst und dann am Ende der Bewegung davonfliegen lässt etc.
MrKeks.net

Mr.Keks

Mo, März 29, 2010 11:53
Antworten mit Zitat

Eine Abprall-Kollision kann man unabhängig von Winkeln auch so verstehen, dass der Vektor, mit dem sich dein Objekt auf die Oberfläche zu bewegt hat, an der Oberfläche gespiegelt wird. (Man nennt das ja auch Reflexion...) Dazu benötigst du dann wirklich nur die Richtung der Oberfläche, also die Normale, ermittelbar mit CollisionNX

YZ(), und die Ballbewegungsrichtung als Vektor.

Das kannst du entweder mit TFormPoint

oder aber auch gleich mit folgender Formel umsetzen, Code: [AUSKLAPPEN]

ballrichtung = alteballrichtung - 2 (oberflächennormale * alteballrichtung) * oberflächennormale

Achtung, alle "Variablen" in dieser Formel sind normierte Vektoren und das erste * steht fürs Skalarprodukt! Ich weiß nicht, wie viel Plan du von Vektorzeugs hast. Sollten dir all dies Worte nicht sagen, liefere ich auf Anfrage auch gerne nach, was das in Code bedeutet.

Ein weiteres spaßiges Problem bei einem Flipper ist, wie du schon erwähntest, dass die Kugel natürlich nicht durch den Flipperfinger gehen darf und sie ja auch nicht nur reflektiert, sondern vor allen Dingen auch beschleunigt wird von dem Teil. Es empfiehlt sich unter Umständen, gerade bei einem Flipper, die Kollisionen mit mehreren Zwischenschritten zu berechnen, also mehr Kollisionszwischenschritte zu machen, als tatsächlich Frames gerendert werden. Für das zweite Problem musst du wohl rumprobieren, ob du einfach immer etwas Beschleunigung in Flipper-Richtung hinzuaddierst, wenn die Finger gerade nach vorne schnellen oder du die Kugel für die Zeit des Nachvorneschnellens einfach sozusagen an den Finger pinnst und dann am Ende der Bewegung davonfliegen lässt etc.

MrKeks.net

	GERMAX	Di, März 30, 2010 4:04 Antworten mit Zitat
Danke für beide Antworten. Da die Kugel schon auf dem Spielfeld rollt, habe ich natürlich auch schon Abprallwinkel ausgerechnet (wobei die Finger allerdings das grösste Prob darstellen). Dürfte so ziemlich so aussehen, wie ihr das meint. Jedenfalls habe ich das in einer einfachen Simulation probiert bzw durch ein simples Programm an einigen Beispielen durchgerechnet. hwinkel=normale/theta=Bewegungswinkel der Kugel/ xspeed1 ist bewegung der kugel in x-richtung (und die kann natürlich auch negativ sein) zspeed1 " z-richtung delta ist die diff zwischen Kugelw und Hindernisw (wichtig für die Rückstoss, weil Teil der Energie durch Hindernis gefressen wird(materialabhängig/bzw aktiv/passives Element) ------------------------------------------------------ Function neuwinkel2 (hwinkel#,material#) theta=theta+180 delta#=(theta-hwinkel);Mod 360 theta=hwinkel-delta If theta < 0 Then theta = theta + 360 xspeed1#=Cos (theta) zspeed1#=Sin (theta) delta=Abs(theta-hwinkel) zuck#=Abs(bspeed1) . . End Function ---------------------------------------------------- Die Mittelsenkrechte/normale (bei mir heisst das Teil einfach Hinderniswinkel) wie midimaster meint, muß man übrigens gar nicht ausrechnen, weil es nur ein paar Stellungen gibt - also kann man sie als Konstanten betrachten (abhängig von der momentanen Stellung des Fingers). (fliprry= Stellung des rechten Flipperfingers) .flirechts Select fliprry Case -60:RotateEntity flipr,2,-60,-6:p=-0.4860EntityX(ball1)+49.6878:f=-0.6824EntityX(ball1)+88.9118 Case -48:RotateEntity flipr,2,-48,-6:p=-0.2478EntityX(ball1)-4.5565:f=-0.4103EntityX(ball1)+27.4659 Case -36:RotateEntity flipr,2,-36,-6:p=-0.0035EntityX(ball1)-59.7438:f=-0.1819EntityX(ball1)-24.2215 Case -24:RotateEntity flipr,2,-24,-4:p=0.1777EntityX(ball1)-101.1299:f=0.0295EntityX(sph)- 72.1375 Case -12:RotateEntity flipr,2,-12,-2:p=0.4056EntityX(ball1)-152.6827:f=0.2435EntityX(ball1)-120.7583 Case 0:RotateEntity flipr,0,0,0:p=0.6768EntityX(ball1)-213.9848:f=0.4811EntityX(ball1)-174.9354 End Select If EntityZ(ball1)-2<p And EntityZ(ball1)-2>f And EntityX(ball1)>216 And EntityX(ball1)<228 Then EntityColor (ball1),255,0,0:zspeed1=5;:xspeed1=xspeed1-1;neuwinkel2 (fliprry+120,5) Else EntityColor (ball1),0,255,0 End If Return ... durch den Flipperfinger durch: Momentan habe ich das so ansatzweise: 1. Wenn man die Oberseite des Flipperfingers als Gerade versteht, kann man eine Geradengleichung aufstellen. 2. Die alte und die neue Position der Kugel werden ebenfalls in eine Gerade umgewandelt. 3. Beide G gleichsetzen. Dabei sollte ein Schnittpunkt rauskommen (keiner wäre extrem unwahrscheinlich) 4. kontroll., ob dieser Punkt innerhalb der linken und rechten Grenze der Strecke liegt 5. da die Kugel jetzt im Finger stecken würde, muß man nun die Streckenlänge zwischen der neuen Kugelposition und diesem Kollisionpunkt berechnen und von der neuen Position zur ganz neuen abziehen. Somit klebte dann die Kugel genau auf dem Schläger. Hoffentlich. Und das muß man dann mehrmals machen usw (wegen der Rundung vorne und unten). Die Bewegung der Kugel sieht bei mir so aus: (also tformpoint isses jedenfalls nicht) If move=1 Then zspeed1=zspeed1-grav:TranslateEntity ball1,xspeed1,-1,zspeed1 bspeed1#=Sqr(xspeed1#xspeed1#+zspeed1#*zspeed1#) theta#=ACos(xspeed1/bspeed1) If zspeed1<0 Then theta=360-theta grav ist einfach eine Zahl, die eben auf 60fps und den Neigungswinkel des Tisches eingestellt ist. CollisionsNx werde ich auf jeden Fall mal ausprobieren, denn ich habe die K. mit den Aufbauten ganz anders gelöst. Allerdings habe ich mit dieser Art der Abfrage überhaupt keine Erfahrung, weil ich die Kollsionen immer einzeln Abfrage, und nicht aus einer Liste heraus: If EntityCollided (ball1,66) Then If EntityCollided (ball1,64) Then If EntityCollided (ball1,200) Then usw Ob das so doll ist, weiß ich nicht, aber die Abfrage ist eben direkter. Jedenfalls sehe ich da noch einiges an Arbeit auf mich zukommen. Vielleicht muß ich einen Großteil des Codes nochmal umschmeissen. Dafür, daß ich jetzt schon ca 1.5 Jahre dran arbeite... Allerdings mit Riesenpausen dazwischen
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Di, März 30, 2010 4:04
Antworten mit Zitat

Danke für beide Antworten.

Da die Kugel schon auf dem Spielfeld rollt, habe ich natürlich auch schon Abprallwinkel ausgerechnet (wobei die Finger allerdings das grösste Prob darstellen). Dürfte so ziemlich so aussehen, wie ihr das meint. Jedenfalls habe ich das in einer einfachen Simulation probiert bzw durch ein simples Programm an einigen Beispielen durchgerechnet.

hwinkel=normale/theta=Bewegungswinkel der Kugel/
xspeed1 ist bewegung der kugel in x-richtung (und die kann natürlich auch negativ sein)
zspeed1 " z-richtung
delta ist die diff zwischen Kugelw und Hindernisw (wichtig für die Rückstoss, weil Teil der Energie durch Hindernis gefressen wird(materialabhängig/bzw aktiv/passives Element)
------------------------------------------------------
Function neuwinkel2 (hwinkel#,material#)
theta=theta+180
delta#=(theta-hwinkel);Mod 360
theta=hwinkel-delta
If theta < 0 Then theta = theta + 360
xspeed1#=Cos (theta)
zspeed1#=Sin (theta)
delta=Abs(theta-hwinkel)
zuck#=Abs(bspeed1)
.
.
End Function
----------------------------------------------------
Die Mittelsenkrechte/normale (bei mir heisst das Teil einfach Hinderniswinkel) wie midimaster meint, muß man übrigens gar nicht ausrechnen, weil es nur ein paar Stellungen gibt - also kann man sie als Konstanten betrachten (abhängig von der momentanen Stellung des Fingers).

(fliprry= Stellung des rechten Flipperfingers)
.flirechts
Select fliprry
Case -60:RotateEntity flipr,2,-60,-6:p=-0.4860*EntityX(ball1)+49.6878:f=-0.6824*EntityX(ball1)+88.9118
Case -48:RotateEntity flipr,2,-48,-6:p=-0.2478*EntityX(ball1)-4.5565:f=-0.4103*EntityX(ball1)+27.4659
Case -36:RotateEntity flipr,2,-36,-6:p=-0.0035*EntityX(ball1)-59.7438:f=-0.1819*EntityX(ball1)-24.2215
Case -24:RotateEntity flipr,2,-24,-4:p=0.1777*EntityX(ball1)-101.1299:f=0.0295*EntityX(sph)- 72.1375
Case -12:RotateEntity flipr,2,-12,-2:p=0.4056*EntityX(ball1)-152.6827:f=0.2435*EntityX(ball1)-120.7583
Case 0:RotateEntity flipr,0,0,0:p=0.6768*EntityX(ball1)-213.9848:f=0.4811*EntityX(ball1)-174.9354
End Select
If EntityZ(ball1)-2<p And EntityZ(ball1)-2>f And EntityX(ball1)>216 And EntityX(ball1)<228 Then
EntityColor (ball1),255,0,0:zspeed1=5;:xspeed1=xspeed1*-1;neuwinkel2 (fliprry+120,5)
Else
EntityColor (ball1),0,255,0
End If
Return

... durch den Flipperfinger durch:
Momentan habe ich das so ansatzweise:
1. Wenn man die Oberseite des Flipperfingers als Gerade versteht, kann man eine Geradengleichung aufstellen.
2. Die alte und die neue Position der Kugel werden ebenfalls in eine Gerade umgewandelt.
3. Beide G gleichsetzen. Dabei sollte ein Schnittpunkt rauskommen (keiner wäre extrem unwahrscheinlich)
4. kontroll., ob dieser Punkt innerhalb der linken und rechten Grenze der Strecke liegt
5. da die Kugel jetzt im Finger stecken würde, muß man nun die Streckenlänge zwischen der neuen Kugelposition und diesem Kollisionpunkt berechnen und von der neuen Position zur ganz neuen abziehen. Somit klebte dann die Kugel genau auf dem Schläger. Hoffentlich.

Und das muß man dann mehrmals machen usw (wegen der Rundung vorne und unten).

Die Bewegung der Kugel sieht bei mir so aus: (also tformpoint isses jedenfalls nicht)

If move=1 Then zspeed1=zspeed1-grav:TranslateEntity ball1,xspeed1,-1,zspeed1
bspeed1#=Sqr(xspeed1#*xspeed1#+zspeed1#*zspeed1#)
theta#=ACos(xspeed1/bspeed1)
If zspeed1<0 Then theta=360-theta

grav ist einfach eine Zahl, die eben auf 60fps und den Neigungswinkel des Tisches eingestellt ist.

CollisionsNx werde ich auf jeden Fall mal ausprobieren, denn ich habe die K. mit den Aufbauten ganz anders gelöst. Allerdings habe ich mit dieser Art der Abfrage überhaupt keine Erfahrung, weil ich die Kollsionen immer einzeln Abfrage, und nicht aus einer Liste heraus:

If EntityCollided (ball1,66) Then
If EntityCollided (ball1,64) Then
If EntityCollided (ball1,200) Then
usw

Ob das so doll ist, weiß ich nicht, aber die Abfrage ist eben direkter.

Jedenfalls sehe ich da noch einiges an Arbeit auf mich zukommen. Vielleicht muß ich einen Großteil des Codes nochmal umschmeissen. Dafür, daß ich jetzt schon ca 1.5 Jahre dran arbeite...

Allerdings mit Riesenpausen dazwischen Wink

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	Midimaster	Di, März 30, 2010 8:59 Antworten mit Zitat
du solltest in den posts die Code-Passagen in BB-Tags (siehe Zeile unter den Smilys) einschließen: so wird aus... (fliprry= Stellung des rechten Flipperfingers) .flirechts Select fliprry Case -60:RotateEntity tateEntity .... ...dies hier: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] (fliprry= Stellung des rechten Flipperfingers) .flirechts Select fliprry Case -60:RotateEntity tateEntity ....

Midimaster

Di, März 30, 2010 8:59
Antworten mit Zitat

du solltest in den posts die Code-Passagen in BB-Tags (siehe Zeile unter den Smilys) einschließen:

so wird aus...

(fliprry= Stellung des rechten Flipperfingers)
.flirechts
Select fliprry
Case -60:RotateEntity tateEntity
....

...dies hier:

BlitzBasic: [AUSKLAPPEN]

(fliprry= Stellung des rechten Flipperfingers)
.flirechts
Select fliprry
Case -60:RotateEntity tateEntity 
....

	BIG BUG	Do, Apr 01, 2010 1:14 Antworten mit Zitat
Je nachdem wie akkurat Deine Simulation sein soll, könntest Du auch in Erwägung ziehen gleich eine Physikengine einzusetzen. Ich glaube mehr oder minder tolle Wrapper gibts für ODE, Tokamak sowie Newton... Wenn Du eine Physikengine nutzt ist es halt viel Feintuning an den diversen Parametern. Habe mich aus Spass auch mal versucht(ist allerdings kein Blitz3D): http://www.mein-murks.de/software/Flipper.zip
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Do, Apr 01, 2010 1:14
Antworten mit Zitat

Je nachdem wie akkurat Deine Simulation sein soll, könntest Du auch in Erwägung ziehen gleich eine Physikengine einzusetzen.
Ich glaube mehr oder minder tolle Wrapper gibts für ODE, Tokamak sowie Newton...

Wenn Du eine Physikengine nutzt ist es halt viel Feintuning an den diversen Parametern. Habe mich aus Spass auch mal versucht(ist allerdings kein Blitz3D):
http://www.mein-murks.de/software/Flipper.zip

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	GERMAX	Do, Apr 01, 2010 3:43 Antworten mit Zitat
So übel ist das für den Anfang gar nicht. (Am Schläger besser als bei mir!) Und akkurat soll heissen <sehr gut>. Natürlich habe ich auch mit dem Gedanken einer Physik-dll beschäftigt. Die Newton kommt aus meiner Erfahrung überhaupt nicht in Frage. Die wird schon von Future-Pinball benutzt und war genau der Grund für mich, selber mal einen (und dann anschliessend noch mehr) zu proggen (soll heissen entweder grundsätzlich schlecht oder falsch benutzt). Theor. könnte man den Tisch natürlich rein 2-D machen (also minimalistische GFX und die Daten dann auf den 3D-Tisch übertragen. Es gibt immer mehrere Möglichkeiten. Apropos: Vielleicht hättest DU ja Lust, dich an dem Projekt zu beteiligen? Zeitdruck gibt es überhaupt keinen! ...und das Projekt hat Potential! Zusatz: Habe noch mit deinem Tisch rumgespielt und in den Dateien nachgeschaut. Wenn die Flipperfinger sich schneller nach oben und unten bewegen würden (in 100ms) und man eine Punktezählung dazumacht, könnte man schon fast spielen. Ansonsten ist das Ballverhalten gerade am Schläger schon sehr gut. Allerdings scheint mir der Tisch zuwenig Neigung zu haben.
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Do, Apr 01, 2010 3:43
Antworten mit Zitat

So übel ist das für den Anfang gar nicht. Laughing

(Am Schläger besser als bei mir!)

Und akkurat soll heissen <sehr gut>.

Natürlich habe ich auch mit dem Gedanken einer Physik-dll beschäftigt. Die Newton kommt aus meiner Erfahrung überhaupt nicht in Frage. Die wird schon von Future-Pinball benutzt und war genau der Grund für mich, selber mal einen (und dann anschliessend noch mehr) zu proggen (soll heissen entweder grundsätzlich schlecht oder falsch benutzt).

Theor. könnte man den Tisch natürlich rein 2-D machen (also minimalistische GFX und die Daten dann auf den 3D-Tisch übertragen.

Es gibt immer mehrere Möglichkeiten.

Apropos: Vielleicht hättest DU ja Lust, dich an dem Projekt zu beteiligen? Zeitdruck gibt es überhaupt keinen! ...und das Projekt hat Potential! Idea

Zusatz: Habe noch mit deinem Tisch rumgespielt und in den Dateien nachgeschaut. Wenn die Flipperfinger sich schneller nach oben und unten bewegen würden (in 100ms) und man eine Punktezählung dazumacht, könnte man schon fast spielen. Ansonsten ist das Ballverhalten gerade am Schläger schon sehr gut. Allerdings scheint mir der Tisch zuwenig Neigung zu haben.

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

flippern in 3d

GERMAX

Betreff: flippern in 3d

Midimaster

Mr.Keks

GERMAX

Midimaster

BIG BUG

GERMAX