3D Entity System [DE]

[x-tra]

ich hab mich jetzt mal hingesetzt, und versuch mal selber bisschen durchzublicken.
und zwar ist mir aufgefallen, dass man die gruppennamen eventuell garnicht brauch, eine durchnummerierung würde reichen.

günstig wäre einfach ein EntitySetGroup(entity, beliebiger Integer), was man gleich bei entityerstellung zuweisen kann.

damit würde man sich diese gruppennamenerstellung sparen, man hat ja keine zig gruppen in einem spiel, normalerweise.

als nächstes ist mir aufgefallen, dass das Äquivalent zu EntityAddCollision bei BB3D(Collisions) in der While True Schleife auf Kollisionen zwischen Gruppe a und Gruppe b prüft.(Und das EntityUpdateCollisions() .ist dort das Updateworld und animiert alle objekte und prüft auf kollisionen, EntityDrawSystem zeichnet wohl dort nur alles.aber das nur am rande)abhängig von der prüfmethode.dabei dürfen in einer gruppe nur objekte mit gleicher eigenschaft drin sein, also alle die einen radius haben oder eine box, oder so, jeweils in eine eigene gruppe.also es gibt nicht eine gr_gegner, sondern im extremfall gr_gegner_sphere, gr_gegner_box usw. (achja, bei BB3D ist die standardprüfmethode mit radius, also sphere, weil das am schnellsten ist.polygon wohl am langsamsten)

es soll nur diese drei prüfmethoden geben
Kugel - Box
Kugel - Kugel
Kugel - Polygon

ich denke, das dürfte einigermaßen gut beschrieben sein, hab jetzt seit langem mich mal in die kollisionen von bb3d reingearbeitet, und die praktischste Funktionsweise abgeleitet.


hier mal zur erläuterung zu dem obigen mit EntityAddCollisions und EntityUpdateCollision() bei BB3D, so wie ich das meine.
einfach mal auf die befehle klicken wegen erklärung.

http://www.blitzforum.de/help/Collisions

wichtig ist eigentlich nur Collisions, da dies das Äquivalent zu EntityAddCollisions ist. Unten im Text steht dann noch "Alle Reaktionen werden nur dann ausgeführt, wenn UpdateWorld ausgeführt wird. " Daher meine Idee das Kollisionsupdate irgendwie mit woanders zu integrieren, da wo eben animationen ausgeführt werden, oder bewegungen etc. aber da hast du sicher mehr ahnung.


achja, ein befehl, wo gleich das handle ausgegeben wird bei kollisionen, wäre toll.(also den umweg über EntityGetName$(i) umgehen)


http://www.blitzforum.de/help/EntityCollided   vielleicht interessant

[Kitty Hello]

EntityGetName$ ist ja nur, damit den Den Namen bekommst. Was Du an EntityGetName$ fütterst, das ist der Entity Handle bereits.
Ich hab mir diese B3D Geschichte lange angesehen und es _genau_ so gemacht. Nur halt andere, sinnvollere Namen vergeben.

[x-tra]

Also was ich an EntityGetName$ füttere ist doch der index, also eine Zahl.man müsste gleich den namen direkt bekommen, das würde bei
Kollisionsprüfungen etwas einfacher machen, ist aber net tragisch, ist ja nur ein befehl mehr.


ich weiß, ich weiß, ich fand nur das mit den gruppennamen zum beispiel etwas verwirrend, weil es doch ziemlich viel extra code ist, ich denke zahlen sind da praktischer, da muss man nichts extra deklarieren, oder meinst nicht?

und warum ist dort das collisions in der while true schleife, wäre es nicht sinnvoller unsere überprüfung als einziger befehl ebenso in die schleife einzubauen?

also ein entityaddcollision(a,b,type)
           entityaddcollision(a,d,type)
usw.

ich werd bei mir später mal eher aus EntityAddCollisions  ein EntityCollisions machen, denke ist praktischer.

und am ende mit einem befehl alles updaten und dann eben ein entitydrawsystem().

mir raucht schon der kopf.

achja, wir müssen unbedingt dazuschreiben, dass in einer gruppe nur objekte drin sein dürfen die zu der prüfmethode passen, ich weiß ja nicht, ob das sonst einen fehler provozieren würde.

[Kitty Hello]

