I recently found a freeware OCR (optical character recognition) software that supported asian character sets, but…. arrrrrgh! It’s INTERFACE was in Kanji, so I couldn’t figure out how to use it. OCR has always been a bit of a hit or miss proposition, so I was loathe to spend any $$$ on a crapshoot that I could get translations of scans.

Just yesterday, that all changed. I saw in a web review that OmniPage 17, one of the oldest OCR packages dating back to 1995 or earlier, had just added asian character support. I found one on ebay for $80. I hemmed, I hawed… I bid. I took the risk.

Well, the software arrived quickly from Brooklyn, NY and I loaded it this T-giving weekend. I scanned in a cockpit legend… got the results in a Kanji font, exported them to MSWord, and then cut and pasted a few test items into GoogleTranslate to check, and…. success!!!! A few items need to be trained, and some items got mixed up because I OCR’d it in columns rather than one lump of text. But I sure can’t complain.

This is going to be great, I think. Not just in getting those tantalizing system descriptions, but also some of the narrative articles that fill out each Maru and FAOW!

Consider this a review and a rave one at that, for Nuance’s Omnipage 17.

See full size, 1024 x 768

See full size, 1024 x 768

See full size, 1024 x 768

Still to do are the side walls, and a few doodads here and there. Also, I need to edit the control panel on the texture to get rid of the holes, as these don’t mate up perfectly with the already placed gauges.

Next step is to delve into animation and expand the number of items that actually move in game. Far as I can tell, in the pit only the throttle and the stick move. So, I’ve got my hands full with all the other necessary controls, as well as exploring some new ones.

When Simulab was aiming squarely at JSBsim as its graphic engine, the plan was to leverage Blender and its Collada-friendly system for import. So, it was quickly becoming necessary to come to grips with this overwrought, incredibly confusing leviathan of a modeling/animation software.

I spent quite a bit of time giving Blender 2.5x the old college try. Really I did. But… even the new 2.5 versions are such bloated, over-designed messes…. how can anyone expect to be productive with this?

You have to know a keyboard command or enter a keyword for the most basic simple types of operations, like resizing, repositioning… stuff that, in AC3D you can do by selecting the object and just using the mouse.

Once you get into all the side menus, you soon find yourself lost. You can spend half an hour trying to find some specific bit of info about an object, or to find a submenu you were *sure* you’d seen before… but now that you need it, it’s buried somewhere in the interface.

Yes, Blender is fully featured… but what good is that if you can never find what you’re looking for?

One fine point I never could figure out (and yes, I admit it might be a case of “user error”)… how do materials and textures become so inextricably intertwined? From what I could figure out, if you set up a material, then later assign a texture to a part, you have to re-install the material for a new part if that new part uses a different texture. Can’t tell you how many times I set up a texture, something ubiquitous, like aluminum… and then when I assigned it to objects that did not share the same texture… total confusion ensued. I’d have to install (and keep straight in my head) an instance of the material for each texture I might use in the model’s parts. I just don’t understand why the two have anything to do with each other.

In fact, the only thing I did like about Blender is that the editing renders were, for the most part, pretty nice.

See full size, 625 x 512

Provided you set up the right lights, you could get really nice effects, like sun off aluminum, the difference between metal wings and fabric-covered control surfaces…. all except for see-through glass, which for some reason didn’t show up. I never got into it far enough to learn how to get a good quality RENDER that would show off the same keen detail I got in the viewports.

Then, after all the pain I endured to learn the little I did learn, come to find that the animation tools wouldn’t export in the Collada files Blender 3.5 exports. Even worse, setting animated parts to adhere to Local positions didn’t export either So, when I exported a Collada file to Simulab, in the Simulab Viewer, all the moving objects would cluster at the 0,0,0 point… even though they were set up in Blender to hinge at their well-established hinge points.

Good riddance to this big piece of bloatware. FlightGear is happy to work with AC3D files, and I’m told the X-Plane animation plug-in will work a treat. Even better, I hear that setting up a “hinge” is no more difficult than to plug in the coordinates of two points at either end of the hinge line. Sounds simple enough to me.

