|
|
|
|
Reply From: |
dc1a0 |
Problems of this type are generally that the fast moving object skips over the collision area. Ways to fix this are:
Make your walls thicker than the distance the moving object will travel in a single frame
Use a raycast to detect when the moving object is close
Use an invisible area to expand the collision checking area.
Thank you for your suggestions. It might be however difficult to implement them.
About thickness of the walls, I’m afraid I don’t have such thing. I have meshes that represent rooms, and walls are the faces of the room. Their thickness is therefore unlimited. It is not like gtkradiant, which have thickness for every wall.
About raycast, I prefer to avoid extra complexity in the node because it’s a bullet and there can be lot of them and it must be performant. And I’m not sure how to implement that since I don’t know where to point the raycast. Rigidbodies rotate in every direction.
And what do you mean for an invisible area? That’s what I use for standard bullets because they must be destroyed when they hit a wall. But a grenade must bounce against the wall.
Gokudomatic2 | 2016-04-09 18:21
For raycast, you could have them point from the grenade, in the direction it’s heading, for the invisible area, you could either have it on the grenade to expand it’s collision area and act like a raycast, or you could attach it to the wall and expand the wall’s collision area.
in all cases, if the closest object or wall, (depending how you decided to set it up) is closer than the grenade will move next frame. you can tell it to only move that distance to make it look like it hit the wall (and then explode or bounce or whatever else you want.)
I’m not sure to understand what you mean. I’m not implementing anything in my grenade. There are no custom integrator, no script. The physics engine does all the work.
Gokudomatic2 | 2016-04-09 18:47
It’s been my experience that the physics engine won’t be able to do all of it. for example, the physics engine can’t reliably tell it when to explode. Ranging from the issue you’re having, to not telling the grenade to explode 60 times. In the end, it will likely need to have some code. So may need code to decide what happens when it gets close, but not close enough as well.
In the meantime, you could also add the code to an invisible area for the walls, that tell objects that are close to them how to behave.
Sure I manage in a script somewhere when the grenade must explode. But about the movement of the body, I want to use the standard behavior of the physics engine. After all it’s his job.
Gokudomatic2 | 2016-04-09 19:00
It’s the physics engine’s job to handle objects, not YOUR objects, there’s a difference. From my experience, It’s generalized so that it can be customized to do the specific things someone wants it to do. That’s why GDscript has bindings to access physics engine functions. Out of the box it’s designed to handle most general tasks capably, not everything specifically. That’s where you step in to provide the specifics.
Alright. Thanks for the explanation.
It’s still hard for me to believe I have to manage myself a round object simply falling on the ground, rolling on a slop and bouncing against a wall, only because it’s going too fast at the beginning. But if it’s a limitation of the physics engine, there’s no way around.
Gokudomatic2 | 2016-04-09 20:12
Think about it, from my understanding so far, your wall is only something like 1 pixel thick. if the grenade is moving farther per fame than the size of the grenade, when is the grenade supposed to record the collision, given that according to the computer they never overlap?
Indeed. That’s pretty much the cause of the problem. I was looking for a way to change the number of calculated frames per second to have a better precision.
Gokudomatic2 | 2016-04-09 20:27
well, changing the calculated frames, per second wouldn’t do much good given that your grenade would still be moving too far per frame as it is now. You possibly could raise the physics fps, but then you’d have to raise the idle fps as well so it didn’t go out of sync when you slowed down the grenade. There’s also another setting that can increase or decrease the calculations, but I’m not certain I understand that one very well to know if it’d be useful in your situation. Much less give any guidance on it.
That’s why I suggested increasing either the detection area for the grenade or the wall to compensate for close in a manner you could control it in a way you could make it look perfect to players who wouldn’t need to know better.