Recent Blogs Posts

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)

1. Replace slidenode code with outside drive-train code - Completed
2. Refactor current wheel calculation - in progress
3. Rewrite current drive-train to make use of new code
4. 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.

Since I've been doing some coding I thought I'd share what I'm working on. First and foremost my goal right now is to rework the drive-train code, this includes the tires. But I am sort of taking a round about approach to this which includes some pretty heavy refactoring. I've written a lot of concept code in the past for a new drive-train but never put it to use. I also wrote it in a reusable manner and am expanding this design.

History
The drive-train code I did write works on it's own, it just needed to be integrated into RoR. The new drive train code is built on the same principle as RoR, nodes and beams. Instead of nodes and beam in a 3 dimensional space we have nodes and beams in a 1 dimensional space. replace position with angle, velocity with moment, and force with torque and you have the same equations. This is where I started.

So I am basically building a parallel "world" for the drive train that works similar to nodes and beams. My starting point was going to be the wheels, since they essentially act like the gate way between the node/beam world and the drive-train world. My approach here is to simulate a drive-train wheel object which is nothing more than an an angle, then calculate where the nodes should be positioned based on that angle. While I was working on this, I realized that this is drive-train same concept I'm using for slide nodes: calculate where a node should be, calculate beam-like forces from where the node is, and where the node should be and distribute forces appropriately. So I started hacking away at some concept that I could use for both when I dawned on me that I had already written this code a long time ago for the drive train.

Theory
So here is a bit about my theory behind the drive-train code, and what will most likely be used in many many more places than the drive-train. As I've worked in the BeamForcesEuler routine I've realized that it boils down to two actions, updating the forces that act on a node, and updating the nodes position. I call them sources, and sinks; sources generate/calculate the forces based on the environment and are applied to the sinks, the sinks take the forces and decide what to do with them. In RoR terms sources are beams, engine, wings, commands, collisions, etc, etc, and sinks are nodes.

One of the cool ideas I will be able to introduce with this new idea is per-node integrators, I feel this will be handy because some weight/spring combinations are not stable but would be if a different integration method is used.

Way Forward (aka the plan)

1. Replace slidenode code with outside drive-train code
2. Refactor current wheel calculation
3. Rewrite current drive-train to make use of new code
4. Add new drive train features

Replace slidenode code with outside drive-train code
I'm doing this first because it's an existing system so I will be able to just test out the new code against existing slide node behavior to tell if it is working. This will be the biggest change all other items will make use of the concepts implemented here.

Refactoring this code will also have the added benefit of slide node damping since it's already built into the code I will be integrating.

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.

Rewrite current drive-train to make use of new code
Make sure the current drive train code works and behaves as is with the new wheel model, and make use of new code to perform drive train calculations. The current code is a bit of a mess and there is a bug where the first two axles are locked together but none others, this should solve that problem.

Add new drive train features
Multiple engines, torque converters, clutches, lockers, limited slip, multiple gear boxes, transfer-case, brakes, etc

My goal here is to model any and all kinds of different power, be it a traditional engine and 4 wheels, a parallel hybrid with two different engine types, or a helicopter with one engine powering two different rotors. Or who knows what. I want to flip over a car, spin one wheel with the mouse and watch the other wheel spin in the opposite direction when using an open diff. the best part IMO is that I've already got some of this working. I've test locked, open, and LS diffs. I've tested with one power source, and I've tested with two power sources.

And Beyond!
I plan on using this framework throughout RoR, hoping to achieve better performance, multiprocessor support, more organized, and easier to alter.

I'm excited

My work and progress is viewable here: http://sourceforge.net/u/aperion/rig...0fd7a443/tree/
What I will be using for much of my refactoring is here: http://sourceforge.net/u/aperion/rig...ics/framework/

I have made a (soft release) of the crane.
Just to have you "feel it" and tell me your thoughts.

Look here: BBD-LTM-11200-9-2/page6

Attached Thumbnails

 

need i say much. 3x mobile platforms, 1x 330,000kg load, over rough terrain, this is heavy hauling at its best.

Here is a small video introducing the Bombardier ALP 45-DP locomotive I build for RoR. Still not finished, things might change for the final release. So far featuring animated cab view, wipers, fans and other things. Sounds are being reworked, still have to change and add some more.



And I did a quite nice render of it in blender, maybe you like it



Suggestions and comments welcome

drew this image in order to visualize the chaotic String conversions happening in the code.

Attached Thumbnails

 

so, there is ANSI, WideChar and UTF8 we deal with in RoR atm.

ANSI is used for raw data which comes from some sort of input. UTF-8 is used throughout RoR and for the network code. WideChar (std::wstring) is only used as bridge between ANSI and UTF-8 atm, also most system string operations use wchar_t.

_L() is a UTF-8 encoded UTFString, if we assume the .po file used was using utf8 as well.

L() is a wide char string, which needs to be converted to UTF-8 before we can combine it with other strings: UTFString(L("foobar")), the short form we invented is U("foobar")

UTFString(String("foobar") will not work as the UTFString will assume UTF-8 encoding of the input string. So we need to take a little way around:

ANSI_TO_UTF(String("foobar")) which will convert any ANSI encoded strings into our beloved UTF-8 strings

the problem is now if we hit such code:

Code:

char tmp[128]="";
std::string format = _L("Position: %0.6f s, frame %i / %i");
sprintf(tmp, format.c_str(), ((float)t)/1000000.0f, curOffset, numFrames);
txt->setCaption(String(tmp));

it will break as the format String will be in UTF-8 format if higher characters are used. so we need the wide-char sprintf version:

Code:

wchar_t tmp[128] = L"";
unsigned long t = curFrameTime;
UTFString format = _L("Position: %0.6f s, frame %i / %i");
swprintf(tmp, format.asWStr_c_str(), ((float)t)/1000000.0f, curOffset, numFrames);
txt->setCaption(convertToMyGUIString(tmp, 128));

certainly does not help with readability :|

also, to make the confusion even better, some Parts of Ogre do not understand UTFString, so you get broken info there... :|

so much chaos in the code ... :|

i'm working on a dashboard editor that should allow users to create their own GUIs for RoR

on top are the debug controls, where you can test if the gauges at the bottom are set-up correctly. WIP.



little preview video: http://modclub.rigsofrods.com/thomas/guitest2.html