Project P.1101 Var.1944 -- Training Aircraft WIP

[teslax]

Hi guys, I'm totally new to Orbiter add-on development but I'd really like to learn on how to develop one, or simply just to make good flyable aircraft in the software. Fortunately I already have some prior experience with 3D Modeling and the necessary graphics skill like Photoshop. I used to help my school in designing banner and other artwork. For coding skill,I only know basic scripting with Python, though I have tried programming with C# before. For the game internal mechanics, I know very little of it currently. I understand basic orbital mechanics as taught in fundamental Physics course but not much. I haven't learned ODE and the advance mechanics course yet.

Having explained my background in brief I would like to propose this simple project of mine. I am planing a new aircraft derived from the prototype aircraft, Messerschmitt Me P.1101 variant 1944. I'm not going to copy the plane exactly and in fact I'm quite liberal with the planning because I don't want this project to be too complicated. This aircraft will have no capability for orbital flight. I see it only as a maneuverable, fast, light aircraft -- maybe even as a cargo object for the heavier craft like the XR-X to be transported around the solar system. :lol:

Plan from Luft45 site.

This is the progress so far. I've managed to get the fuselage and the wing. So far it has approximate 800 polygons.

As you can see the plane's main propulsion is liquid fuel rocket similar to Me-163.

To do:
-Model the aircraft completely (Partially done)
-Add cockpit and virtual cockpit
-UV Unwrap and paint texture to the plane
-Add the plane to Orbiter

I have several questions for the expert developer here:
-How Orbiter handle the flight surfaces and other openings? Does it consider it as separable mesh from the main fuselage?
-How can we integrate the animation to Orbiter? Do Orbiter has default animation or do we need to create one from scratch?
-Is the virtual cockpit separate mesh from the aircraft mesh?
-What is the maximum polygon counts for good FPS?
-How large should the texture map be?
-Does the current Orbiter renderer support bump-map or normal map?
-How does Orbiter model the flight characteristic of the plane? In this case I don't know how the aircraft should behave because it's fictional aircraft. How can I best manage this?
-What are the major steps to integrate aircraft to Orbiter?

-----

For latest updates please scroll down below.

Thank You for your help and attention. I also apologize if my post is unprofessional for addon. I'll try to improve the first post as the time progresses hopefully.

 

[boogabooga]

For you, I would look up something called spacecraft3.

It provides a generic code such that you can define aerodynamic constants, animations, etc. from .ini files rather than having to write your own code. Having said that, setting up airfoils and such is on the more advanced end of spacecraft3, and the results for aircraft are often "meh..." at best. (spacecraft3 airplanes occasionally and unintentionally are orbit capable. ) So writing your own dll for your aircraft could be your ultimate goal.

 

[Loru]

I have several questions for the expert developer here:
-How Orbiter handle the flight surfaces and other openings? Does it consider it as separable mesh from the main fuselage?

Other than rendering scene and animations there is no connection between flight model and mesh in orbiter. But if you want some part to move in orbiter, they have to be separate objects or, how they're called in orbiter "meshgroups" (refer to 3dmodel.pdf in OrbiterSDK\Doc\ folder). Also single meshgroup can only have one material so forget about Multi/sub materials.

