Let’s start to tell that I’m a complete and utter n00b in game development, while having many years of professional software engineering experience. For a project that I’m likely going to do, I think we can use Panda3D, but I like to be sure before I put too much time in research.
Our situation can be described as follows:
It will not really be a game, but it is more like a research project where we would like to visualize our acceleration / collision problem.
What we like to do is to model a simple (but variable) path as an input; let’s see it as a track with a 3D (smooth) path, like a roller-coaster.
We put a car on the beginning of the track so it can slide along it.
Now the questions:
it is possible to tell the physics engine to ‘push’ the car, so that it automagically follows the center of the track, exactly following the 3D path, even altering its 3D orientation to follow the track’s curves? (think about a roller-coaster loop, in which case the car will be flipped completely)
can you implement an action in every frame / each time the car moved a fixed distance, so that speed, acceleration / wobble / etc. of the car can be monitored?
if the car should touch any other object along the path, is it possible to log those positions of the car on which this happens, without influencing its speed and position?
Thanks for reading, and hopefully answering, the question.
I may be missing some complexity or difficulty, but that seems very feasible. Getting values at each interval of a fixed distance might be a little tricker – perhaps you might use the average velocity over the frame to calculate the point at which the car reaches the end of the interval (and appropriate physical values), and repeat as called for.
If I understand what you say, then it is tricky to get the exact location and orientation at a constant rate, but it is easier to retrieve the car’s (average) velocity? (in 3D I hope, so we can also see the ‘wobble’)
Sampling position and velocity is not a problem. But how to depends on what you mean when you say “constant rate”.
Rate usually referrs to time, i. e. get the values every X milliseconds. You need to know that you can querry an objects position only at the end of a simulation step, so the size of simulation steps is crucial. The most simple usage is to advance the simulation time each render frame, by the elpsed time since the last frame.
–> If your sample rate is small compared to the stepsize then you can simply read the pos/velocity once the simuation time has elapsed a sample threshold.
–> If it has equal magnitude then you need to decouple the simulation stepping (advancing the simulation time) from the rendering, which is not a big deal either. Of course smaller timesteps mean more CPU time, and thus the hardware is the limiting factor for precision.
If rate refers to distance then you can place trigger objects along your track. The triggers can send an event if your car passes through the trigger, and you can read the pos/velocity upon notification.
What I am more concerned about is how you want to make the car follow the track, how you want to prevent it from bouncing off the track, and how you want to drive the car (or is initial momentum and gravity enough?)…
So you can define the time between frames yourself, and with that you can slow down, (or reverse ) the simulation?
Rate would indeed refer to track-distance indeed. The usage of trigger objects sounds simple and feasible enough, thanks.
The car should automatically follow the track, exactly as a roller-coaster car would. Initial momentum (or a constant force, whichever is easier) is enough indeed. Is it easy to make the car ‘hold on to’ the track while it’s being pushed?
Nothing highly complex, right. But each trigger is an object, and too many objects kill performance. Finding the right balance is part of the art.
I think it is not easy. A real roller-coaster has two rows of wheels, one above and one below a tube-shaped rail. Much depends on the tiny contact area between the rails and the wheels.
Attempting to do exactly the same with a game physics engine is probably very slow and inaccurate. I’m not sure what the best approach is. Maybe a custom constraint. Maybe it is sufficient to implement the dynamics directly in Python.
Hmmm… if I understand the video right then this guy is not using any physics at all. He just creates a bezier curve in blender and animates (keyframes…) the movement of the car (box) along the curve. That is, he defines by hand how fast the car moves in different parts of the track. Panda3D can do this too - the keyword is “motion path”.
While it may be expensive, if you wanted a simulation that was geared more towards testing the physics of track layouts instead of trying to animate a coaster you could probably attach 3 collision rays shooting downwards from the vehicle- two on each of the front corners and 1 in the center of the back side. These can act as sensors to see if the car is on the track. Using this setup you could see if the coaster is turning (using the front two rays) or changing its pitch (using the average z position of the front 2 rays and the z position of the back ray). Based on the information you receive you can adjust the HPR of the car accordingly. Hopefully that helps you out with your first question.
Once you know the car’s angle, you can then create a basic formula that adjusts the speed of the car. the CollisionHandlerGravity class may help you here.
For your second question, if you use tasks you can monitor the movement because those activate each frame. .getPos will tell you the location of your car each frame if it’s within the task, and if you want you can use it and some pretty simple calculations to get the speed and acceleration. To be honest, I don’t know what wobble is so I wouldn’t know about that.
For question 3, yes you can and it’s pretty simple once you know how to use collision surfaces. There’s a series of very useful tutorials in this thread (Panda3d Collisions made simple) that’ll help you with everything gravity and collision related if you need it. Good luck!
) the simulation?
He defines all the movement on forehand.