Project B-58A Hustler Development

[Urwumpe]

O-F Staff note: Thread splitted from Gaming: Digital Combat Simulation thread

Okay. You know all about that area. I'll give the mesh a go, then. Fingers crossed regarding the results!

If you want to start slowly, a placeholder mesh of it would already be great to avoid programmer art. :lol:

My idea would be starting at the J79 jet engine simulation model, so having a simple B-58 (wind tunnel quality) model to test the simulation for stability and performance would be great.

If you need references, there is a 1:15 wind tunnel model described on NTRS from NACA... including the aerodynamic properties.

...

Also, like so many things of the early cold war, it is interesting what you can find if you just click on links for a while...

[ame="http://en.wikipedia.org/wiki/High_Virgo"]High Virgo - Wikipedia, the free encyclopedia[/ame]

One of the first ASAT tests done with a B-58... it sure does fit well into Orbiter. :lol:

Its a bit hard to find more on the B-58, the biggest book on it seems to have just 64 pages. (Except the flight manual... not sure if I can get my hands on the supplements outside the USA)

---------- Post added at 01:14 PM ---------- Previous post was at 09:09 AM ----------

After thinking more about it during the lunch break, I came to the conclusion that I actually can do the plain engine modelling easier...

The NF-104A used a very similar J79-GE engine as the B-58, so I could simply use this for developing a suitable engine simulation model and maybe contribute the changes back to Sputnik.

And one more question: B-58A with ejection seats or the later modification B-58A with ejection capsules? If the capsules, I would really need to invest some money for a newer flight manual.

 

[Quick_Nick]

 

[Urwumpe]

Also, according to the NACA wind tunnel tests, the engines are hanging at slightly different angles inboard and outboard.

 

[ex-orbinaut]

If you want to start slowly, a placeholder mesh of it would already be great to avoid programmer art. :lol:

My idea would be starting at the J79 jet engine simulation model, so having a simple B-58 (wind tunnel quality) model to test the simulation for stability and performance would be great.

So, does this mean there is some priority on getting a good cockpit(s) mesh out above all else? That meaning; I am assuming a full working gauge and switch cockpit for the engines "player interface" will be a priority, if you want to start with the engines. I might have misinterpreted that, so please correct me if I am wrong.

Regarding the rest of the meshes; I am somewhat familiar (if a bit rusty) with Orbiter API / SDK, to the extent that I can "create" the model with consideration towards the required animations (mesh groups, IIRC), and knock out a working mockup of the code for it which can then be hooked out / hacked / modified for the respective aircraft systems' bindings, as required. I would, of course, limit my coding to that. The model I will post on a cloud link of some sort or another, for access, scrutiny, and suggestions for improvements.

If you need references, there is a 1:15 wind tunnel model described on NTRS from NACA... including the aerodynamic properties.

I have only had the opportunity for a cursory search for this, so far, and have not found it yet. Have you a reference number for the tech-report? It is well past midnight and I only just got back home as I write this, so I will resume the search tomorrow, when able.

Also, like so many things of the early cold war, it is interesting what you can find if you just click on links for a while...

High Virgo - Wikipedia, the free encyclopedia

One of the first ASAT tests done with a B-58... it sure does fit well into Orbiter. :lol:

So. It already has a place in Probe-dom. Its continuing role as a sinister villain suits it well! :lol:

Its a bit hard to find more on the B-58, the biggest book on it seems to have just 64 pages. (Except the flight manual... not sure if I can get my hands on the supplements outside the USA)

I think the Flight Manual I located and downloaded just now is the same one you have. Ie; missing the all important performance data supplement. You probably already have found this, but no worries, I think can get a hold of that if you cannot.

The book you mention is probably the one I have, it was not very long. I have had it for years, but I believe I know which "book box" it is in, so I will dig it out. However, I will be after this, for some supplemental information. I think it will be mostly historic, but I understand it is good.