As you can see in attached pic each meshgroup has it's color of the wireframe
[url=http://www.orbiter-forum.com/gallery/showphoto.php?photo=5449] [/URL]

-How can we integrate the animation to Orbiter? Do Orbiter has default animation or do we need to create one from scratch?

By default orbiter support translation, rotation ans scaling of entire meshgroups. You can define animations in code and link them to meshgroups.

Haven't seen animation exported from 3d modeller to orbiter yet though.

OrbiterSDK\Doc\APIGuide.pdf and APIreference.pdf are your friends here

-Is the virtual cockpit separate mesh from the aircraft mesh?

If you're using "Spacecraft3" framework (scripts to define vessel parameters instead of compiling your own dll) then VC has to be separate mesh (3dmodel.pdf and APIguide.pdf as certian groups have to have proper flags attached to them in order for VC to work)
If you're coding your own dll, then you can use same single mesh for craft and VC.

-What is the maximum polygon counts for good FPS?

Depending on machine, OS, texture set, graphic client you're using etc. etc. Orbiter is an open sandbox you can arrange way you like. Largest polcoun I've seen in orbiter was ~220 000 polys and it gave me headache on my previous machine. On good machine orbiter is quite capable though as demonstrated with some projects here (few thousand modules each few hudreds of polys)
You can go anyware from few hundred to few dozen thousands. 2000 - 12000 is good boundary for start.

-How large should the texture map be?

Depending on your needs but to keep compatibility with older GPUs keep your textures in square and power of 2 size (2048x2048 is common limit for certain GPUs). If you need more space just make 2nd texture.

-Does the current Orbiter renderer support bump-map or normal map?

Default graphics client does not, however there is Direct3d9 client for orbiter that support bump, normal, specular and reflection mapping.
http://d3d9client.codeplex.com/

-How does Orbiter model the flight characteristic of the plane? In this case I don't know how the aircraft should behave because it's fictional aircraft. How can I best manage this?

Trial and error. Orbiter uses "Airfoils" and "Crossections" to manage lift and drag characteristics. Look at examples in OrbiterSDK

-What are the major steps to integrate aircraft to Orbiter?

-Meshing
-Texturing
-Mesh Conversion
-Coding/Scripting
-Debuging (a lot of times)
-Packing into zip
-Releasing

Thank You for your help and attention. I also apologize if my post is unprofessional for addon. I'll try to improve the first post as the time progresses hopefully.

:tiphat:
Glad to help. Remeber that orbiter has excellent API, and documentation (said OrbiterSDK folder). Dig through that. And keep trying.

Also on the bottom of THIS page you have some usefull developer resources.






-

 

[goaowonk]

(spacecraft3 airplanes occasionally and unintentionally are orbit capable. )

Those Moon landings with a Me-262 are pure epicness.

 

[4throck]

You can take a look at similar airplanes on Orbiter Hangar. Be careful that some of them are old and use Spacecraft2. That version is compatible with Spacescraft3 but the configs have less options.
Anyway, you can use it to see how things may be put together.

 

[teslax]

Other than rendering scene and animations there is no connection between flight model and mesh in orbiter. But if you want some part to move in orbiter, they have to be separate objects or, how they're called in orbiter "meshgroups" (refer to 3dmodel.pdf in OrbiterSDK\Doc\ folder). Also single meshgroup can only have one material so forget about Multi/sub materials.

...

I'll definitely try to look into the documentation and see this spacecraf3.dll. I really thank you guys and specially Loru for the detailed answers and explanation. It's certainly very valuable. The process is surprisingly quite straightforward and make sense as you described. I was first worried that I might exceed the average polycount but then < 12000 should be achievable without loss of details or quality.

---------- Post added at 11:35 ---------- Previous post was at 11:34 ----------

Progress so far.

I've done the control surfaces and are now working to create the details such as cockpit, gear, hatches and etc.

---------- Post added Oct 29th, 2013 at 11:34 ---------- Previous post was Oct 28th, 2013 at 20:27 ----------

So last night I sketched this cockpit plan briefly. I don't know if all of it can be realized within Orbiter, e.g the conventional gauges.

The plan is partly inspired from Mig-29 and modern day glass cockpit fighters. I don't think it'll be comfortable for the pilot if I am to use the original 1944 cockpit design.

The layout is pretty basic. Under the HUD you can see autopilot panel and screen as well as some dials to adjust the brightness of the HUD. On the left beside it, there is the master warning and other warnings panel. On the right side top there's small standby ADI just in case of system failures and cockpit light switch and brightness control. Below it are three main MFDs for the flight operation. On the far left of the panel there's small clip for checklist and important reminders. On the far right there is flight clock, VOR/DME distance indicator, and digital fuel gauge. Below there are three big standby instruments, displaying airspeed, altimeter, vertical speed and AoA respectively. I don't know whether it's actually redundant because you got the HUD and the MFDs already, but I think it's pretty nice design. Just beside the airspeed indicator there's landing gear lights button.

On the left pedestal there are one primary FMC and the flight joystick as well as circuit breakers for the electrical system. On the right pedestal there are flaps, trims, landing gear lever, and the throttle for the engine. I believe it's also possible to reverse the configuration if necessary in the final design, to move the stick to the right. Radio and communication equipment is located just right beside the throttle with maybe further stacks to the back.

 

[Loru]

Analog style cockpit can be done in orbiter in at least 3 ways I'm aware of:

1. Each gauge indicator (needle)and switch has to be separate meshgroup (object) and is animated like any other mesh. In that case you have to note down every rotation point and axis you want to animate.

2. All gauges are single meshgroup sharing dynamic texture updated from VC code.

3. Mix of two above.

Universal note: each MFD screen and HUD has to be separate meshgroup (details in SDK docs)

Let me show you the example:


1. Each flip/flop switch is separate meshgroup here (well at least movable part)
2. Every button and led in this case is separate meshgroup with distinct material so they can be easily changed dpending on state (on/off)
3. Alarm display, Center fuel display and MFD buttons are sharing single dynamic (updatable) texture (however MFD buttons are using different material)
4. MFDs and HUD are separate meshgroups flagged accordingly in mesh file.
Rest of VC is static.

 

[Hielor]

Nice cockpit sketch. More Orbiter vessels with awesome 3d cockpits are always welcome.

That said...maybe swap the joystick and throttle. It's fairly standard in pretty much all single seat or tandem aircraft, regardless of nationality, to have the throttles be operated with the left hand and the joystick with the right (regardless of whether it's a sidestick or center stick). Having it be the other way would just be...awkward.

 

