Collision

[Kjell]

Hi guys,

So close .. but not quite yet In another attempt to create a collision system that communicates directly with Clones and their properties I managed to set up a pretty solid solution .. as long as you don't use the build in Position, Rotation and other property's you want to consider in your collisions Since this is quite a nuisance, would it be possible to have a CheckCollision Component that basically is a portable OnCollision Event Trigger to be used in OnUpdate?

I've attached a example containing a bend Plane, and 2 Cloned Arrows that can be controlled using WASD and the Arrow Keys making use of the Build-In Position Properties. As you can see ( especially due to the low framerate ), the Position data used for the collisions is one frame old.

*Just to be clear, the Arrow Models don't contain any Expressions on the shape of the Plane, only simple Horizontal Movement and fetching the generated collision data. All Collision results are calculated by the Plane itself.

K

[VilleK]

This looks promising Kjell.

How does it work? How do you send data between the surface and the clones?

I definitely consider inter-clone communication to be the highest priority feature for ZGE, and the largest hurdle for making more advanced games. So I always have that in mind while working on ZGE and try to find a good solution, most likely in the form of extending the scripting language with some kind of "with ... do" functionality. But I can't promise when it will appear.

[Kjell]

Hej Ville,

In short, a Parameters, Result and Index Array. Since Collisions are handled in the order that Clones are Spawned, you can just write off any Parameters you want to use in the OnCollision Event, increase the Index specific to that Collision Category combination and fetch the Parameters on the "other side" of the Collision ( you know, a Collision between two Clones causes a OnCollision Event to occur on both of them ). Then it's just a matter of calculating the appropriate results and storing them just in time for the OnUpdate Event.

Again, this fully works ( without any 1 frame old data issues ) as long as you don't use the build-in Position, Velocity etc. variables. You need to define local variables for those that you sync with the build-in properties in OnUpdate.

K

[jph_wacheski]

interesting,. . not sure how that is working, however it is a nice little set up,. could be a fun two handed game,. . in the Excellent Bifurcation vain.

I too am most interested in seeing some way to talk to clones individualy,. . damn clone-wars.

[VilleK]

That's a clever technique of using arrays Kjell. What about the CheckCollision-component you mentioned, can you tell me more on how you would like it to work?

[Kjell]

Hej Ville,

Well, basically a component that triggers the OnCollision check to occur again by request. It's probably most convenient if the Component itself has a OnCollision Event then just like Model / AppState and such have.

Going off-topic now

However, this is more or less just a work-around of having a fixed order pipeline. In order to make a behavior system truly flexible, I think a Priority property on most Components will be necessary. Unfortunately this kind of collides with the current design principle of ZGE .. let me explain.

For example, let's say you have a Model that you want updated before the other, right now you just Spawn it before the other .. but you run into problems when you start Spawning dynamically.

Now imagine this, let's say you have a couple of Models of which you want certain Components to execute before the rest. Right now there's no way to do so apart from using the OnCollision Event as the first priority slot, and OnUpdate as second. GM ( which also has a fixed pipeline ) for example solves this by having 3 States ( Begin Step, Step & End Step ), which still can be far too limiting. If you'd be able to set the priority on a Group or other individual Components, you have much greater control over the order things happen in ( obviously this does requires the Scene / State Manager to sort Objects before starting a execution pass ).

Perhaps technically you'd want to have a PriorityLevels property on App, so the number of levels is pre-defined. But even then it shouldn't be too complicated to comprehend.

Problem is ( here it comes ) that the moment on which a Model's Position, Rotation etc. are applied is currently fixed too ( after OnUpdate ). This is exactly the reason I had to ditch them .. And as long as there are any items fixed in the pipeline, a priority approach will always be crippled.

Anyway, this is a design issue .. plus I have no doubt that with a fixed pipeline you can have great flexibility as well.

Sorry, had to get that off my chest
K

[VilleK]

Hey Kjell, I've said it before: you really push zge to it's limits all the time
I just wonder what kind of advanced stuff you are working on.

The reason it works the way it does right now is of course because it was the easiest way to implement. And as it only requires a single loop through the models each step it is also the fastest.

If we are to change this we really need to think it through so that it is flexible enough: support control over draw-order, update-priority, fast iteration on subsets using scripts etc.

But also keep in mind it cannot be as generic as the larger engines out there, it is simply not possible to fit everything within a 64kb runtime.

So we need to collect all requirements in a thread and work on it until we are sure it will be good enough, and then start the implementation afterwards.

[Kjell]

Hej Ville,

By the way, not sure if I did ask you this before or not .. but why is OnCollision executed before OnUpdate in the first place?

*Incorrect statement

K

[VilleK]

As far as I can remember there is no real reason for this and it's just a coincidence it was implemented in that order. But I could be wrong.

[jph_wacheski]

This is just an idea but, perhaps,. as we approach the 2.0 mark we should consider a re-design of the system? Levereging all the implemented code that is in there now and working so nicely,. however having discussions of the best architecture for a general system, as some stuff that sounds important to me like only including just the components that are used, and scritability could benifit from a bit of overall system architecting,. . a brake with back compatibility, but a newer more robust system could be created,.
just a thought, like I said, but i have found that by building things once and then reaching a point where it seems easier to re-build from the begining with all the new knowlage generated from the first design can often lead to much better results,. also when rebuilding, many things that took forever at first, we find are now trivial with the new learned skills from the previouse builds,. . (I just watched IronMan so perhaps this influances my thoughts here.)

[Kjell]

Hej guys,

Rebuilding from scratch will take a lot of time ..

Anyway, the only reason I can think that OnCollision might be executed before OnUpdate is for the Collision Action "Stop" behavior. However, even if that's the case, it should be able to work the other way around as well.

Here's what I'd like to propose. The top time-line shows the behavior as it is now when not using "Stop". The Collision behavior will always be a frame late when using the build-in properties. The bottom time-line shows the proposed approach, with the OnCollision executing after OnUpdate, and if OnCollision is true, the build-in properties get updated a additional time after OnCollision.

*Removed incorrect statement. Proposal was already the way things work.

K

[VilleK]

I just checked the code. Here is the current order, from ZApplication.pas (stripped away irrelevant lines):

Code: Select all

Models.Update;

Collisions.Update;

UpdateScreen;

Models.Update both call OnUpdate on each model and updates properties based on velocities.

UpdateScreen calls OnRender for every model.

Collisions.Update performs all collision checks. If collision is detected and mode is "Stop" then it will try to modify the models position out of collision by moving towards the previous position.

[Kjell]

Guess it's time to take a weekend off The worst part is that I even listed the correct order a long time ago myself.

K