How do I get more accurate collisions at high velocity?

0 favourites
  • 8 posts
From the Asset Store
Particles support animations, collisions, effects and etc.
  • I was messing around with a "realistic" bullet penetration prototype and currently the detection of the collisions is less than desirable. Currently it completely bypasses any object smaller than the green box and will sometimes even skip it at its current size.

    It runs fine locally at mostly 60fps, but this is just a messy prototype so don't expect the best performance. Firing too fast seems to wreck the fps in some cases also sounds might repeat or not play etc etc.

    I have tried altering the stepping of the physics object, but this seems to have no effect.

    I saw a posted example of pixel perfect collision detection, but unfortunately the performance was lackluster and used a messy loop that caused the cpu to hit 100% after 50+ shots.

    Not looking for a concrete example, but anyone that can point me in the right direction would be much appreciated.

    Trying not to get too heavily into the math side of things, but I'm thinking custom movement and some trajectory equations might have to happen.

    Test:

    WASD = Move gun around

    R = reload

    X = clear all lines/magazines

    Left click = fire

    B= Enable blood

    https://dl.dropboxusercontent.com/u/14181859/bullet%20Test/index.html

    EDIT: Updated the example to adjust velocity and fixed it so no matter what angle you shoot it should go out the right side.

    Green = less than 50% the original speed

    Yellow = between 90-51% original speed

    Reload your cache or load it in a incognito tab to see changes.

    Still can't get the collision to work right on thin objects, but I am working on another prototype using custom movement and some trajectory formulas.

    Got it to be a little more accurate but not much.

  • If you are using the bullet behavior, there isn't much you can do. If you are using the physics behavior, perhaps setting the "bullet" property on the bullet sprite might improve things out. Although a quick test I did with the bullet sprite set to fired with an impulse of 1000, worked perfectly, without even having to set the bullet property to "yes". In fact I don't think that the physics behavior allow for that kind of high velocities. 1000 impulse has the same speed as 10000 or 100000000....

    Oh well...

  • If you are using the bullet behavior, there isn't much you can do. If you are using the physics behavior, perhaps setting the "bullet" property on the bullet sprite might improve things out. Although a quick test I did with the bullet sprite set to fired with an impulse of 1000, worked perfectly, without even having to set the bullet property to "yes". In fact I don't think that the physics behavior allow for that kind of high velocities. 1000 impulse has the same speed as 10000 or 100000000....

    Oh well...

    I have the physics property set to bullet and it still fails to register hits that fall out of the "step" range and increasing the stepping does nothing.

    What is odd is I am only applying an impulse of 0.6......

    I think I might just write a custom behavior to do a trajectory/ delayed hitscan and do away with the bullet all together.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Well look at the math. If an object is going faster than 60 pixels per second, and your solids are smaller than 60 pixels, then there's a high probability it can skip the object.

    You're just not going to get pixel perfect collisions in a javascript engine running v synced at 60 fps.... with crappy garbage collection.

  • Well look at the math. If an object is going faster than 60 pixels per second, and your solids are smaller than 60 pixels, then there's a high probability it can skip the object.

    You're just not going to get pixel perfect collisions in a javascript engine running v synced at 60 fps.... with crappy garbage collection.

    Makes sense. I guess I could try doing an invisible cage object that is much larger and then offset the impact point.

  • Well, physics collisions are accurate. The problem is with the normal collision/overlaping check. What would be nice is to have physics objects as detectors/triggers. That way we would have accurate detections either upon collisions, or while overlaps.

    I am not sure what is the purpose in your gameplay, if you are trying to simulate penetration damage. I did some checks and came up with a basic capx that does detect all collisions, perhaps it will be of some use to you. Perhaps not. Here it is never the less

  • Well then, why don't you check the distance between the objects and the bullet, if its smaller than the distance traveled by the bullet in a tick, then you could move the bullet by that distance in the angle of the bullet and check for collisions or use an invisible object to do the checking, if that object collides with the target then the bullet has hit it

  • Well, physics collisions are accurate. The problem is with the normal collision/overlaping check. What would be nice is to have physics objects as detectors/triggers. That way we would have accurate detections either upon collisions, or while overlaps.

    I am not sure what is the purpose in your gameplay, if you are trying to simulate penetration damage. I did some checks and came up with a basic capx that does detect all collisions, perhaps it will be of some use to you. Perhaps not. Here it is never the less

    Thanks for the example, but this is similar to what I was already doing. The problem is if you increase the impulse or make the board any thinner it will start to miss collisions.

    I ended up settling for an invisible cage around small objects that is much larger than the object itself, and then getting the distance and moving the impact point to the object. It works fine for what I wanted to do.

    There isn't really any gameplay purpose, just a prototype for ballistic behaviour that I wanted to mess around with. I'm going to put it aside for now and revisit it later after some other ideas.

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