Project Energia 5V Heavy Launch Vehicle

[Urwumpe]

I don't know what the function outputs when it gets (0,0,0), but other than that it should output an unit vector with the same direction as the input.

That is implementation dependent - In Orbiter and VC++ using IEEE floats, it is a NaN vector.

You can use both normalise() and unit(), they are technically the same function but have different ways to calculate the unit vector: normalise modifies the vector passed as argument, unit returns the unit vector for the input.

 

[N_Molson]

After a day of trial and error, messing with conditionals, I got it working ! A significant step forward !

I wired the logic so that you can have pitch and yaw together, but not roll, because while pitch and yaw use different sets of nozzles, roll use the 4 of them.

Now this is only for manual control and for the core booster. I still have to implement it for the strap on boosters, make the 5 boosters work together and code some kind of ascent program. But now I know I can do it !

Also I think, as Urwumpe wrote above, that those actuators can move much much faster, but I assigned a variable to the speed component set in the header file so it will be very easy to tune.

 

[N_Molson]

Now I'm stuck on another detail... As my nozzles rotate, so does their exhaust point. Problem is that particlestreams and exhaust get misaligned with the nozzle animation... Is there a way to update the particlestream or exhaust vector in preStep or postStep ? SetThrusterRef allows to move the thrusters attack point, but visuals don't reflect that change... Am I missing something ?

It seems to work nicely on stock Atlantis, and the gimbal range is greater than on my rocket... Any idea how Martins did that ?

 

[GLS]

Now I'm stuck on another detail... As my nozzles rotate, so does their exhaust point. Problem is that particlestreams and exhaust get misaligned... Is there a way to update the particlestream or exhaust vector in preStep or postStep ? SetThrusterRef allows to move the thrusters attack point, but visuals don't reflect that change... Am I missing something ?