See full size, 1024 x 768

As of today, here’s where the progress sits…

See full size, 1024 x 768

See full size, 1024 x 768

See full size, 1024 x 768

It’s almost there. I’m not happy with the rudder pedals (need to be wider), I want to have another go at the sloped auxiliary panel on the left side, and a few radios on the right side need to be outfitted with knobs and switches… and I need to lay in some pipes and wiring bundles. Then, of course, it all needs to be textured.

See full size, 1024 x 768

See full size, 1024 x 768

See full size, 1024 x 768
I haven’t started the texturing process yet, so it’s quite a bit hard to see. But still… you get the point. What’s still missing is:

There’s a large unit on the wall with many dials and toggle switches and lights on top, on the left pit wall, near the throttle. I reshaped it, but haven’t added the rest of the doohickeys to it.

And on the lower forward right there are two or three radio/electrical panel boxes and a series of pipes and conduits for the backup hydraulic system that I haven’t gotten to. That area looks a bit bare at the moment. Then, after that, I need a bunch of wiring and pipes to finish the cluttered, claustrophobic pit, and placing fuel gauges on the right panel.

I added the thin back headrest (even though it’s not really visible in game), the proper rudder pedals (the actual foot pedals need to be made wider though), and I made the seat more accurate. Oh, yes…. before I forget…. GUNS! They’re also a bit undefined, but two 7.7mm machine guns are now there in the cowl, with their cocking handles.

I’ll post more as I add the missing final elements and start on the textures.

Before… amateurish gauge art

After… vast improvement

Then, I started asking questions about the spartan cockpits. I wondered if I could start with the already created FG “tub” and start to add more detail to it? A half hour and a trip to AC3D later, and the answer was a resounding “yes”. I added a few sections of bracing to the existing FG Zero. That’s just the start of a lot of gear, wiring, conduits and stuff… not to mention a pair of cowl machine guns, which I can’t believe they left out… whether they currently function or not.

Only problem with this might be the totally weird axis setup FG is currently using, and how Simon and Gerry at T4T are envisioning using a code snippet at the head of an aircraft’s file to create a proper alignment. I’ll have to see if I can use the native AC3D axis alignment and still be able to perhaps use some FG geometries and make it all work in a new mod. My goal is, for some planes where FG’s external models might do fine (with just a texture upgrade, of course) and my cockpits, why re-invent the wheel? Get permission for a few Frankensteins, give credit where credit’s due, and get through the planeset quicker; especially those old Target:Rabaul aircraft I had nothing to do with, but could still make use of in an expanded Hakko Ichiu planeset. The P-38, F6F Hellcat, TBF Avenger and a few others might be plane families where I can really make this go. I have yet to do any geometries at all for them, internal or external, but if I can save time and only have to do a cockpit, and a little bit of axis rotation, why not? I will have to at least open the models in AC3D, prepare some background graphics and make sure the dimensions are done properly. If they pass muster, not having to create them, or perhaps just using them as a starting point, will save SCADS of time.

Paul, the chief dev who’s responsible for bringing the combat elements to these ventures, seems to busy with Real Life™ at the moment… I sent him an email relative to the crew/gunner debate and he requested I file the comments/requests in a job ticket repository for the mean time. I sure hope he doesn’t get so sucked into his “real job” that he becomes a stumbling block. Really, his delivery of the combat possibilities (ballistics, collision code, damage modeling) and the server/mission GUI are critical. Without these all we have is this spotty-quality civilian flight sim… and that just won’t cut it.

I’d really like to be sure he can deliver before I truly jump in feet first with this mountain of work to get Hakko Ichiu going. I suppose I now know I can, at any time, begin the task of reorganizing and porting over the IJN, USN/MC, USAAF and RAAF gauges, and placing them into a shared instrument folder directory.

Up til now, I’d had just a bear of a time with it, and so have the Target For Today guys, so I’ve kind of let it slide until they get a bit further along.