[Urwumpe]

I would flip both left and right console including sidestick and throttle. That way, the controls are following the usual conventions for western single seaters:

Communication radio gear is at the left side
Throttle and engine controls are on the left side
Navigation systems are at the right side
Electrical System is on the right side.

What you should remember: Having a light test button. This makes your development easier (since you can test if the lights illuminate correctly much easier). And it is pretty easy to add failing indicators to simulate some failures, compared to more complex problems to simulate.

The cockpit light controls are usually on one of the consoles (often the right one), since you rarely need to change the settings - the front cockpit should only have those indicators and controls that you really need every instant.

The further you go to the aft in the cockpit, the less often the controls and indicators are needed. Behind the seat, you might even have controls, that you only need to access on the ground.

The standby instruments are only needed once and can be combined into a lower number of instruments, since they are only needed in real emergencies:
1 STBY Attitude indicator
1 STBY Air speed indicator
1 STBY altitude indicator
1 STBY Variometer
1 STBY compass

"Too much information" can also happen in flight.

 

[teslax]

I would flip both left and right console including sidestick and throttle. That way, the controls are following the usual conventions for western single seaters:

Communication radio gear is at the left side
Throttle and engine controls are on the left side
Navigation systems are at the right side
Electrical System is on the right side.

...

Thanks for the information on the cockpit layout. I'll keep the convention in mind for the final design before modeling. The test button should really be there as you said because of it's usefulness.

I agree also that it makes a lot more sense to put the interior light control beside the pilot or in other less essential area. I thought if the pilot first enters the cockpit and it's dark or has too bright light then he would want to change that first instead of groping around in the dark.:facepalm:

Does fighter pilot normally uses their flood light though, or if there is one?

Is variometer and vertical speed indicator the same?

Nice cockpit sketch. More Orbiter vessels with awesome 3d cockpits are always welcome.

That said...maybe swap the joystick and throttle. It's fairly standard in pretty much all single seat or tandem aircraft, regardless of nationality, to have the throttles be operated with the left hand and the joystick with the right (regardless of whether it's a sidestick or center stick). Having it be the other way would just be...awkward.

Thanks.

I think the image Airbus cockpit got into my mind while I was drawing. The captain seat on the right has its control stick in the left and throttle on the right. I just realized that it isn't so in most single seat aircraft. Certainly this can be reverted.

Analog style cockpit can be done in orbiter in at least 3 ways I'm aware of:

1. Each gauge indicator (needle)and switch has to be separate meshgroup (object) and is animated like any other mesh. In that case you have to note down every rotation point and axis you want to animate.

2. All gauges are single meshgroup sharing dynamic texture updated from VC code.

3. Mix of two above.

Universal note: each MFD screen and HUD has to be separate meshgroup (details in SDK docs)

...

Ok I understand now that you need to have the moving parts separate from the non-moving part. It does seem sound a bit complicated but hopefully I can manage the coding part afterwards.

I have several questions for the cockpit and also for aircraft functionality. Is it possible for one aircraft to have one unique MFD program? Say for example this EICAS.

Most importantly, is it also possible just to add switches just for the sake of fun and role play? I mean the function might not be implemented to the aircraft but pilot can still click and adjust the button. Say, I add switch for the air condition or engine extinguisher and so on?

 

[Loru]

I have several questions for the cockpit and also for aircraft functionality. Is it possible for one aircraft to have one unique MFD program? Say for example this EICAS.

