PureBoard

Hallo
Wenn ein 3d Objekt das mit #PB_Entity_StaticBody deklariert wurde und ein anderes 3d Objekt das mit #PB_Entity_BoxBody oder #PB_Entity_SphereBody deklariert wurde miteinander kollidieren dann reagiert ExamineWorldCollisions() und alle für die Kollisionsabfrage zu verfügung stehenden Befehle nicht. WorldPhysics und WorldCollisions sind eingeschaltet.

...dann noch ein zweites Problem.
Ein 3d Objekt das mit #PB_Entity_BoxBody oder #PB_Entity_SphereBody deklariert wurde und den Parameter #PB_Entity_AbsoluteBodyMove besitzt veruhrsacht einen übelen Fehler. Dieses Thema habe ich aber hier im Forum schon einmal angesprochen dazu bittehier weiter lesen oder vieleicht könnte es auch jemand hier her verschieben, gehört eigentlich auch hier rein denke ich.

MfG.
Captain_hesse

bitte poste mal zwei möglichst kurze codes, die das demonstrieren und maximal das mitgelieferte 3D-Archiv benutzen,
damit man den Bug bestätigen kann und auch das Team ihn einfach per Copy-Paste nachvollziehen kann.
Es gibt einfach so wenig Leute die sich mit der OGRE-Engine beschäftigen...

Ein 3d Objekt das mit #PB_Entity_BoxBody oder #PB_Entity_SphereBody deklariert wurde und den Parameter #PB_Entity_AbsoluteBodyMove besitzt veruhrsacht einen übelen Fehler.

"übler Fehler" ist eine viel zu schwammige Beschreibung.


Wenn dir diese Probleme wirklch so wichtig sind, solltest du bitte etwas mehr Arbeit investieren und Beispiele zur Verfügung stellen, die präzise aufzeigen was nicht stimmt.
dein Kommentar dazu sollte in so wenig wie möglich Sätzen so viel wie möglich Information über den Fehler und die Umstände enthalten.

captain_hesse hat geschrieben:Hallo
Wenn ein 3d Objekt das mit #PB_Entity_StaticBody deklariert wurde und ein anderes 3d Objekt das mit #PB_Entity_BoxBody oder #PB_Entity_SphereBody deklariert wurde miteinander kollidieren dann reagiert ExamineWorldCollisions() und alle für die Kollisionsabfrage zu verfügung stehenden Befehle nicht. WorldPhysics und WorldCollisions sind eingeschaltet.

...dann noch ein zweites Problem.
Ein 3d Objekt das mit #PB_Entity_BoxBody oder #PB_Entity_SphereBody deklariert wurde und den Parameter #PB_Entity_AbsoluteBodyMove besitzt veruhrsacht einen übelen Fehler. Dieses Thema habe ich aber hier im Forum schon einmal angesprochen dazu bittehier weiter lesen oder vieleicht könnte es auch jemand hier her verschieben, gehört eigentlich auch hier rein denke ich.

MfG.
Captain_hesse

Das erste Problem ist Absicht, da man die Levels etc. als Static Body deklariert und man darauf ja nicht reagieren will, sondern nur auf Kollisionen mit dynamischen Objekten. Sonst würde man dauernd bei der Kollision mit dem Boden z.B. etwas auslösen was man garnicht beabsichtigt. Es gehört meiner Meinung nach trotzdem rein. Man bekommt ja die MeshIDs und könnte prüfen ob es ein Static Body ist, wenn es Funktionen dazu gäbe.

Das zweite Problem habe ich mir noch nicht näher angeschaut und ich habe momentan auch keine Zeit dafür, es tut mir leid.

Das erste Problem ist Absicht, da man die Levels etc. als Static Body deklariert und man darauf ja nicht reagieren will, sondern nur auf Kollisionen mit dynamischen Objekten. Sonst würde man dauernd bei der Kollision mit dem Boden z.B. etwas auslösen was man garnicht beabsichtigt. Es gehört meiner Meinung nach trotzdem rein. Man bekommt ja die MeshIDs und könnte prüfen ob es ein Static Body ist, wenn es Funktionen dazu gäbe.

ok... dann dürfte es aber maximal optional eingebaut werden, weil es die Anzahl der benötigten Kollisionsprüfungen potenziert.
man muss also in der Lage sein, diese static-Kollisionen komplett abzuschalten in der Engine selber.

... und hier stellt sich die Frage, was denn OGRE selbst überhaupt zur Verfügung stellt,
vielleicht gibt es gar keine Kollisionen mit Statics, weil es zu viel würde.


zum zweiten Punkt:
wenn du dann Zeit hast schau mal bitte in den Thread, Didi, ich habe den Verdacht, dass das eigentliche Problem durch einen Type ausgelöst wurde, gab damals keine Antwort mehr.

Kaeru Gaman hat geschrieben:

Das erste Problem ist Absicht, da man die Levels etc. als Static Body deklariert und man darauf ja nicht reagieren will, sondern nur auf Kollisionen mit dynamischen Objekten. Sonst würde man dauernd bei der Kollision mit dem Boden z.B. etwas auslösen was man garnicht beabsichtigt. Es gehört meiner Meinung nach trotzdem rein. Man bekommt ja die MeshIDs und könnte prüfen ob es ein Static Body ist, wenn es Funktionen dazu gäbe.

ok... dann dürfte es aber maximal optional eingebaut werden, weil es die Anzahl der benötigten Kollisionsprüfungen potenziert.
man muss also in der Lage sein, diese static-Kollisionen komplett abzuschalten in der Engine selber.

... und hier stellt sich die Frage, was denn OGRE selbst überhaupt zur Verfügung stellt,
vielleicht gibt es gar keine Kollisionen mit Statics, weil es zu viel würde.

OGRE selbst stellt garnichts bereit zur Kollisionserkennung. Fred hat OGRE einfach mit dem ODE Addon und CEGUI Addon verlinkt und die Funktionen PureBasic konform gemacht.

Kollisionserkennung mit Statics gibt es sehr wohl und das macht ja auch Sinn. Sonst würde der Spieler nie auf dem Boden landen oder immer durch die Wände durchgehen. Das sind diese "statischen" Objekte, die keine Trigger auslösen und sich auch nicht im Laufe der Zeit bewegen.

Durch ExamineWorldCollisions etc. listet man alle Objekte auf mit denen ein anderes Objekt kollidiert. Das sind auch mit den "StaticBodies" nicht viele. Aber über das will man in 90% der Fälle nicht bescheid wissen. Angenommen du machst ein Jump'n'Run wie Croc oder Rayman. Dann interessiert es dich in erster Linie nur ob du ein spezielles Feld berührst um mehr Lebenspunkte oder ein Item zu erhalten und weniger ob du jetzt gegen die Wand läufst oder nicht, denn das kann die Physikengine selbst regeln. Desshalb wird dies auch in vielen Fällen einfach der Physikengine überlassen und man gibt nurnoch Kraft oder Geschwindigkeit, Masse, Reibung und einen Abprallfaktor an.

In seltenen Fällen ist es aber trotzdem nützlich zu erfahren, ob das Objekt z.B. den Boden berührt, z.B. um einen Sprung zu ermöglichen. Das kann man in diesem Fall noch durch einen trivialen Workaround herausfinden indem man die Geschwindigkeit bzw Positionsänderung überprüft.

Zum zweiten Problem schreibe ich vielleicht was am Wochenende - Heute schlafe ich seltsamerweise immer wieder ein, das ist zuvor noch nie Tagsüber passiert.

Schönen Abend noch.

Kaeru Gaman hat geschrieben:

Ein 3d Objekt das mit #PB_Entity_BoxBody oder #PB_Entity_SphereBody deklariert wurde und den Parameter #PB_Entity_AbsoluteBodyMove besitzt veruhrsacht einen übelen Fehler.

"übler Fehler" ist eine viel zu schwammige Beschreibung.


Wenn dir diese Probleme wirklch so wichtig sind, solltest du bitte etwas mehr Arbeit investieren und Beispiele zur Verfügung stellen, die präzise aufzeigen was nicht stimmt.
dein Kommentar dazu sollte in so wenig wie möglich Sätzen so viel wie möglich Information über den Fehler und die Umstände enthalten.

Allerdings geht der Satz noch weiter

captain_hesse hat geschrieben:...dann noch ein zweites Problem.
Ein 3d Objekt das mit #PB_Entity_BoxBody oder #PB_Entity_SphereBody deklariert wurde und den Parameter #PB_Entity_AbsoluteBodyMove besitzt veruhrsacht einen übelen Fehler. Dieses Thema habe ich aber hier im Forum schon einmal angesprochen dazu bitte hier weiter lesen.

Ich wollte ja nur einen Doppelpost vermeiden deshalb habe ich den link eingebaut und in diesem Thread habe ich das Problem ja auch so gut es ging beschrieben. Ich werde hier aber noch einmal explizit darauf eingehen.

