Hi Leute,

nachdem ich mich vor einiger Zeit schonmal an OpenGL probiert habe und aus diversen Gründen gescheitetert bin, starte ich jetzt einen neuen Versuch. Bei meinem ersten Versuch hatte ich (zumindest im Großen und Ganzen) keine Probleme eine "Welt" zu erstellen, in der ich mich in einem Raum frei gewegen konnte - für meinen Geschmack jedoch etwas zu frei - irgendwie mag ichs doch mal ab und zu ganz gerne, wenn mir eine Wand auch mal das Hndurchgehen verweigert.
Kollision ist also das Thema. Nun, ich war soweit ganz glücklich, dass ich grundsätzlich verstanden habe, dass es natürlich darum geht hier über Schnittflächen oder -punkte festzustellen, ob eine Kollision vorliegt, jedoch bin ich dann irgendwie auch an der Mathematik gescheitert - das passiert mir jetzt hoffentlich erstmal nicht mehr. Vielmehr ist mir jetzt klar geworden, dass etwas grunsätzlicheres fehlt: Wie und Wo legt man eigentlich "Objekte" richtig fest?!
Ich hab das glaub ich schonmal gefragt, aber kann mir nicht einer einmal ein ganz simples Programm zur Verfügung stellen, das einfach nur eine Mauer enthält und mich daran hindert hindurchzulaufen?

Und, ums gleich noch komplizierter zu machen: Einfach nur feste Werte bei der Kollisionsabfrage machen natürlich keinen Sinn. Ich brauch doch also im Endeffekt sone Art "Tabelle", in der alle meine Objekte eingetragen sind (ob die dann alle überprüft werden oder über Vefahren wie Bounding Boxen, Octtreees etc. einige ausgeschlossen werden is erstmal zweitrangig)? Und genau das scheint mir irgendwie seltsam?!
Also, ich fühl mich nun wirklich grundlagentechnisch schon recht belesen, aber zu diesem Thema hab ich weiß Gott nichts gefunden (außer vielleicht diese BSP-Maps, wo faktisch die Informationen "mitgeliefert" werden, aber das is angeblich ressourcenvergeudend und außerdem würde das ja bei ner größeren Karte auch wieder etliche Abfragen bedeuten).

Falls ich einigen Pro's hier trotzdem ein wenig desorientiert vorkommen (obwohl ich glaube genau zu wissen, was ich nicht verstehe), dann wäre mir auch nochmal ne Belehrung recht, aber, wie bereits gesagt: Ein einfaches (oder von mir aus auch komplexeres - ich arbeite mich da rein - ) Programm käme mir sehr gelegen.

Ich weiss nicht ob du es schon gelesen hast(eigentlich nicht zu übersehen ^^) aber es gibt fertige Physik Engines wie Newton z.B. diese Beherscht nicht nur schnelle Kollisionsberechnungen mit. Sonder darüber hinaus bringt es auch weitere dinge wie Raycast mit, die für Selektionen und überprüfungen auf sichtbarkeit praktisch sind und es ist Dokumentiert.

Wenn du aber wirklich sowas selber machen willst guck mal bei gamestutorials nach dort sind nicht nur Plane,Line,Polygon collisionstechnicken beschrienben sondern auch Tuts zum Thema Collision und BSP.

MfG TAK2004

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Danke. Also das mit den Physikengines scheint mir "neuer" oder "trendiger" zu sein, denn davon wusste ich bis dato nichts. ich guck mir die mal an - obwohl es ja irgendwie auch die Grundlagenprogrammierung ist, die zwar einerseits wirklich schwierig (da planungsbedürftig), andererseits aber auch spannend ist.

Klar ist das eigentlich mit das "spannenste" der Programmierung mit Kollisionen usw.
Aber ich muss sagen, dass hatte ich auch vor, aber ohne Newton keine möglichkeit das umzusetzen.

_________________
www.audi32.de

Also kolision mit ner Mauer das sollte eigentlich schon machbar sein. Nur bleibts ja net dabei...Und da kommen die Phyikengines ins spiel.