When I got set up the first problem was that there were a bunch of civilian and other aircraft that I just had no interest in whatsoever, in the stock set. Adding planes through the wizard just wasn’t working, and I’d just given up. But today I persevered and had another go at it.

First thing was to solve the plane list issue. I removed all the planes I had no use for… and still they populated the menu. Huh? Further poking around revealed that there were TWO Aircraft/ folders, one at the root, and one inside the data/ folder. I trashed the one in the root, and took all the undesirables out of the data/Aircraft/ folder and voila. My available plane list started looking more like I wanted. But, still many add-ons I wanted to see weren’t showing up. That was because, when you download the add-on planes, they come in an archive with some numeric date reference on them, and on the folder name as well. Of course the aircraft files aren’t looking for that :rolleyes: … so I had to move all the files and sub-folders out of the “Plane-Type_020304″ folder and put them in vanilla “Plane-type” folders. That fixed most of the rest.

Then, a tour through what I’ve got. I launched each one and had a look. Almost universally, I can see I’ll have to replace all but perhaps the 3D exteriors. The exterior textures are of the most basic quality imaginable, and most of the pits are terrible as well, both in 3D and 2D. I imagine for the aircraft I’ve already modeled, I’ll attempt to engineer a complete replacement.
Next up is to start the process of porting over the gauges, and getting them to appear in the FG-native aircraft. Then after that, perhaps learn Gerry’s process for multi-crew access in planes with that.

Then after that, I get to the real make-or-break point where I decide if I’m going all-in or not. I’d like to have more info on how Paul gets on with the combat aspects of the system, how the terrain fits in, and have an idea of the interface. FG’s interface is spotty: it has some nice ideas in it, but it’s all wrong for a mission-oriented combat flight sim. We’ll need to have it set up to log into a server, which would handle what terrain loads, what the whether is, the location for the action, the weather (FG seems to have a lot of weather features, including the ability to get “representative” weather that mirrors the day’s weather at the location you’re simulating! Of course, that all would need to be controllable at the server level, not at the player level as it is now).

Color me optimistic at the moment.

On the damage side, Simon’s now envisioning a 16-section wing (!!), with the possibility of non-rectangular hit boxes tied to the flight model.

Nice that he’s going through the trouble, but I can’t see the need for 8 sections on each side of the wing, especially for a fighter-sized aircraft. Something like a Lancaster or a B-29, sure. At any rate, I’m just hoping that his calculation method allows the author to make different decisions and can create 6-section wings (root, middle, outer per side). That’s how I see doing it.

The wild card at the moment is Paul Guhl. He’s checking in with little bits of progress, most notably that he thinks he’s solved the lighting limitation issues, so that we can plan on having flexible cockpit lights or luminescent gauges (as was or wasn’t available per type). But, he also has to make the damage modeling ideas work. If he comes through with the ability to use irregular damage hit boxes, and tie them to the damage model, with probability-based component damage… well, I think we should be happy with the end result. The other thing I want to be sure we get is variable materials, to allow for “toughness” or resistance to failure for different parts. The hard-coded one-material inflexibility problem was crippling at Targetware… it created a bunch of problems with weapon effectiveness.

Speaking of Targetware, the news came out on the separatist Target: Tobruk site that Vespa met with -sick- and got confirmation from the horse’s mouth that the project is dead in the water with no plans to move forward. I dutifully went to the TW site and penned the obituary… seeing as -sick- can’t be bothered to do it. Arrrrgh…. still seething about that….

But, we’re getting closer to the time when I can commit to scaling the mountain of work needed to get Hakko Ichiu up and flying. I need to be sure that Simon has “perfected” his FM method, and that it’s documented. Same with all the 3D and 2D production stuff Gerry’s working on.

So, here’s hoping we get some confirmation soon from Paul (outlaw) Guhl that we’ve got a new GUI, ballistics and weapons and some semblance of a server-based, MMOG system to put all these planes into. If all that comes together, that fires off a big Very pistol for me and signals a new push to finally get a serious, historically-based flight sim on the road to release.

