A potential way to eliminate collision checks with solids?

0 favourites
  • 5 posts
From the Asset Store
Particles support animations, collisions, effects and etc.
  • Ashley

    This occurred to me while messing with wall-tracing enemies / weapons that use a lot of collision checks with solids + solid tilemaps...

    The platform behavior already has "is touching wall" and "is on floor" which to my knowledge are handled in the behavior's script and simply return true or false -- using them in events does not create extra collision checks.

    If it also had "is touching ceiling" then we would be able to check if it's overlapping solids on all 4 sides without the need for "Is overlapping at offset", drastically reducing the amount of potential collision checks with solids.

    Better yet, if there was an offset parameter to "is touching..." and all the basic movement behaviors had them, then we can eliminate event-based collision checks with behaviors<>solids completely, since they'll just be checking if a particular existing overlap from the script is true or false.

    Considering a large portion of overall collision checks are simply to see if objects with behaviors are interacting with solids in some way, I think this could be rather beneficial. Thoughts?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • The platform behavior already has "is touching wall" and "is on floor" which to my knowledge are handled in the behavior's script and simply return true or false -- using them in events does not create extra collision checks.

    This is not true, I just tested with the Platform template and here are the results:

    • Default template: ~240 collision checks per second.
    • With "Is by wall" event: ~420 collision checks per second.
    • With "Is overlapping at offset" event: ~360 collision checks per second.

    So testing for overlapping at offset is actually better for performance as it uses less collision checks.

    But I agree, including "is touching ceiling" would be an simple and useful addition to the Platform behavior.

  • The platform behavior already has "is touching wall" and "is on floor" which to my knowledge are handled in the behavior's script and simply return true or false -- using them in events does not create extra collision checks.

    Actually as dop2000 has found, these both do collision checks internally as well. They are essentially glorified "is overlapping at offset" checks (but taking in to account other cases like slopes and jump-thrus).

    But even before we get to that, the #1 question for anything related to performance - particularly when implementing new performance-related features - is: what measurements do you have indicating this is a performance bottleneck? The collision engine has already had tons of optimisation work done on it. In particular collision cells normally mean that objects only test collisions against nearby instances. Then objects whose bounding boxes don't overlap are extremely fast to reject as not overlapping. So the real work of collision checks tends to only be poly checks for objects that are actually overlapping. Even this tends to be very little work compared to everything else happening in a project.

    The cases I've seen where collision checks really do affect a project's performance are truly extreme cases, like spawning 1000 objects on-screen at once and having them all check collisions against each other. In that case there's lots of objects in one collision cell, and so the main performance bottleneck is simply iterating through the ~1 million combinations of objects every tick. (And if that all got spread out over a large area, collision cells would still keep it running fast.)

    It's easy to speculate about performance and end up spending ages writing lots of fancy code that ends up having negligible effect on any real games. As a small company with loads to do this has a high opportunity cost, so we have to be careful to spend our time on things that are provably necessary wherever possible.

  • Ashley

    Thanks for clarifying. I had assumed the "Is touching..." collision checks were already occurring since having objects with platform & solid behaviors with no events increases the collision count in the debugger.

    I know you guys have to take great consideration into any features like this anyway. I've been here since the beginning :) Just wanted to see if I was on to something.

    On the subject though - is there a general amount of collision checks we should try to stay under? You mentioned millions per tick is extreme, and I'm over here thinking numbers like 50,000 per tick is too high lol.

  • Tokinsom You should try firing up the "Raycast reflections" example project. It casts a ray with "as many reflections as it needs". Depending on how long those rays are that is a lot of collision checks. I'm seeing ~1.5% CPU time increase for 50000 collision checks per second.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)