Alle Methoden funktionieren beim Erstellen/Laden schon. Ich parse die Modelle durch und mach eine Kugel und eine Box drum rum. Sollte man evtl. vermerken.

[x-tra]

das hab ich jetzt nicht wirklich verstanden?!?


achja, mach doch noch nen paramter rein, dass wenn EntityAddCollision(a,b,typ,reaction) ...

also wenn player in gruppe a ist, und mit irgendeinem entity aus gruppe b unter beachtung des kollisionstyps(typ) kollidiert, dann erfolgt reaction.

reaction:  0 = nichts
              1 = stop

sliden und raufsliden wären noch möglich, aber allein so ein stop, wäre schon sehr hilfreich.

[Schranz0r]

AAAAAAAAALLLLLLLLLLLLSSSSSSSSOOOOOOOOOOOOO


Die Kollisionen sollten im Prinzip einzeln oder auf die Masse geprüft werden können, sprich:


EntityGetCollision( Mesh1, Mesh2) // sollte auch Mesh->Box,  Box->Kugel, Kugel->Mesh, Box->Box, Kugel->Kugel können ( jetzt nicht hauen Gernot  ^^ )

Und

EntityGetGroupeCollision( Groupe1, Groupe2) // Gibts ja glaub schon, evtl als byref die returns der jeweiligen Meshes was sich berühren ?
z.B so   EntityGetGroupeCollision( Groupe1, Groupe2, BYREF Coll_Mash1, BYREF Coll_Mash2)


Desweiteren sollte eine Entity -> World Kollision da sein, World ist dabei von mir aus auch eine Gruppe.
Diese sollte jedoch die Slidecollision beinhalten ( Programmiertechnischer aufwand bestimmt sehr hoch, aber extrem sinnvoll!)

Gernot wird mich jetzt bestimmt verfluchen, aber sonnst ist das ES echt eine Augenweide !

[x-tra]

[edit] achso, der extra parameter, wenn gruppe a mit gruppe b, dann bspw. stopp, oder sliding.und hinterher kann man ja noch einzeln entscheiden, was das entity machen soll.


nein, die bisherigen Gruppenkollisionen sind nur da um rechenleistung zu sparen, sonst würde immer alles gegen alles geprüft werden, und so kann man das auf gruppen und deren prüfmethoden begrenzen.

und deine entity-entity methode ist toll, aber eben trotzdem gruppenabhängig.

hier mal stück code, so hab ich das gemacht.

Code: (glbasic) [Select]

LOCAL gplayer = 101
LOCAL ground = 102

light = EntityCreateLight(RGB(255,255,255) )
camera=EntityCreateCamera()
          EntitySetCameraRange(camera,1,1000)

level = EntityLoadMesh("level.ddd")
     leveltex=EntityLoadTexture("level.bmp")
          EntityApplyTexture(level, leveltex, -1 )
                   EntitySetGroup(level, ground)

juru = EntityLoadMesh("juru.ddd")
     jurutex=EntityLoadTexture("juru.bmp")
          EntityApplyTexture(juru, jurutex, -1 )
               EntityCollisionSetRadius(juru, 0.4)
                    EntitySetGroup(juru, gplayer)

stumpf = EntityLoadMesh("stumpf.ddd")
     stumpftex = EntityLoadTexture("stumpf.bmp")
          EntityApplyTexture(stumpf, stumpftex, -1)
               EntityScale(stumpf, 20, 20, 20)

stamm = EntityLoadMesh("stamm.ddd")
     stammtex = EntityLoadTexture("stamm.bmp")
          EntityApplyTexture(stamm, stammtex, -1)


EntitySetPosition(level, 0, 0, 0)
EntitySetPosition(stumpf, -2, 10, -2)
EntitySetPosition(stamm, 10, 19, 0)
EntitySetPosition(camera, 0, 7, -15)
EntitySetRotation(stamm, 0, 70, 0)
EntitySetPosition(juru, 0, 10, 5)
EntitySetRotation(camera, 15, 0, 0)

EntityParent(light, juru)
EntityParent(camera, juru)
EntityTranslate(light, 0, 2, -2)

EntityEnable(camera, TRUE)

//Kollisionsgruppen initialisieren
EntityAddCollision(gplayer, ground, 0)
//

