Where a guide line displays where your cue ball is going to go and the angle at which it will deflect, a circle shows where the impact will take place, and an additional guide line shows the angle at which any balls you collide with will bounce.
I have the guide line pointing straight out from the cue ball, that was easy, but finding the position of the guide circle, where the impact occurs, is far trickier than I had thought. Once I have the position of impact, ie where the guide circle goes, calculating the rest will be easy. So that’s what I need help with most.
I’ve tried casting multiple rays to predict the point of impact but it was excessive and inaccurate.
I tried using a Guide Ball, a sphere collider I translate forward from the cue ball, which reports it’s position once it’s collided with something, then returns back to the position of the cue ball and translates forward again to update this collision point. This method would work great if it weren’t for one major problem.
In order to update the guide circle’s position often enough to get smooth movement for the guide circle, I need to translate the guide ball forward very often, constantly looping and casting it forward at high-speeds. This is causing the guide ball to move so fast that it often passes straight through objects, and in general at high speeds it reports inaccurate values.
What I’m thinking of doing now is instead of casting one guide ball forward super-fast, I’ll caste multiple guide balls all in a row forward at a more modest speed, so I’ll still get an OK update interval without high-speed causing inaccuracies.
I would expect so, and in any case you probably don’t want to use rigid bodies for a pool simulation. Unity’s collision code is nowhere near accurate enough - like most modern physics engines, it leaks a lot of energy, and is more concerned with resolving collisions than conservation of energy and momentum.
Yeah I’ve learned that the hard way through-out development, the major problem I had with PhysX is the velocity of a ball seems to change the bounce angle, which I assume is a desired effect but in pool games it’s more of a nuisance.
Uhm I don’t think is incorrect per se.
The faster a ball is, the less it will change it’s trajectory when it hit another ball, so, the angles, definitely changes with speed.
The problem I would anticipate would be that collisions in game physics engines tend to be rather inelastic - they lose a lot of energy in uncontrollable ways. You will also have difficulty getting emergent concepts like swerve, backspin, etc to behave realistically - the physics engines are developed with the wrong priorities in mind.
My understanding is that sphere-cast will simply tell you what’s nearby, while sweep test will in effect simulate moving the ball and give you precise collision info.
While I do agree physx is probably not a great engine for pool simulation - you can turn on CCD/increase accuracy and muck around with bounciness, friction etc. It’s entirely possible that it’s more than sufficient for fun game-play.
Ah yes ok I understand what you’re saying, so sphere cast acts more like a radar than a directional ray?
I have done exactly that and the movement of the balls is fun and visually accurate, what I’ve noticed about most web and mobile pool games is they decrease the friction/mass of the balls and increase the bounciness, so you get a more fun type of gameplay with less high-speed collisions. Which is the method I intend to move forward with, but was I starting over I would create my own pseudo-physics system to allow for better control over the trajectory of the balls.
Thank you very much to everyone who’s commented, you’ve all been extremely helpful!
SphereCast is just like a fat ray. It will tell you the distance you could move the sphere before it would collide with something. I tried it out at the time - you can see the result here:
The ball in the middle is the cue ball, and as you move the mouse around one of the other balls will show the position the cue ball would reach before colliding with another ball. Here’s the code:
public class CueBall : MonoBehaviour
{
public Transform childTransform;
void Update()
{
var mousePosition = GameObject.Find("Main Camera").camera.ScreenToWorldPoint(Input.mousePosition);
mousePosition.y = transform.position.y;
var direction = (mousePosition - transform.position).normalized;
RaycastHit hitInfo;
if (Physics.SphereCast(transform.position, transform.localScale.x/2, direction, out hitInfo, 10.0f, 1<<8))
{
childTransform.position = transform.position + direction * hitInfo.distance;
}
}
}
