This is a follow up post to my previous one about refactoring and my plan forward.
I have completed the first item in my list
Way Forward (aka the plan)
- Replace slidenode code with outside drive-train code - Completed
- Refactor current wheel calculation - in progress
- Rewrite current drive-train to make use of new code
- Add new drive train features
Here is what I wrote about the next step here:
Refactor current wheel calculation
Current wheels aren't very reliable, we average the speed of each node to calculate the rotation of the wheel, this is subject to fluctuation. Instead I will have one object that represents the wheel as a whole, it acts more like a traditional tire model in a game where it's simply a cylinder. This is very similar to slidenodes is that there is an ideal state, and a state the wheels actually are at.
I'm expecting this to help solve a few issues RoR currently faces such as vehicles slipping down a slop when they should be braked. Also under this approach folding wheels should be a thing of the past.
I am kind of gathering my thoughts on how to approach this step, and how to explain it. There are essentially two "worlds" I'll be dealing with, a beam world and a drive-train world. the beam world is the one we are familiar with, point masses held together by springs in a 3D space. The drive-train world is made of point masses held together by springs in a 1D space. So where nodes have an [x,y,z] coordinates drive-train components simply have an angle. Essentially the drive-train world is the beam world with different dimensions and units.
So what the next step needs is translating from 1D to 3D and back. The angle in the drivetrain world will correspond to the angle offset each node is from it's original position, the hard part is how do you account for the wheel being at any odd angle? Possibly even upside down. Come to think of it, I remember now what my solution was, this is actually why I write these posts, to help me think.
What we know is each nodes initial starting position and the current position of the axle nodes and each wheel node. If we find the rotation required to translate the axle to it's original postion we can then apply that transformation to the current wheel node position. Then use the translated current wheel node position, the center axle and the initial node position we can calculate the current angle difference from the initial position. This can then be used to calculate difference between where the node is supposed to be based on the drive-train world, and where it actually is.
I did write a tiny program just to test this out:
Code:
#include <iostream>
#include <OGRE/Ogre.h>
int main()
{
Ogre::Vector3 pn1(1, 0, 0);
Ogre::Vector3 pn3(1, 0, 1);
Ogre::Vector3 n2(0, 0, 0);
Ogre::Vector3 n1(0, 1, 0);
Ogre::Vector3 n3(-1, 1, 1);
Ogre::Quaternion rot;
// move nodes to origin...
n1 -= n2;
n3 -= n2;
// get rotation
rot = n1.getRotationTo(pn1.normalisedCopy());
// move spoke to origin for rotation
n3 -= n1;
n3 = rot * n3;
std::cout << Ogre::Degree((pn3 - pn1).angleBetween(n3));
return 0;
}
We'll see how logn this takes to get done. night night.
Recent Comments
Gold
Silver
Bronze