Regarding making the model (and apart from Nick's posted 3 view and some other located drawings, every little helps ATM), I got in contact with a scale kit modeller (credit where due) who was kind enough to scan and send me some plans from an old magazine, these...

The most important things are the cross sections, so I can have a guide to get the area ruling right.

After thinking more about it during the lunch break, I came to the conclusion that I actually can do the plain engine modelling easier...

The NF-104A used a very similar J79-GE engine as the B-58, so I could simply use this for developing a suitable engine simulation model and maybe contribute the changes back to Sputnik.

It was also the F-4 Phantom's engines, so there should not be a shortage of information around regarding. If the already developed "model" of one is in your judgement satisfactory with some tweaks, all the better!

And one more question: B-58A with ejection seats or the later modification B-58A with ejection capsules? If the capsules, I would really need to invest some money for a newer flight manual.

I dunno; what do you think? Capsules, I suspect! They were quirky things, and if they saved your life, it did not automatically mean that it was worth living after the deed (ref, the XB-70), but they are so cool! :thumbup:

Also, according to the NACA wind tunnel tests, the engines are hanging at slightly different angles inboard and outboard.

Probably a good reason for that. My guess would be that it is for keeping the thrust-drag couple manageable, as the centers of thrust are lower along the normal axis on the inboard engines and would contribute a greater moment to the couple if some "compensation angle" were not added to them. Again, that's a guess! :lol: Now, why is it?

Finally, one last idea for tonight. Looking at how expansive the project can get just with what you mention here, I honestly think...

 

[Urwumpe]

So, does this mean there is some priority on getting a good cockpit(s) mesh out above all else? That meaning; I am assuming a full working gauge and switch cockpit for the engines "player interface" will be a priority, if you want to start with the engines. I might have misinterpreted that, so please correct me if I am wrong.

Actually, any VC is a 2.0+ idea. The basic aircraft is already complicated enough to get started.

Just look at the early coding problems to solve:

• Better engine simulation is required because the engines are integral factor of the performance - the B-58 was especially famous for its climb rate.
• Later, many systems depend on engine performance as source of power, and every engine pair has different auxiliary systems to drive.
• Engine failures are the primary cause of aircraft losses.
• Aerodynamics differ from Orbiters expectations with the elevon controls.
• CG control is needed for stable flight
• CG control requires simulation of the fuel tanks, including the pod tanks.
• It needs a drag chute during landing
• Ummu should get supported
• Desired animations in 1.0 release:
  • Elevons and Rudder
  • Landing gear with: NWS, compression, wheels and MLG pivots
  • Canopies
  • Drag chute
  • Engine inlet cones
  • Nozzles (maybe simplified by changing the geometry of a simple two-walled tube meshgroup)
  • Pod pitot tube
  • Capsule ejection?

So far, the engines are no need for a VC. The other stuff would be one. Once the simulation is at a point where the titanic navigation system could get added, we would need it. It would be very hard to control the system with the generic cockpit and keyboard bindings.

So yes - after an initial release of the Hustler, there should be a future development with a VC. Maybe I have some concept until then about how to include more developers and share some of the work load.

An important question later would be: Navigator and DSO stations needed as VC or would an AI representation be enough? Even if the Navigator station would be done as AI only... I would love to have the inflight printer output saved as text file. :lol:

Also, somewhere in the future, I would also think that ground start and APU carts would be nice to see. Or doing an interlude and add some soviet SAMs of the era.

I have only had the opportunity for a cursory search for this, so far, and have not found it yet. Have you a reference number for the tech-report? It is well past midnight and I only just got back home as I write this, so I will resume the search tomorrow, when able.

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19710076499.pdf

So. It already has a place in Probe-dom. Its continuing role as a sinister villain suits it well! :lol:

At least, it could do more than training dropping of bombs. :lol:

The most important things are the cross sections, so I can have a guide to get the area ruling right.

Should be the toughest aspect of the model. OK, and of course the DX9 reflectivity map of the skin.

It was also the F-4 Phantom's engines, so there should not be a shortage of information around regarding. If the already developed "model" of one is in your judgement satisfactory with some tweaks, all the better!

Well, it still lacks some stuff, but its a good starting point. Also it is simply the best test vehicle for such an engine, since it only has one.

I dunno; what do you think? Capsules, I suspect! They were quirky things, and if they saved your life, it did not automatically mean that it was worth living after the deed (ref, the XB-70), but they are so cool! :thumbup:

I think capsules would be better because most of the fun stuff with the Hustler happened when it had capsules.

Finally, one last idea for tonight. Looking at how expansive the project can get just with what you mention here, I honestly think...

Keep calm and continue testing?

---------- Post added at 02:01 PM ---------- Previous post was at 09:38 AM ----------

After getting some more insights into the design and function of the escape capsules...

Maybe those should be done as 1.5 version or be developed in parallel by somebody else... this escape capsule is not less feature-rich than the typical space capsule implementations in Orbiter.

 

[ex-orbinaut]

I do think this is going to need a thread over on the Addon Development section of the forum. I feel a bit self conscious getting into discussing a proposed Orbiter addon on the DCS thread. Shall I go ahead and start one?

Actually, any VC is a 2.0+ idea. The basic aircraft is already complicated enough to get started.

Just look at the early coding problems to solve:

• Better engine simulation is required because the engines are integral factor of the performance - the B-58 was especially famous for its climb rate.
• Later, many systems depend on engine performance as source of power, and every engine pair has different auxiliary systems to drive.
• Engine failures are the primary cause of aircraft losses.
• Aerodynamics differ from Orbiters expectations with the elevon controls.
• CG control is needed for stable flight
• CG control requires simulation of the fuel tanks, including the pod tanks.
• It needs a drag chute during landing
• Ummu should get supported
• Desired animations in 1.0 release:
  • Elevons and Rudder
  • Landing gear with: NWS, compression, wheels and MLG pivots
  • Canopies
  • Drag chute
  • Engine inlet cones
  • Nozzles (maybe simplified by changing the geometry of a simple two-walled tube meshgroup)
  • Pod pitot tube
  • Capsule ejection?

So far, the engines are no need for a VC. The other stuff would be one. Once the simulation is at a point where the titanic navigation system could get added, we would need it. It would be very hard to control the system with the generic cockpit and keyboard bindings.

From what I see, there's nothing impossible there, just quite a bit of work. I heed orbitingpluto's comment about it not being all the bells and whistles, but I do think that we are of the same mind that this has to be as right as possible. Call it perfectionism or obsessive compulsive disorder :lol:.

I will take the list from the top. You already seem to have a plan all sussed out for the engines. Regarding the systems running from engines, they will have to be conditional to the respective engine's condition, and certainly not something so Boolean as;

pseudocode...
if(engine[1]="running")
    generator[1]="on"
    hydro_pump[1]="on"

Yes, I know you are more than aware of this; it is just to show I am of like mind. There are several factors going to influence the performance and "output" of each engine driven system under different flight conditions. Again, you will know what you are doing... :tiphat:

Regarding engine failures, I am not a fan of random failures out of the blue on an engine that was running perfectly well two seconds earlier. Barring ingestion, it is very rare. Failures will usually be preceded by a (sometimes long) history of "misbehavior", and that itself as the result of some "mistreatment" or another. This is not unlike the requirements of the cumulative "stress" the newer DCS models are implementing. I am just picturing in my head the gargantuan coding requirements of engine component condition following, however. It is a (much) later development, as far as I can see.

Do you want a mesh of the engine, BTW?

Elevons and the mixer unit. Yay! The Delta-Glider has them! However, the B-58 FCS has a feature of aileron and elevator available (ratio) and the stick authority limit, with 3 modes! That is going to be fun. I am thinking; the animation for the surfaces themselves should be done for full movement, and the control (joystick) input be "intercepted" and processed by the "mixer/ratio" code before "output" to the control surfaces themselves. That way the factors that are conducive to reduction of movement can be computed and a "percentage" of the commanded movement be sent to the animation, as required. No doubt, you have already considered this, too. I mention it only as it involves the mesh animations.

CG control through fuel "ballast" shift. Actually not so hard. I made an addon all about that subject some time ago, but the controls were pretty basic. Once the centroids and interconnection routes (a bit like a text adventure's room interconnection, really) for each tank are established, the biggest challenge, programming-wise, will probably be a believable B-58 fuel management panel! Centroids, I say, unless you want to go full shop and have the local cg of each tank vary as it empties, though I have not seen any tables for the B-58 regarding this, yet. Maybe in the Supplement? Now, my worry, from Orbiter API (please note, it has been a long time since I last touched it) is the CG Shift function. I recall its effects being a little "harsh" (?) on flight dynamics.

The drag chute is an animation, and yes the object would be, eventually, to have a nice deployment sequence! :thumbup:

Agreed on the other animations, however I have not found a reference yet in the Flight Manual as to how much movement there is on the spikes.

So yes - after an initial release of the Hustler, there should be a future development with a VC. Maybe I have some concept until then about how to include more developers and share some of the work load.

An important question later would be: Navigator and DSO stations needed as VC or would an AI representation be enough? Even if the Navigator station would be done as AI only... I would love to have the inflight printer output saved as text file. :lol:

Eventually, I hazard to think, a VC for all? There are some important tasks to be carried out by the other two crew members, especially (from what I can glean by my preliminary scan of the Auxiliary Equipment section) the DSO's management of the TR's for the DC power buses. The NAV system might be a bit of a challenge, but I think I can already see a stop-gap measure that can be used straight from Orbiter API, while it is developed properly. But perhaps you are right; AI stations for now.

Let me be customarily silly for a moment. How about OMP, so three multiplayers can fly in the same aircraft doing the station duties? Yeah, I know... :rofl:

Also, somewhere in the future, I would also think that ground start and APU carts would be nice to see. Or doing an interlude and add some soviet SAMs of the era.

Aw, yeah. Guidelines! (Sound like you want to do a SAM sim for Orbiter?) And the air cart, at least, is a must. Can't start the beast without it.

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19710076499.pdf

Thanks for that. It is a good report. The transonic drag increase and LD data is pretty critical for good performance of the model, but unfortunately stops at M 1.2 on the graphs. Also, the AoA range of the test is a bit limited, but it is a great starting point.

What do you think? I feel the capsules as "Orbiter modules" is something that will become important during VC development. I'll do the meshes, and they can just "eject" for visual eye candy, while the model has only 2D panels.

And finally; yes, I have made a start on the mesh!

 

[Urwumpe]

OK, my book orders arrived, including F-104 and B-58 flight manuals ... now I just need some more time to work on the math.

 

[MaverickSawyer]

Let me be customarily silly for a moment. How about OMP, so three multiplayers can fly in the same aircraft doing the station duties? Yeah, I know... :rofl:

DO. WANT. Count me in if you need a third warm body for that!

 

[sputnik]

Eek. I had missed this thread. I have a B-58 add-on ready to go; was just waiting on adding some functionality for some of the payloads. I'll skip it and get it out there now.
Mesh is based on an X-Plane model, so there's certainly room for improvement.

 

[Urwumpe]

Eek. I had missed this thread. I have a B-58 add-on ready to go; was just waiting on adding some functionality for some of the payloads. I'll skip it and get it out there now.
Mesh is based on an X-Plane model, so there's certainly room for improvement.

Dont worry, there is a lot of room left... also I am using your NF-104 right now for fleshing out the J79 simulation a bit (Thus the need to get a readable F-104 manual)... simply because I still know its source code and it was good.

---------- Post added at 10:58 PM ---------- Previous post was at 09:07 PM ----------

Just reading the newer B-58 manual with the modifications... anybody also interested in allowing a cartridge start of the #2 engine?

 

[ex-orbinaut]

DO. WANT. Count me in if you need a third warm body for that!

Aye. Seems to be one of the most "un-pursued" facets of flight sims, as far as I can see. Don't even know if it would be possible with OMP, but it would be cool, wouldn't it?

Eek. I had missed this thread. I have a B-58 add-on ready to go; was just waiting on adding some functionality for some of the payloads. I'll skip it and get it out there now.
Mesh is based on an X-Plane model, so there's certainly room for improvement.

Oh, man! For my part, sorry! I had no idea you were already working on one. Looking forward to seeing your add-on.

Just reading the newer B-58 manual with the modifications... anybody also interested in allowing a cartridge start of the #2 engine?

Plus One.

---------- Post added 10-22-14 at 10:36 AM ---------- Previous post was 10-21-14 at 10:20 PM ----------

Good to see it in Orbiter. Nice one and good work! Took it for a fly around. Animations are working well.

Mesh is based on an X-Plane model, so there's certainly room for improvement.

I see what is meant, regarding this. I was expecting to see a higher poly mesh, really (I have not cracked it open in any editor yet to see the count, however, please note). With my own time constraints IRL, mine is taking and will take a long time to complete. I have partly finished with the fuselage, as yet, as a basic Anim8or mesh to improve on, but it already "looks" higher poly (ie; keeping emphasis on smooth transitions of form between the cross sections) than this X-Plane one, and I thought I was keeping them low.

I do worry that my standards and rusty mesh building prowess might not have been up to expectations, but I will press on anyway! It is bound to improve again with the renewed practice.

 

[Urwumpe]

Can you include already details like the external air conditioning and starter air connections and their access doors? And the cartridge starter door on the #2 engine?

 

[ex-orbinaut]

Can you include already details like the external air conditioning and starter air connections and their access doors? And the cartridge starter door on the #2 engine?

I do think so. From the start I have had the objective of conforming the model as much as possible to the access panels, with the idea that "damage" can then be better simulated/represented.

 

[Urwumpe]

I do think so. From the start I have had the objective of conforming the model as much as possible to the access panels, with the idea that "damage" can then be better simulated/represented.

Sounds like a good plan. I think about making an Aircraft vessel framework for it, so that at least other aircraft of the era could be programmed by reusing the component model.

Right now, I am trying to get the engine model from a university thesis programmed into Orbiter and work on fitting the parameters to the engine performance.

 

[ex-orbinaut]

I think about making an Aircraft vessel framework for it, so that at least other aircraft of the era could be programmed by reusing the component model.

This would be very good. You know, the narration on the video I posted over here had me wondering...

The NACA tech report deals with reasonably high stream velocity characteristics, but I find myself also to be interested in the low speed regime, particularly the increase of induced drag (deltas being famous for this, AFAIK). The video talks about the use of the two outboard afterburners at low speed, as used during refueling. Obviously, they were limited by VLE throughout that ordeal, which would have kept them at a high AoA, and the massive fuel transfer testifies to some high consumption all the way through the night in the gear down configuration, but the consumption is phenomenal (as a quick calculation of fuel/time, the resultant flow works out at something above the region of the maximum fuel-flow per engine on the gauge!).

Of course, it is a rough video, where data is concerned, and there is no mention of other leaks aside the pod (which they would not have been pumping fuel into), but no doubt the expected low speed characteristics of the aerodynamic model are going to be something akin to the DCS Mig-21, another delta.

Right now, I am trying to get the engine model from a university thesis programmed into Orbiter and work on fitting the parameters to the engine performance.

Nice!

I am at a bit of a "semi-loose end" today, for once, so I am making some progress with the mesh.

 

[Urwumpe]

I am at a bit of a "semi-loose end" today, for once, so I am making some progress with the mesh.

Yeah... but progress here is still slow. Spent the past free hours of the week for creating a simple mathematical model of the engine in Java, so I can compare the EGT/Thrust/Nozzle curves in the F-104 manual with it. Still not working well, even linearized differential equations are a lot of math for the evening.

But the engines are the most crucial part of the aircraft, if they are not working properly, even the aerodynamics can't fix it. Also, the engines are cool. Still the howling J79-5 engines.

What I think about... if we do a VC, we should have at least an AI DSO for reading the checklist to the pilot and navigator. And we really need the clothesline style transport "rope transfer line" between the three cockpits. Or the ashtrays (oh, the 50ies had been cool)... the food storage compartments.

Also, my experience from SSU tells me: All animations and VC definitions should be done by configuration files and not be hardcoded at all. Maybe even every subsystem configuration that can be described by factory patterns.


EDIT: Just found a Matlab/Simulink model of a jet engine that is accurate enough for our purpose. I think I can program a C++ version of it.

 

[ex-orbinaut]

Yeah... but progress here is still slow. Spent the past free hours of the week for creating a simple mathematical model of the engine in Java, so I can compare the EGT/Thrust/Nozzle curves in the F-104 manual with it. Still not working well, even linearized differential equations are a lot of math for the evening.

But the engines are the most crucial part of the aircraft, if they are not working properly, even the aerodynamics can't fix it. Also, the engines are cool. Still the howling J79-5 engines.

EDIT: Just found a Matlab/Simulink model of a jet engine that is accurate enough for our purpose. I think I can program a C++ version of it.

If this is what you are doing, very nice! You'll be setting a new standard when you pull that one off. :tiphat: Looking forward to the results when this is all "installed". Let me guess; I am pretty sure this is not going to be using the standard Orbiter API thruster.

What I think about... if we do a VC, we should have at least an AI DSO for reading the checklist to the pilot and navigator. And we really need the clothesline style transport "rope transfer line" between the three cockpits. Or the ashtrays (oh, the 50ies had been cool)... the food storage compartments.

:lol: Open the hatches, stick back and hard left rudder, and you can even have a spin dryer, if you want! All possible as far as the mesh is concerned; the thing is time. Did some yesterday, but only a few minutes today. Still relearning the use of some of the tools, but my main worry of the fuselage is over and done with. I won't post too many of these screen shots until I have something worth looking at, just this one to show that I have actually started...

Zinc chromate primed (EDIT: Aw! Shucks, it's bare metal. Get the Brillo pads out, lads!), but the trailing edge is looking a bit like Batplane II at the moment. Didn't have time to clean it up today. Sorry.

Also, my experience from SSU tells me: All animations and VC definitions should be done by configuration files and not be hardcoded at all. Maybe even every subsystem configuration that can be described by factory patterns.

The Orbiter script language, perhaps? It would simplify things for the tweaking/testing stage, I imagine.

 

[Urwumpe]

If this is what you are doing, very nice! You'll be setting a new standard when you pull that one off. :tiphat: Looking forward to the results when this is all "installed". Let me guess; I am pretty sure this is not going to be using the standard Orbiter API thruster.

Found a more "Math for software developers" like thesis :lol: But yes, something along such lines.

And time should be in mesh terms the smallest problem, the main trouble will be making the code for the meshes.

The Orbiter script language, perhaps? It would simplify things for the tweaking/testing stage, I imagine.

Well, first of all, it would make it much easier to include changes in the visual. Instead of programming everything new, we then only need to blame the mesh makers for the bugs.

Of course, it would also make SW testing easier since it removes many internal dependencies and allows adding better seams into the code.

 

[ex-orbinaut]

Found a more "Math for software developers" like thesis :lol: But yes, something along such lines.

And time should be in mesh terms the smallest problem, the main trouble will be making the code for the meshes.

Well, first of all, it would make it much easier to include changes in the visual. Instead of programming everything new, we then only need to blame the mesh makers for the bugs.

:dry: *Cough* Cutting straight to the animated ashtrays (with smouldering cigarette). I can tell right now they are going to be a problem to code...

 

[Urwumpe]

:dry: *Cough* Cutting straight to the animated ashtrays (with smouldering cigarette). I can tell right now they are going to be a problem to code...

Thats pretty turbulent flow above a lit cigarette.... oh...you mean we should fake it? :lol:

Actually, much harder is getting some important flight limitations into the engine model right now... studying how to imitate the behavior of the different kinds of compressor stall.