It’s been a while since I’ve used it and not at my computer but would the projectile component solve this? From what I understand it uses raycasts in between each step so it can handle very fast moving small objects (like bullets), can calculate bounce, gravity, and maybe air friction (can’t remember if that was default or I added it in).
The only downside from what I remember is you need a simple collision shape as it’s base (sphere/capsule/etc)
I gave that a go and it seems you can’t get good physics simulations (the coin won’t rotate while falling) while using this unless you enable “Simulate Physics”, which puts us back to square one. Unless I missed something.
Is it important that the physics is fully simulated? You just add some rotational force to it and fake it
this may seem simple, but can you increase the x/y collision box it self to a larger #?
My issue is the coin will fall and just stand up on its side without falling over like a real coin would, if I could fix that, id call it good enough. How do I go about adding rotational force?
Don’t know if this would strictly work, but worth a try, projectile component needs simple collision.
Have the coin as a child, add rotation to the coin when it bounces or in flight (just go with what feels good), when the component detects it’s below a velocity threshold on the last bounce get the hit location and normal, set the coin to that location and use the normal of the hit to determine the final rotation of the coin.
I found that enabling CCD within a blueprint didn’t work. It helped slightly but not much. HOWEVER, enabling CCD on the mesh’s actual physics asset. THIS FIXED IT COMPLETELY.
For me, this let me drop a small object from 250 meters up onto landscape terrain without ever falling through. Before I had CCD from within a blueprint, and it didn’t even fix it for 20 meters.
Enable it on the actual physics asset and it seems to work.
Its not about “how high”, its about velocity.
How fast is the object traveling, and is it possible for the 2 collisions to missmatch or not.
Meaning if you start from 150m high, and your speed is a constant 1200m/s in the 60fps it takes to fill up a second your object is very likely to miss the landscape completely - depending on the size of the landscape collision.
1200/60 = 20m increments per frame.
Impact should occur around 150/20 = 7.5 frames.
Note the .5.
If your terrain collision doesn’t cover at least 10m the chance the object will miss is actually 100% in this “math only” scenario…
Obviously substeps would make the hit in this hypothetical much more possible to begin with (re-do the math with the correct frame count).
Either way, the above describes the base problem with any physics simuation.
Steps taken to overcome the problem can vary wildly.
For instance, you could make the projectile collision 21m long so that each frame the whole thing is checked against the whole area - dub this the TravelSpeed+1 approach.
For non projectiles, youd have to specifically stretch the collision in the vector direction of speed as well, or else rotated items woud flag hits on things that arent necessarily even close to their trajectory.
Another approach is to use a line trace in the direction of travel which stops ahead of the object by hlaf the speed/frame value (gets you if the hit is the next frame).
Theres probably 1001 creative solutions that would all be equally effective - yet not require the overhead of sub steps, or ccd, or whatever else…