Yeah - you'd need to code wour own MFD but why not??

and yes - switches can be clickable/adjustable and have no function whatsoever.

 

[Urwumpe]

Yes, a variometer is an indicator for vertical speed.

Yeah - you'd need to code your own MFD but why not??

It would also be possible to make a generic MFD, that loads display scripts for a focused vessel and which could be scripted by Lua for preparing the data for the displays.

There is an ARINC standard for that, that uses binary or XML files for defining what you see on the display and how a program can interact with the display. While using all from ARINC including the referenced standards is a tiny bit over the top and expensive, it is a nice inspiration for creating such a standard for Orbiter.

(Theoretically, it would even be possible to implement such a standard in a modern SoC to create your own MFD for a simpit)


Also, in SSU, the VC framework can be used for defining switches for animation and interaction, without linking them to a subsystem, it is no problem, though the VC framework of SSU is not really that good as example anymore (Would need to be cleaned up and get cleaner interfaces for being useful somewhere else)

 

[PhantomCruiser]

Regarding cockpit lights...

All the ones that I'm familiar with didn't have "floodlights", but rather smaller individual lamps (maybe the size of a matchbox?) that had clear or red lenses, depending on conditions. All the buttons were backlit, and everything could be dimmed (or brightened) with variable control.

 

[teslax]

Yeah - you'd need to code wour own MFD but why not??

and yes - switches can be clickable/adjustable and have no function whatsoever.

Good to know that I can let my imagination runs wild.

Regarding cockpit lights...

All the ones that I'm familiar with didn't have "floodlights", but rather smaller individual lamps (maybe the size of a matchbox?) that had clear or red lenses, depending on conditions. All the buttons were backlit, and everything could be dimmed (or brightened) with variable control.

That makes sense. I don't see why fighter aircraft would want to have bright cockpit that can be seen form long distance, and I was previously referring to this kind of flood light. Feels pretty bright there.

http://www.airliners.net/photo/Calm-Air-International/Saab-340B/0288862/M/

 

[PhantomCruiser]

That does look like an overhead light. While this image is mostly outside flightdeck lighting...

You can see three of those "dashboard" lights I'd mentioned, the most obvious is right in the center.

I miss my old job

 

[4throck]

Ok I understand now that you need to have the moving parts separate from the non-moving part. It does seem sound a bit complicated but hopefully I can manage the coding part afterwards.

Simply model the parts separately. Each needle is a separate 3D object. Place it a few millimeters in from of the panel surface.
Model them reading maximum of whatever quantity they are supposed to measure, so that it looks nice even if not animated.

Look at my Buran OK-GLI cockpit mesh with working instruments ([ame="http://www.orbithangar.com/searchid.php?ID=6092"]http://www.orbithangar.com/searchid.php?ID=6092[/ame]), it's quite simple and was done in LUA + SC3. Be prepared to translate fuel kgs to rotation angles ! :lol:

---------- Post added at 17:05 ---------- Previous post was at 16:59 ----------

The plan is partly inspired from Mig-29 and modern day glass cockpit fighters. I don't think it'll be comfortable for the pilot if I am to use the original 1944 cockpit design. ....

It's your call, but at least texture it so that the devices look from the 50's. Look at old switches and early NASA control panels.
The X-20 is much latter, but you can use it as inspiration. The Apollo feel is evident, and it has a CRT display. Of course, the early CRTs were rounded...

The standard Orbiter MFDs will look out of place, but you can simulate a CRT display by using an appropriate texture, like I did here:
[ame="http://www.orbithangar.com/searchid.php?ID=5844"]http://www.orbithangar.com/searchid.php?ID=5844[/ame]

 

[Donamy]

Can you give me a place to find LUA scripting help ?

 

[Urwumpe]

Can you give me a place to find LUA scripting help ?

http://www.lua.org/

Additionally the examples of Orbiter with Lua.

 

[Donamy]

Hmmm looks like more time to learn, than I have to give.

 

[4throck]

Not that much to learn.

LUA is simply a script that will run over Orbiter, giving access to the API.

For logical or numeric operations, sure, you will be using LUA syntax, but for the rest, you will be using Orbiter's API.

Your best route is to start changing some existing scripts.
I used a very simple one for my Brazilian Space Program add-on. It induces roll to the VS-40 sounding rocket, based on dynamic pressure.
Quite simple to understand and useful for other projects :thumbup: