I’m using ProjectileIntervals to throw a ball from the current position of the camera. Later on, the balls need to collide with collision nodes that surround the surface of models.
I’ve setup all this, and when I run my game in my machine, that has a nVidia 7900 gs, I get around 400 fps, and the collisions work perfectly. When I test the same game in a slower machine (one with a nVidia 6600), where I get around 100 fps, or when I test the game in my same machine (the one with the 7900gs), but with vsync turned on (what causes me to get a maximum of 60 fps), the collisions sometimes don’t work.
When I say that collisions don’t work I mean something like the following scenario. Imagine that you have a sphere model, completely surrounded by collision nodes around its surface. If I throw a ball, in the case were the fps is 400, the collisions are correctly detected against the sphere’s collision nodes that are closest to the ball. When I test the same thing, but with the lower fps, collisions occur in nodes that are behind the ones where collisions actually should have been detected.
I’m guessing that it has to do with the fact that the balls are moving too fast, so when the framerate drops, collisions don’t get detected all the way through the projectile interval. I’ve read that this can be fixed, by giving an empty collision node to the ProjectileInterval constructor, so that internally the interval creates a collision parabola.
Yesterday I tested this, but I keep getting the same results as when not using the parabola.
What I can do to fix this?
Thanks for the link!
I’ve already read it, and I thought about using object.setFluidPos(newPos), but somewhere I saw that actually thats the default behavior used by ProjectileIntervals.
It seems that base.cTrav.setRespectPrevTransform(True), might work, but the caveat at the bottom of the page states that this will only work in situations where the “from” object is a collision sphere and the “into” object is a collision polygon. I’m using collisions spheres for both “from” and “into” objects.
I guess I’ll have to start using collision polygons for my “into” objects. Is there any other solution? Shouldn’t the empty collNode given to the ProjectileInterval be enough? (Maybe I’m doing something wrong while setting it up).
The empty collNode given to ProjectileInterval should be enough. For the record, we added this solution specifically to solve the same problem in Pirates of the Caribbean Online, and it still works well for us.
Great! I’ll keep experimenting with it and I’ll post the code I’m using if I can’t make it work.
One question though. If I create an empty collision node and give it to my ProjectileInterval, internally a collision parabola will be created, right? But what about if in my collisions I want to consider the ball size (or in your case your cannonball size)?
I want that collisions be detected between the ball and one or more of the collision nodes attached to the surface of the model against which I’m checking, depending on the ball’s size. If the ball’s size is bigger, I want that my ball collides with more collision nodes at the same time, than if the ball’s size is very small.
How can I achieve this?
You might have to write your own variation on CollisionParabola to achieve this.
Failing that, you could simulate it by creating bigger (invisible) target geometry when you are using a bigger ball. It amounts to the same thing.
Alternatively what about that with every ball I throw, I create various ProjectileIntervals with their corresponding collNodes?
I mean, I would create a ProjectileInterval that starts at the center of the shot, and around it, a varying amount of ProjectileIntervals at different offsets, both depending on the ball’s size?
You could do that too. It would be a bit more expensive, though.