In addition to GGulati's explanation, you can represent (logically, or in your code) the helicopter cockpit and its rotor(s) as a transform hierarchy of the transforms he describes. Your rotors will be spinning in a certain direction, and at a certain speed that should not affect the helicopter cockpit at all. However, the rotor positions in world space have to be rigid to the cockpit, e.g. the helicopter goes up, the rotors spin but are translated up accordingly. Each piece, therefore, maintains its own "local" transform - the cockpit probably is centered at the origin, but the main rotor is translated some units up the y-axis and so on. Then when you're updating the scene, you combine these local transforms into a final world transform for each piece of geometry.

For example, from my own code organization:

1. Each geometry has a local/world Transform, where a Transform is comprised of a Vector3 for Scale, a Quaternion for Rotation, and a Vector3 for Translation. You can of course use a rotation matrix rather than a quaternion, or keep three matrices for each component - but I tend to shy away from matrices.

2. The scene is organized with parent-child relationships. So the cockpit would be a parent, and the two rotors would be children (they have a reference to their parent and vice versa).

3. Every Update() call on the scene, each child combines their local transform with their parent's world transform:

Cockpit - No parent, simply uses its local Transform as its world transform.

Rotors - Parent is the cockpit, so their locals are combined with the cockpit's world transform.

The actual combination code looks something like this:



private Vector3 _scale;
private Quaterion _rotation;
private Vector3 _translation;
private bool _cacheRefresh;
private Matrix _cachedMatrix;

...

//Combines the components into a matrix
public Matrix Matrix {
get {
if(_cacheRefresh) {
Matrix scaleM;
Matrix rotationM;
Matrix translationM;

Matrix.FromScale(ref _scale, out scaleM);
Matrix.FromQuaternion(ref _rotation, out rotationM);
Matrix.FromTranslation(ref _translation, out translationM);

_cachedMatrix = scaleM * rotationM * translationM;
_cacheRefresh = false;
}

return _cachedMatrix;
}
}

public void CombineWithParent(Transform parent) {
//Multiply scaling
Vector3.Multiply(ref parent._scale, ref _scale, out _scale);

//Multiply rotation
Quaternion.Multiply(ref parent._rotation, ref _rotation, out _rotation);

//Combine translation
Vector3.Multiply(ref _translation, ref parent._scale, out _translation);
Vector3.Transform(ref _translation, ref parent._rotation, out _translation);
Vector3.Add(ref _translation, ref parent._translation, out _translation);

_cacheRefresh = true;
}


The (world) transform class I use has a matrix property which would then be used in with your view/projection matrices when setting the world-view-projection to the effect you're using. I cache that matrix too, so it's only computed once unless if any of the individual components change. Likewise, my scene management only updates world transforms if a scene object's transform has changed to reduce redundant computations. For example, the cockpit's transform may not change, but the rotor's rotation will, so only the world matrix is recomputed for the rotor and not for the cockpit. If the cockpit's transform changed, both would need to be updated. (Basically update any scene object, and any other objects it would influence - so children).

I mention this because your DrawRotor() could be made a lot simpler where each geometry has its own transforms, that get compiled to a world matrix in some general function like I posted above, making it easy to add new objects to Render, since you may only need to change a few transform properties without having to re-write the same sort of code. Also, you can reduce computations for parts of your models that don't actually move in a frame.