More math?
You have to update the exhaust position when the nozzle gimbals. You can do the math yourself or use the ANIMATIONARRAY (or whatever it is called... sorry, I'm totally disconnected from the code for 2 months now ?) to "animate" vectors together with the mesh. Look at the RMS code and how it moves the attachment point.

 

[N_Molson]

My head is gonna blow... ?

But thanks, yes the RMS is a good example of hierarchy, will look into that.

 

[Urwumpe]

My head is gonna blow... ?

But thanks, yes the RMS is a good example of hierarchy, will look into that.

If you want to keep this simple, there is a function in the Orbiter API to to that for you, so you just need to tell Orbiter the distance between exhaust start and the thrust force reference.

 

[N_Molson]

If you want to keep this simple, there is a function in the Orbiter API to to that for you, so you just need to tell Orbiter the distance between exhaust start and the thrust force reference.

Do you remember which one ? Thanks a lot.

 

[Urwumpe]

Do you remember which one ? Thanks a lot.

One of the many versions of AddExhaust()

 

[N_Molson]

That one, I guess ?

 

[GLS]

I think that only works for the exhaust texture. The partice streams need to be manually moved.

 

[N_Molson]

Well I fear I'm going to have to move on, I can't find a way to move the source of a thruster ExhaustStream dynamically. I can move the logical thrusters using "SetThrusterRef", but particlestreams simply don't want to "follow" and stay in the initial position. So I'll do the maths to have the thrusters attack point match with the animations.

If someone can find a code example of an ExhaustStream moving dynamically, I'm interested of course.

I looked at the Atlantis RMS arm code, but its like searching a needle in a haystack...

 

[GLS]

Like I said above, look for the ARRAYSOMETHING (it's all caps) in the animation definitions. That's a feature of Orbiter where you can "animate" a vector. In the RMS it is used to move the attachment parameters, but the idea is the same: you have the nozzle mesh rotating about a point, and with this feature you can have the initial (no gimbal) particle stream position and direction vectors rotating about the same point. All you have to do is declare this special "animation", (maybe) handle the rotation offset math (if so, it's just addition and subtraction) and the vectors will automatically be updated by Orbiter when the animation runs, so you just have to update the particle stream position and direction in one of the timestep callbacks.

The alternative is you do the rotation of the particle stream vectors by had, which isn't super hard.

 

[N_Molson]

OK I think I found it in Atlantis code :

    rms_anim[5] = new MGROUP_ROTATE (LOCALVERTEXLIST, MAKEGROUPARRAY(arm_tip), 3,
        _V(-2.26,1.7,-6.5), _V(0,0,1), (float)(894*RAD)); // -447 .. +447
    anim_arm_wr = CreateAnimation (0.5);
    hAC_arm = AddAnimationComponent (anim_arm_wr, 0, 1, rms_anim[5], parent);

In OrbiterAPI.h they say :

#define MAKEGROUPARRAY(x) ((UINT*)x) ///< casts a vertex array into a group

I have no idea what is a "vertex array", how you define it and how to wire that into my thruster problem...

 

[Urwumpe]

OK I think I found it in Atlantis code :

    rms_anim[5] = new MGROUP_ROTATE (LOCALVERTEXLIST, MAKEGROUPARRAY(arm_tip), 3,
        _V(-2.26,1.7,-6.5), _V(0,0,1), (float)(894*RAD)); // -447 .. +447
    anim_arm_wr = CreateAnimation (0.5);
    hAC_arm = AddAnimationComponent (anim_arm_wr, 0, 1, rms_anim[5], parent);

In OrbiterAPI.h they say :



I have no idea what is a "vertex array", how you define it and how to wire that into my thruster problem...

A vertex is just a VECTOR3 describing a point in a graph, and a vertex array is thus, just an array of VECTOR3 elements.

You can use vertexes as unconnected point cloud or treat them as if they are connected in some way - just like the RMS code does in treating the 3 points as end points and origin of a cartesian coordinate system.

 

[N_Molson]

OK so what it does is defining a triangle (3 points) in 3D space... So I can take 3 points on my nozzle exit rim, that should be ok, right ?

Also I think I have the same of misunderstanding about ParticleStreams that another orbinaut back in 2015 :

General Question - moving exhuaust streams

I have added a exhaust stream to the tower. No problem. But because this exhaust stream needs to match the animation that is a problem. I added an attachment to see if the values of the location changed and they do. But the exhaust remain at the starting point. vapourlocation[0] =...

www.orbiter-forum.com

Honestly, those concepts are not the most intuitive ever...

 

[Urwumpe]

Well, what you really need is two vertices for your animation per chamber. One point defines the place, where the exhaust stream starts. The other point defines the direction of the exhaust relative to the first point.

 

[N_Molson]

OK so how should I define "LOCALVERTEXLIST" into an array ? More a C++ langage thing I think... I can't find where Martins did that in Atlantis, its not in the .cpp or the .h ...

Would something like that work ?

#define LOCALVERTEXLIST[3] = {_V(0,0,1);_V(0,0,2);_V(0,0,3)};

No, MGROUP_ROTATE don't like it and "expects an identifier"... Usually the input here is a meshgroup index integer like 0, 1, 2, 3...

Meanwhile, I modified the boosters in order to make the nozzles movable parts, like the core. Next step will be to implement animations and basic manual control and make all boosters work together.

 

[Urwumpe]

Try it with

VECTOR3 nozzle_vtx[8] ;

for example, and use nozzle_vtx, nozzle_vtx + 2, nozzle_vtx + 4, etc for addressing the right pair of vertices for each nozzle.

Remember, an array in C++ is represented by a pointer to it. The definition only reserves the heap or stack memory, but the nozzle_vtx is syntactically just a normal pointer to a typed variable.

 

[N_Molson]

I can see that other people had issues trying to move particle exhaust streams dynamically.

API Question - Non-thruster related particle effects (explosions and the like)

I'm already familiar with using dummy-thrusters + exhaust streams to model venting, contrails, and the like but could someone explain how I would go about modeling more transitory effects such as a fireball from a crash or catastrophic failure, the burst of debris from staging, or the shock...

www.orbiter-forum.com

 

[N_Molson]

If someone managed to do it, I'd like to know, if its an Orbiter bug I don't want to chase a wild goose...

Cleaned the code : instead of dummy thrusters to get manual pitch/yaw/roll input, I now use the dedicated SDK function (GetManualControlLevel). ?

I plan to use the dummy thrusters for core to boosters communications.