WHILE TRUE
GOSUB Kollisionen
GOSUB Movement
GOSUB UpdateMovement
EntityDrawSystem()
EntityUpdateCollisions()
X_MAKE2D
PRINT updown, 10, 10
PRINT EntityGetY(juru), 10, 20
SHOWSCREEN
WEND

SUB Kollisionen:
             LOCAL ncol = EntityCollisionCount(juru)
              FOR i = 1 TO ncol
                 IF EntityCollisionEntity(juru, EntityGetName$(i)) = level THEN collevel = 1
              NEXT
ENDSUB
 
SUB Movement:
//Sprung
            IF collevel = 1
               updown = 0.01
               collevel=0
             IF KEY(57) THEN updown=0.5
            ELSE
               updown=updown-0.02

            ENDIF

// drehen und bewegen
            IF KEY(203) THEN jy = 1
            IF KEY(205) THEN jy = -1
            IF KEY(200) THEN jz = 0.5
            IF KEY(208) THEN jz = -0.5

ENDSUB


SUB UpdateMovement:

EntityRotate(juru, 0, jy, 0)
EntityMove(juru, 0, 0, jz)
EntityMove(juru,0,updown,0)
EntityRotate(stamm, 0, 0, 1)
jy=0;jz=0

ENDSUB

aber ich denk, auch, dass es einfacher gehen müsste.

naja, so wie es momentan ist, kommen wa och klar.

achja, mesh is polygonkollision, oder?

und kann man um EntityDebug mode auch die kollisionsradien und boxen sichtbar machen, wäre vielleicht hilfreich.

um bspw. eine box an ein objekt anzupassen.

[x-tra]

oh ja, wenn man sliden könnte nach kollision, da hat schranz0r recht, das wäre hammer.

weil, man prüft bspw. gruppe player gegen level, und wenn es da zwischen den gruppen zu einer kollision kommt, dann hintendran eben stop, sliden, oder raufsliden wie bei bb3d.

also so hier: EntityAddCollision(gruppe_player, gruppe_level, kollisionstyp, reaction)
reaction wäre dann stop, sliden oder raufsliden.

Deswegen ist der Befehl Collisions bei BB3D auch in der While True Wend schleife.

im weiteren verlauf kann man ja dann einzelne abfragen der entities gegenüber machen, aber so für den grund wäre das super, und so meinte es schranz0r auch. denk ich.p.s. so ist es bei bb3d.

man könnte dann wie in meinem codebeispiel eine einfache player-welt kollisionsprüfung machen, wo, wenn player mit irgendwas aus der welt gruppe zusammenstößt, gestoppt, oder auch geslidet wird(ich denke mal es werden minimal die werte beim sliden verändert.)jedenfalls, benötigt man keine einzelnen abfragen, so wie ich das momentan tun muss, ich musste mit pivots arbeiten, da boden kollision anders ist als wandkollision, ein einfaches stop hintendran, und das problem wäre gelöst, beim kollidieren mit allem was im in der level gruppe drin ist.dann nur noch den sprung mit rein, es könnte so richtig einfach sein.

so muss ich mir erstmal mit pivots helfen, um einzeln auf boden oder wandkolli zu prüfen.

ach und gaaaanz wichtig, könntest du bitte ein kleines update des ES machen, weil pivots nicht kollisionsfähig sind, ich brauch das aber uunbedingt.

danke dir, bist ein schatz.

bzw. kannst du hier auch schreiben, was du geändert hast, hab selber an meinem ES bisschen rumgefrickelt, und würd das gern austauschen wollen.

dankeschön


achja, kann man auch onthefly kollisionen verändern.stell dir vor eine spielerfigur.ich mach da zwei versetzte pivots ran.eins bekammt nen radius für die bodenkollision, ein ne box z.b. für wand kollisionen.so, was aber mach ich wenn ich springe, und da mal ich irgendwie durch hüpfe, oder so, kann ja passieren, man weiß nie.man könnte dann noch eine kollision mit einem extra pivot machen, was einen kompletten radius um alles bekommt, oder eben einfach um den ganzen spieler, und somit gegen kollisionen jeglicher art prüfen.

das müsste man jedoch ab und anschalten können.

puh sicher kompliziert erklärt.

also 1. diesen parameter hinter entityaddcollision damit bei kolli der gruppen eine reaction in form von stop, sliden etc. ausgeführt wird
       2. pivots kollisionsfähig machen
      3. animationen etwas verbessern, also vielleicht mehr als nur ein befehl, oder so.
      4. vielen dank