DarkDragon hat geschrieben: Das erste Problem ist Absicht, da man die Levels etc. als Static Body deklariert und man darauf ja nicht reagieren will, sondern nur auf Kollisionen mit dynamischen Objekten. Sonst würde man dauernd bei der Kollision mit dem Boden z.B. etwas auslösen was man garnicht beabsichtigt. Es gehört meiner Meinung nach trotzdem rein. Man bekommt ja die MeshIDs und könnte prüfen ob es ein Static Body ist, wenn es Funktionen dazu gäbe.

Das zweite Problem habe ich mir noch nicht näher angeschaut und ich habe momentan auch keine Zeit dafür, es tut mir leid.

... außerdem hat man ja nicht nur den Boden als statisches Objekt, Häuser, Bäume, Mauern etc. declariert man auch am besten als Statisch das habe ich bei verschiedenen Experimenten mit Ogre herausgefunden und dann währe es schon ganz gut wenn man wüsste welche Objekte zusammenstoßen, alleine schon, wie soll man einen crach Sound handhaben wenn man keinen Wert zurückbekommt und wenn man solche Objekte als dynamisch deklariert und ein anderes Objekt stößt dagegen ändert sich die Position des Objektes das eigentlich fest stehen sollte und es dreht sich auch leicht egal wie groß man seine Masse setzt. So wenn man nun ein Objekt hat durch das man hindurch oder drunterdurch muß z.B. eine Röhre oder eine Brücke muss man es auch statisch machen da man sonst nicht hindurch kommt da wenn man es als dynamisch deklariert man den durchgang zwar sehen kann aber sobald die beiden virtuellen Boxen zusammenstoßen man nicht mehr weiter kommt. Gut das mag zwar kein Bug sein aber es ist fast schon zwingend notwendig das man einen Wert auch bei statischen Objekten zurückbekommt.

Nun zu:

Ein 3d Objekt das mit #PB_Entity_BoxBody oder #PB_Entity_SphereBody deklariert wurde und den Parameter #PB_Entity_AbsoluteBodyMove besitzt veruhrsacht einen übelen Fehler.

da muß ich jetzt erst mal ein demo Programm schreiben weil das nicht gut zu erklären ist am besten schaut man sich das an.
Fortsetzung Folgt

Hallo,

Also ich hab mir das jetzt mal angesehen. In dem Thread stand, dass man Speed auf 1000 setzten soll, dann würde sich der Fehler, dass die Kamera sich vom Objekt wegbewegt sofort zeigen.
Naja, bei mir flackert das Bild dann bei jeder Bewegung. Das ist vermutlich desswegen, weil die Kamera an irgendeinem Ort außerhalb des Geschehens ist für 1 Frame.

Das hier ist schon korrekt so Kaeru: Er setzt damit den Würfel auf die Höhe des Bodens + 100. Die anderen Parameter sind sozusagen #PB_Ignore (Kann er hier aber ja schlecht nehmen bei Fließkommazahlen, die auch den wert von #PB_Ignore annehmen können sollten).

Danach bewegt er das Entity mit relativ in Abhängigkeit zu Speed, der Rotation und den gedrückten Tasten.

Danach setzt er die Kamera der Ego-Perspektive auf dieselbe Position des Würfels mit Soweit so gut. Die Physikengine ändert die Position des Entities aber nochmal vor dem Rendering-Vorgang in Abhängigkeit von den physikalischen Eigenschaften, den angegebenen Parametern bei MoveEntity und der Zeit, die vergeht.
Das sieht man wenn man das Delay(50) vor dem RenderWorld wieder reinsetzt. Da sieht man den Würfel von hinten. Leider habe ich keine Zeit das 30 Minuten durchlaufen zu lassen, aber kann mir einer mal sagen wie der ablauf da ist oder vllt Screenshots davon machen wie das aussieht wenn das verschoben ist?

Also zuerst einmal Danke an euch für eure Hilfe.
So nun also:

DarkDragon hat geschrieben:Soweit so gut. Die Physikengine ändert die Position des Entities aber nochmal vor dem Rendering-Vorgang in Abhängigkeit von den physikalischen Eigenschaften, den angegebenen Parametern bei MoveEntity und der Zeit, die vergeht.
Das sieht man wenn man das Delay(50) vor dem RenderWorld wieder reinsetzt. Da sieht man den Würfel von hinten. Leider habe ich keine Zeit das 30 Minuten durchlaufen zu lassen, aber kann mir einer mal sagen wie der ablauf da ist oder vllt Screenshots davon machen wie das aussieht wenn das verschoben ist?