Wenn dus mit der Hand machen willst, dann kannst du deine Komplette welt z.B. als Boundingboxen oder allgemeiner aus BoundingObjekten basteln und in nem Quadtree ablegen. Dann brauchst du nur noch die Kollision für die Objekte benutzen, die im selben Quadtreeknoten liegen wie deine Kamera.

Aber Physikengines können die sache sicherlich bequemer machen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Joa!

Ausser du entscheidest dich für Heightmaps und ein Spiel ohne aufwändige kollisionen dann kannstes locker selbst realisieren.

Aber schau dir mal Newton an, ist echt ne klasse Sache.

_________________
www.audi32.de

Hm, frage mich immer wieder was an normaler Kollisionsabfrage so schwer sein soll. Man hat die Dreiecksdaten, man weiß wo der Spieler ist, und im Netz gibts sogar fertigen Delphicode für Dreiecks-Linien-Intersektion. Dann repräsentiert man den Spieler über seine drei Hauptachsen, die man dann je nach FPS skaliert und testet diese gegen alle in Frage kommenden Dreiecke und fertig ist die Kollsionsabfrage. Kollisionsreaktion ist dann nochmal ne andere Sache.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ob das wohl so robust ist nur die Hauptachsen zu testen. Da besteht ja dann doch noch die Möglichkeit, dass man in eine Ritze fällt, die nur wenige cm breit ist. Oder wenn man sich einer Ecke schräg von der Seite nähert, kann die Kante dann bis nah an die Kamera heran.

Nimmt man halt Achsen diagonal durch den Körper und davon 2 oder?
Naja Obwohl, sollte man schon wie ne Box testen...

_________________
www.audi32.de

Robust ist das natürlich nicht, aber im Normalfall (hatte es ja selbst in nem Ego-Shooter im Einsatz) reicht das. Aber zumindest lernt man so mal ne Möglichkeit kennen wie man Kollision regelt, und v.a. wie man sowas umsetzt. Wenn man das erstmal implementiert hat kann man das ja dann noch nach Gusto erweitern und robuster machen. Mir ging es eher um den Lerneffekt : Man kann zwar ne Physikengine nutzen, aber in meinen Augen sollte man doch mal ne Kollisionsabfrage selbst implementiert haben. Bei der Programmierung geht es ja (zumindest finde ich das so) nicht nur um die Implementation selbst (also dass es funktioniert), sondern auch um das "warum". Und selbst wenn man es nicht selbst macht, kann es besonders bei der Parametrisierung bzw. Fehlersuche helfen wenn man weiß wie es geht. Ne Physikengine ist z.B. ein gutes Beispiel : Sie lässt einen z.B. ein Fahrzeug einfach implementieren, aber wenn man nicht weiß wie ein Fahrzeug funktioniert, dann wirds im Fehlerfall (bzw. wenn es sich eigenartig verhält) sehr schwer dies zu berichtigen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Keiner sagt das die Normale Dreicksbehandlung wie bei GamesTutorials so schwer sind aber man will doch auch noch schöne Reibungen und und und. Sowas stellt sich als zeitaufwendig, ich habe damals auch meine Kollision per eigene Plane und dann Poly Intersection gemacht aber ist nicht so der Burner.

Da ist doch viel toller ne schöne Physiklib zu nutzten die einige in mühevoler kleinarbeit sich aufgebaut haben und freuen wenn man es huldigt ^^. Aber das sollte nicht davon abhalten sich mit der Theorie zu beschäftigen im gegenteil nichts ist schlimmer als copy paste und dann wenn es nicht geht noch die Zeit von anderen Leuten für das debugen zu vergolden.

MfG TAK2004

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Sasch, ich habe mal versucht was zu finden, da du sagtest warum das ein Problem ist.
Aber ich muss sagen ich habe nichts gefunden ...
wurde von google dann aber des öffteren hier auf DGL verwiesen, wos auch zu men Thread von dir ging.
Da gings über so ne Unit für Matheberechnungen.
Da steht dann allerdings kein Link...

Nur mal so

_________________
www.audi32.de