[Kitty Hello]

Die Kollisionen sollten im Prinzip einzeln oder auf die Masse geprüft werden können, sprich:

Verstehe. Das ist relativ easy zu machen. Werd ich einbauen. Aber: Wird's dann nicht ein riesen Wirrwarr an Befehlen?

...
Diese sollte jedoch die Slidecollision beinhalten ( Programmiertechnischer aufwand bestimmt sehr hoch, aber extrem sinnvoll!)

Ja, schon klar. Wenn Du's sagst, mach ich's rein.

Pivots können Kollidieren!? Brrr....
"Mia thun whaf mir khönhen!"

Bitte ein Beispiel: Was macht B3D, wenn man Sliding oder Vertikal Sliding macht, wenn man 3 oder 4 Körper von aussen gleichzeitig in der Mitte zusammenschiebt?
So:

Code: (glbasic) [Select]

   2
   |
   v
1-> <-3
   ^
   |
   4

Bleiben alle stehen? Überschneiden die sich und klemmen für immer?

[x-tra]

Ähm pivots können kollidieren?!?

und wie?

ich hab sphere-mesh kollision gemacht. geht nicht.wenn ich statt nen pivot ne sphere erstelle, gehts.
hab auch nen kollradius drum gemacht.

gernot, ich weiß, ich schreib viel, aber manchmal ist es sinnvoll meins auch zu lesen.

du hast die befürchtung, dass es ein riesen wirrwarr wird wegen der einzelnen und massemässigen kollisionsprüfung.

es könnte im idealfall nur ein einziger befehl mehr werden.(vielleicht auch nur ein parameter extra)

Das was bei dir EntityAddCollision macht, macht bei BB3D Collisions.

Nur, mit zwei Unterschieden.
1. wird es bei BB3D immer in der While True schleife ausgeführt.
2. extra parameter, wenn (ein Entity aus)gruppe a mit (einem Entity aus) gruppe b unter prüfmethode c kollidiert, dann d (stop, sliding) ausführen.

einfach genug?

achja, für den anfang würde es doch reichen, dass sich intern immer irgendwo die positionen gespeichert werden, und bei collisionen wenn stop gewählt wird, einfach die alte posi und drehung und was auch immer, wieder hergestellt wird.

[Kitty Hello]

Ähm pivots können kollidieren?!?

Ja, ich wusste nicht, dass B3D das kann. Ich bau's mal ein.

2. extra parameter, wenn (ein Entity aus)gruppe a mit (einem Entity aus) gruppe b unter prüfmethode c kollidiert, dann d (stop, sliding) ausführen.

OK, das bau ich noch ein. Siehe meine Frage weiter oben dazu!

achja, für den anfang würde es doch reichen, dass sich intern immer irgendwo die positionen gespeichert werden, und bei collisionen wenn stop gewählt wird, einfach die alte posi und drehung und was auch immer, wieder hergestellt wird.

Jo, dass ist easy. Aber! Werden "beide" bei der Kollision zurückgesetzt? Oder nur einer der Beiden? Und wass passiert, wenn beide "Sliden" dürfen?

[x-tra]

zu 1. vielen dank, super.

zu 2. ich mach mich gleich schlau.

zu 3. siehe 2.

ich editiere dann hier.

aber ich denke mal, dadurch, dass der befehl in der while true schleife steht, wird ja immer wieder geprüft obs kollidiert, und wenn man etwas bewegt, ändert sich ja der zustand der kollision.

hab mal geschaut: http://www.blitzforum.de/help/Collisions

ich denk mal, dass sich sliden, stop auf das objekt in der ersten gruppe bezieht.

da bin ich mir soagr ziemlich sicher, denn bei collision zwischen  player und welt, darf doch nicht die welt sliden, das wäre ja quatsch, weil dann bewegt sich ja der level immer ein stück.

demzufolge reaktionsparameter nur für erste gruppe.

für alles andere kann man ja seperat die reaktion zusätzlich für jedes entity steuern.

schau mal bei dem link oben, vielleicht wirst du ja auch sonst noch etwas schlauer draus.

habe ausserdem mal unter einem alten acc im forum dort gefragt, mal sehen, was die so von sich geben.

gerade, wenn mehrere aufeinandertreffen, wäre schon interessant.


hier schonmal eine antwort aus dem bb forum:

Code: (glbasic) [Select]

Wenn du Gruppe 1 gegen Gruppe 2 Fliegen lässt dann bleibt die erste stehen.

Ein Tipp zu Collisions: Bei blitz3D sind Kollisionen mit 2 bewegenden Objekten fast unmöglich. Normalerweise funktioniert das nur bei Kugeln die beide einer gruppe angehören:

zB: Collisions 1,1,1,2

Das würde die Kugeln(mir EntityRadius) der ersten Gruppe gegen andere Kugeln der ersten Gruppe prallen lassen.

Bei Box Kolli funktioniert das nurnoch bedingt und bei Poly kannst du's eigentlich vergessen.
haben wir also schonmal gelernt, dass kollisionen auch innerhalb einer gruppe möglich sind, bzw. sein sollten.

was logisch ist, aber vlt. etwas komplizierter für dich wird, weil dann nichtmehr gilt, dass alle aus der ersten gruppe gegen die 2. geprüft werden, sondern notfalls, alle aus einer gruppe mit allen aus derselben gruppe, ohne dass sich jeweils eins aus einer gruppe mit sich selbst prüft, weil dann gäbe es ja immer eine kollision. ist wie als wen ich mit mir selbst zusammen rennen würde, was ja nicht möglich ist....

[Kitty Hello]

Gruppe 1 mit Grupp1 geht schon. Hab ich alles gemacht. Und den EntityUpdateCollisions mussts Du freilich in die WHILE Schleife packen.
Der Befehl ist (bis auf "reaction") komplett identisch mit B3D's "Collision".
OK, also diese Resonanz macht kaum Sinn, dachte ich mir schon. Ich bau's ein, aber ich meine auch, dass es gescheiter sein wird Newton "einfach" einzubinden.
Dann wird's allerdings wieder ziemlich cool.

[x-tra]

achja, der Befehl EntityUpdateCollisions ist ja nicht identisch, weil der kollisionstyp ja bei glb schon vorher ausserhalb der schleife mit EntityAddCollision gesetzt wird.
praktisch wohl das gleiche, nur was ist wenn ich während des spiels kollisionen ändern will?
das würde dann ja nicht gehen.
oder?

Was meinst du mit Resonanz? Auf was?

danke dass du es mit einbaust, und ich hab mich mit newton überhaupt noch nicht befasst.

ohne einen einfachen tut, tu ich mich da grad bisschen schwer, is grad auch ne zeitfrage.

nun, wenn du die pivotkollision und das mit der reaction auf massen bzw. gruppenprüfungen drin hast, kannst du da noch wegen dem animationskrams schauen.

vielleicht irgendwas, was du da noch für notwendig erachten würdest.

damit ich eben meinen player anständig animieren kann.(der wird eh an ein pivot gepappt, daher auch pivotkollisionen...)


[edit] wenn du noch paar anregungen haben willst, hier mal die collisionen von c3d, anklicken und mit dem IE öffnen, also der IE7 kann es öffnen.
         http://www.glbase.de/help.xps

[Schranz0r]

...Ich bau's ein, aber ich meine auch, dass es gescheiter sein wird Newton "einfach" einzubinden.
Dann wird's allerdings wieder ziemlich cool.

Sagte ich ja schonmal irgendwann vor 2-3 Seiten ^^
Gut Newton einbinden ist so ne Sache oder( Winonly? )?

Was machen die Würfel wenn sie aufeinanderprallen.... Hmm gute frage!

Ich würde sagen die verschieben sich in eine Richtung in die sie können.
Aber rein thoretisch stoßen da ja die Ecken exakt aufeinander wenn die alle die gleiche Entferrung, Speed und die exakten Winkel haben.
Also müssten sie stehen bleiben!
Da die Slidingcollision ja so ist, das wenn du im rechten Winkel auf die Wand zuläufts mitn Kopf an die wand rennst, und wenn du nun weiter läufts bleibst du stehen !
Wenn du jetzt im 45° Winkel ankommst berührst du mit der Schulter die Wand und wenn du nun so weiter läufst geht es zwar vorran , aber nur ca. halb so schnell, wie wenn du mit einen kleineren winkel wie 2° dagegen läufst.(Sliding)

@ Heiko:

Sicher kannst du im laufenden Spiel die Collisiongroupe wechseln für ein Objekt!