Wie du richtig bemerkt hast, wenn man den Delay Befehl mitlaufen lässt dann verhällt sich das Programm exakt so wie nach 30 Minuten wenn speed auf 400 steht, hab das natürlich in den anderen Threads vergessen dabei zu schreiben, ich hoffe Ihr könnt mir das verzeihen aber deshalb hatte ich den Befehl auch uhrsprünglich mit in das Beispielprogramm eingebaut. Wenn man hingegen den Delay aber weg lässt und nur die Variable speed auf 1000 setzt dann kann man nur die Verschiebung sehen die Trägheit oder das Laggen kommt erst später. Also nochmal, wenn man Delay(35) mitlaufen lässt und speed (wie uhrsprünlich) auf 400 stellt hat man genau das Selbe wie nach ca. 30 minuten deshalb denke ich ist ein Screenshot vieleicht auch nicht notwendig ?

DarkDragon hat geschrieben:Die Physikengine ändert die Position des Entities aber nochmal vor dem Rendering-Vorgang in Abhängigkeit von den physikalischen Eigenschaften

stimmt nur teilweise,
richtig ist:

Die Physikengine ändert die Position des Entities aber nochmal vor dem Rendering-Vorgang

aber nicht

in Abhängigkeit von den physikalischen Eigenschaften

das habe ich auch getestet, egal wie man Masse oder Reibungskraft setzt es passiert immer das Gleiche.


Die Physikengiene hat also immer noch einfluss auf das Objekt obwohl es wünschenswert währe das #PB_Entity_AbsoluteBodyMove dieses verhalten gänzlich außer Kraft setzt. Natürlich sollte aber die Eigenschaft das eine Kollision erkannt wird bestehen bleiben.

captain_hesse hat geschrieben:Also zuerst einmal Danke an euch für eure Hilfe.
So nun also:

DarkDragon hat geschrieben:Soweit so gut. Die Physikengine ändert die Position des Entities aber nochmal vor dem Rendering-Vorgang in Abhängigkeit von den physikalischen Eigenschaften, den angegebenen Parametern bei MoveEntity und der Zeit, die vergeht.
Das sieht man wenn man das Delay(50) vor dem RenderWorld wieder reinsetzt. Da sieht man den Würfel von hinten. Leider habe ich keine Zeit das 30 Minuten durchlaufen zu lassen, aber kann mir einer mal sagen wie der ablauf da ist oder vllt Screenshots davon machen wie das aussieht wenn das verschoben ist?

Wie du richtig bemerkt hast, wenn man den Delay Befehl mitlaufen lässt dann verhällt sich das Programm exakt so wie nach 30 Minuten wenn speed auf 400 steht, hab das natürlich in den anderen Threads vergessen dabei zu schreiben, ich hoffe Ihr könnt mir das verzeihen aber deshalb hatte ich den Befehl auch uhrsprünglich mit in das Beispielprogramm eingebaut. Wenn man hingegen den Delay aber weg lässt und nur die Variable speed auf 1000 setzt dann kann man nur die Verschiebung sehen die Trägheit oder das Laggen kommt erst später. Also nochmal, wenn man Delay(35) mitlaufen lässt und speed (wie uhrsprünlich) auf 400 stellt hat man genau das Selbe wie nach ca. 30 minuten deshalb denke ich ist ein Screenshot vieleicht auch nicht notwendig ?

DarkDragon hat geschrieben:Die Physikengine ändert die Position des Entities aber nochmal vor dem Rendering-Vorgang in Abhängigkeit von den physikalischen Eigenschaften

stimmt nur teilweise,
richtig ist:

Die Physikengine ändert die Position des Entities aber nochmal vor dem Rendering-Vorgang

aber nicht

in Abhängigkeit von den physikalischen Eigenschaften

das habe ich auch getestet, egal wie man Masse oder Reibungskraft setzt es passiert immer das Gleiche.

Hättest du meinen Text mal richtig gelesen, dann hättest du gemerkt, dass da eine Aufzählung der Abhängigkeiten ist und nicht nur "physikalische Abhängigkeiten" da steht. Für die "physikalischen Abhängigkeiten" muss die Gravitation an sein. Und dieses Verhalten ist absolut korrekt. Man sollte lediglich pro Kamera noch einstellen können welche Meshs sichtbar sind. Dann könntest du in der Ego-Perspektive sowieso den Würfel ganz weg lassen. Und man sollte die Neuberechnung der Koordinaten von der Physikengine nach den Renderingvorgang setzen.