Provided that works… then I’ve got a boatload of Japanese, American and Aussie gauges to port over. Simon and Gerry are thinking about the idea of using texture atlases (whereby you combine shared artwork on larger texture files, presumably to limit draw calls as much as possible), so I may need to wait and lurk a little while longer before diving into THAT pool.

Today, though, Mossie got the trial Spitfire I on the tarmac in-game in Flight Gear (albeit with landing gear not displaying correctly, as it hasn’t been mated to a proper flight model). Still that’s immense progress. In the whole time we were associated with Simulab, nobody managed to get a model that wasn’t one of Paul’s original jets) to appear in-game.

With FlightGear, we can use the X-Plane plug-in to create and preview animations, and also, the animation protocol in this system requires only that, for a hinge or a travel path, you name the xyz coordinates of the two end points. That is such a wonderful, freeing revelation. No more of the old Targetware drudgery of needing to provide both a position and an angle accurate to 3 or four decimal points… on any axis that was not completely 90 degrees, or haggling with whether or not the part references the 0,0,0 point. Just that one fact alone will reduce a huge burden with regards to building and importing aircraft.
So, it’s actually looking like this is gonna happen… provided Paul can add the ballistics elements, Simon comes through with the flight model process, and we all can create the GUI and other gameplay elements we require to call this a decent combat sim.
I’m looking forward to jumping in with both feet. I’ve got 25+ aircraft and almost 10% of the earth’s surface to outfit. And I miss flying too!

Paul was optimizing his commute train time in Germany by trying to wrestle

Simulab into some semblance of shape. There was some progress, but

frustratingly slow. That’s one of the downsides of the “lone programmer”

method of sim development. Well, at least he’s communicative.

My “relationship” with Simon (bomber) Morley hasn’t gotten any better. He’s

still as cantankerous as ever, and has effectively frozen me out of what has

evolved into nearly daily Skype sessions. The people involved in those chats

are Paul (outlaw) Guhl, Simon (bomber) Morley, Kevin (mekpg) Pothoff and

Gerry (Mossie) Mos, who was always a very prolific Targetware contributor who

really steps up to the plate, delivery-wise. He’s got a huge store of 3D

objects and targets, and is a fast and efficient 3D modeler and animator.

After a few attempts to try and steer and clarify discussions, I quickly

realized that Simon will always “shoot the messenger” if that messenger is

me. So be it. So, I decided to merely “lurk” on the discussions, limit my

contributions to only the most important things, and to just go to Paul

directly for feature requests. I can trust that the group will likely end up

agreeing to something I can get behind. In the end, all I really need is to

get the flight gear creation method under my thumb, and then I can get Hakko

Ichiu up and running, by my lonesome if I have to.

Simon has worked up a detailed Spitfire I flight model, with, I believe, 4

sections per side (whereas the Simulab/X-Plane/FlightGear systems all adhere

to the single wing concept, which of course isn’t granular enough for a

combat flight sim, where you need to degrade specific areas in response to

combat damage). Simon said he was pretty close to having it ready for

Simulab.

Full Reverse! Hard to Port, Ensign!

Then, on 20 August, 2011, the bomb landed. Paul had been stumped by a

nettlesome flickering problem with his graphics engine. He looked at his

progress overall with Simulab, and how far he still had to go to get a

workable alpha, and decided to change direction… radically. He elected to

align his efforts with the FlightGear engine. The benefits being that it was

already up and running, had a large aircraft selection already and was also

proven at accommodating third party efforts.

The downside? It’s a civilian sim, so there are no bullets, bombs, rockets,

missiles, or anything else of a beligerant nature (Odd that it had lots of

historical and modern military aircraft modeled…. I have to ask, “Why

bother?”). But that’s what Paul hopes to add: all the combat elements, plus

the interface overhaul that has already been hashed out for Target For Today

.

The FlightGear Era Begins…

Anyway, since the announcement, we’ve all been downloading Flight Gear,

poring through its planes and file structure trying to figure out what’s

what. It’s been somewhat enlightening. First the bad.

1) No consistency. The 3D models and textures are all over the map. Some have

very spartan, non-textured cockpits. Some have fully functioning modern

instrumentation. They use a hodgepodge of graphic file types (.jpg, .tga,

.png, .gif) and a variety of methods (alpha layering, bump and occlusion

maps, etc.).

2) Poor GUI. So bad that installing the program can be an exercise in

frustration. I hope Paul will quickly be able to take Simon’s vision and

create an interface that’s usable and flexible.

3) Goofy orientation: The only sim I’ve yet seen that doesn’t use the X axis

for the wing/roll axis. In FG, X is the thrust/nose-tail axis. Whatever:

Simon plans to introduce a root-of-the-object rotation line item to set

things to orient to the AC3D axis setup.

4) No combat modeling.

5) Very limited damage modeling (e.g., random part and system failure). Part

and parcel with #4. This is what Paul is tasked at adding.

6) Flight modeling very basic. For our purposes, that translates into

“crappy”.

And the good:

1) FlightGear is set to work from .ac AC3D file format! It can make use of

the X-Plane AC3D plug-in to create animations and cull the numeric data for

use in its .xml files. In fact, I believe that going with Flight Gear rules

out Collada as well. Yay, no more wrestling with that infernal Blender!!

2) The gauges look to be easy to create, and I’m reasonably sure I’ll be able

to quickly port the Targetware gauges over to FG gauges (improving the

accuracy of the 2D work manifold in the process). T4T wants to use 3D gauges,

which I still don’t see the benefit of at all (why use hundreds of polys to

describe the lip of a gauge and protruding mounting screws when a bump map

will do just fine?). At worst, I can take (and re-axis-orient) a FG 3D gauge,

replace its textures with TW 2D art, and see what the graphic hit is. As it

is, needing 3 rectangular objects (and just 6 tri-polys) to describe a face

and two needles has got to beat the hell out of nearly 300 for a true 3D

gauge. We’ll see, I guess.

3) Crewing (one of Simon’s big emphases) is already included and implemented.

Ditto for carrier operations.

4) Weather. Already built in. Will come in very handy for monsoon season with

Hakko Ichiu.

5) Moving assets/targets. In fact, since its designed more as a single-player

system, it’s got lots of AI features I’m sure we can bend to our devices.

Now the unknown….

FG uses a server-retrieved terrain system, and we have no idea yet how

editable it is. Suffice it to say, this being a civilian sim, it’s going to

be chock-a-block with modern-day airports, and will require a lot of work to

restore the world back to the 1940s. I’m fairly confident the 2D artwork

(basic terrain textures) will be able to be ported from Targetware… but how

do we scuplt the actual terrain? How will roads and rails and coastlines

work? (Would be nice if it’s vector driven and also editable). The bigger

question is, how can we keep our edited terrain separate and still support a

MMOG sim?

Well, having sat with this for a week, and seeing the first Skype session

transcripts, I’m a bit bouyed by this change in direction. Provided Simon is

successful in porting the Spitfire, and its detailed FM to FlightGear… and

provided he can then create a tutorial that shows the rest of us how to do

that; and then, provided Paul comes through with the interface and the combat

elements needed to make this a creditable combat sim… then the future would

be bright.

But, those are some huge IFs…. so I’m going to stay tuned, and try to

remain a bit detached, so as to limit my disappointment if this doesn’t pan

out. I may begin the process of porting Japanese, American and British gauges

over (I can use the existing FG Zero and Kate and Val as guinea pigs to test

them in situ, before axis orientating them for Hakko Ichiu), as this is a big

and necessary undertaking.

I’ve already contacted Mossie about showing me how to do animation using the

X-Plane plugin. Paul has already contributed a debug overlay for testing

aircraft during development. Simon has a Spit on some FG tarmac (albeit, not

animated yet), and thinks it’ll be flying by the end of this weekend.