Heretic
Resource contributor
- Messages
- 6,830
- Country
I'm trying to bring Vit's Aero L-39C model from FSX into XP11. To make matters more complicated, I'm also learning Blender along the way.
This will not be a complete tutorial on anything involved in the process! If you're an absolute beginner to making models for MSFS, leave a few words of encourangement if you want to, but otherwise stay in read-only mode!
Despite achieving the same things XP and MSFS speak an entirely different language. Basic elements that can be used in both sims are:
Preparation:
The L-39C was modeled in GMax, but since there are no exporters for XP for that tool (plus certain incompatibilities to Windows 10), a compatible modeling tool is needed. Either 3ds Max with StepToSky or Blender with XPlane2Blender. Because Blender is freeware and by now well supported in MSFS and X-Plane alike, I chose the latter. For 3ds Max, Dino Cattaneo has written a tutorial on converting a model for X-Plane.
Setting up Blender and XPlane2Blender is fairly easy, having to know that
Getting the model ready for Blender was achieved by importing the latest MDL file of the L-39C into ModelConverterX, deleting anything that will not be needed in XP (custom light splashes, modeled effects or else) and exporting it as a Wavefront OBJ.
This, of course, kills all animations and visibilities present in the model, but at the same time at least forces me to study Blender's armature handling in greater detail.
Import into Blender:
This is pretty straightforward. Just import the OBJ file exported from MCX and make sure to set the axis orientations to "Y forward" and "Z up". Other than that, the 3D mesh, without its textures, will pop right up in the 3D view.
After that, parts should be renamed.
Materials:
X-Plane does not require an extensive material setup as MSFS. As far as I know, only three textures are required per material:
Note that the relative location of the texture files also determines the folder X-Plane an Plane Maker will look in! Loading the textures from the same folder that the BLEND file is in will prompt X-Plane to look in the same folder that the OBJ files are in later on. Loading the textures from a folder named, e.g. "Texture" will require having a folder named "Texture" at the same location as the output OBJ files!
Showing the textures on the model:
Here's a small pitfall I ran into. I don't know if it's due to the import or general blender handling, but I had to put a part from "Object" into "Edit" mode once and then, in the UV Editor, associate a valid texture with the mesh. Only after doing that would the texture show up in Blender, Plane Maker and X-Plane
Since this had to be done one part at a time, the process might become annoying pretty quickly. Fortunately, the L-39 only has around 120 relevant parts.
Also, setting Blender's shading options to "Multitexture" and turning on textured shading (ALT+Z) is akin to the small blue box in *Max. The former fortunately only needs to be done once while the latter can be used interchangeably with wireframe and shaded rendering (Z).
Layers/Hierarchy:
To make this short: All parts using the same material have to be located in the same scene layer, since they will be exported in a single OBJ file! So parts using, e.g. the fuselage material will have to be moved to layer 1, while parts using the "wings" material will have to be moved to layer 2, etc.
When adding new parts like bones to the model, watch the layer in which they are created as it should be the same as that of the part they're parented to!
The exporter can also deduct layering from the hierarchy, but I have not tried this (yet). I am pretty sure, however, that the same rule applies, i.e. one hierarchy stack per material.
Using layers also offers a method for quickly decluttering the scene.
The current exporter version (3.5.0) handles 20 scenes maximum, which subsequently imposes a limit of 20 materials per Blender file.
Another drawback is that complex animations, such as landing gear featuring parts using different materials, might require a workaround such as cloned bones to get around the layer limitations.
Exporting:
Getting the OBJ files out of Blender is pretty straightforward and surprisingly quick. Logging in the exporter should be enabled as it will produce a helpful text file.
The exporter allows to set a name for each layer, which in turn will be the name of the output OBJ file. When not dealing with cockpits (I'm not there yet), setting the type to "Aircraft (Part)" suffices.
Output of the OBJ files will occur at the location of the BLEND file. I did not manage to define a different path yet.
Getting the model into X-Plane:
Much as in MSFS, any texture mapped and animated 3D mesh is merely cosmetic. To have your 3D model show up in X-Plane, you will need to create a basic, untextured 3D model that is mainly used for the flight dynamics engin in X-Plane's Plane Maker. It's stored in an ACF file together with references to other objects and lots of systems or sound data. However, being as lazy as I am, I used a simple L-39C, made entirely in Plane Maker, as a basis.
Pre-made model or not, what you will have to do in Plane Maker is declare all parts your simple aerodynamic model as invisible for X-Plane ("Invisible Parts" menu) and then add all exported OBJ files to the model in the "Misc Objects" menu.
Note that the exported parts might not line up with the aerodynamic model, but setting an offset will fix this.
The relationship between 3D models and Plane Maker is covered in a bit more depth in Dino's tutorial.
X-Plane aircraft folder file structure:
This is a bit different from MSFS. You're free to set up any number of subfolders in XP11's "Aircraft" folder. Within your airplane's parent folder resides the ACF file that governs aerodynamics, systems, sounds, etc. plus all other resource folders used by the aircraft.
Your exported OBJ files will need to be located in a folder called "objects" within the airplane's parent folder, with the textures located at a relative location from that folder (see notes regarding materials).
A "liveries" folder governs aircraft liveries. In there, a folder named for the livery, e.g. "Red Stripes" contains an "objects" folder mimicking the same relative layout used by the main "objects" folder, but only containing textures that are relevant to the livery. Note that X-Plane simply distinguishes between liveries by the folder's name. No config file editing needed to make a livery show up.
The first impression:
Once all pitfalls had been cleared, the aircraft should show up in XP in all its basic glory, without visibilities and animations. The shaders already do some nice work, even without the magic of normal maps.
But what good is an inanimate object...
Animations:
X-Plane's handling of animations is a bit tricky and unusual. As far as I know, any animation using the world coordinate system can be done for the part itself, but parts requiring their own coordinate system, e.g. rudders require a parent object like an empty/helper or bone.
For the few parts I've animated so far, I've settled for bones to provide a local coordinate system. One or multiple bone provide the parent object(s) for the part(s) that need(s) to be animated. Once a bone setup was rigged and keyframes were created, the animation is tagged much like for MSFS.
In the bone's "Object Properties" tab, one needs to pick a dataref by either searching for one or pasting one found in the database (mind the index number for things like control surfaces or engines!). "Animation Type" should be "Transformation".
Each keyframe needs an assigned dataref output value, so it's best to load the aircraft in the simulator and use the DataRefTool or Plane Maker to find the usable output value range for the control or system in question.
So if an elevator has a maximum downward deflection of 30 degrees at keyframe 0, the value for keyframe 0 is -30. Keyframe 30, which might show neutral deflection, has a value of "0" and so on. After entering each value, the "key" icon needs to be clicked to add an X-Plane dataref value to the keyframe.
In the "Dope Sheet" view, all keyframes relevant to XP will be shown in an "XPlane Datarefs" line for the current armature's "ArmatureAction" section, which is useful to check that the assignments are present at the correct keyframes.
Note that this method enables compound animations without tons of helper/empty objects. If you, say, have a control yoke that translates and rotates, you'd add the translation to keyframes 0 to 40 and the rotation to keyframes 50 to 90 and then tag each keyframe range with the corresponding dataref and values.
For rotating objects such as wheels and knobs, the keyframing method corresponds to the one used for MSFS, although wheel type animations seem to be content with a keyframe at 0 and 90 degrees of rotation and a corresponding dataref value at each (untested yet).
Animation loops, such as "Tick17" or "Ambient" in FSX are also possible if the right loop cutoff value is specified.
Custom datarefs may of course be used, but will have to be defined externally, e.g. by a plugin or LUA file.
The conclusion so far:
It's a learning curve and involves tons of googling and the occasional exclamation of frustration, but so far, I'm pretty content with having broken new ground in both Blender and X-Plane.
This is where I'm at at the moment:
Note the undeflected elevator and rudder, which means that I've successfully implemented those animations (parts are stuck at keyframe 0 when exporting as OBJ from MCX, as can be seen on the ailerons).
I don't know how far I can take this and if I can keep up the motivation, but my goal is to have all the basics covered. There's still tons of ground to (dis)cover. Visibilities, 3D cockpit models, gauges, systems, sounds and performance figures are still question marks.
Hope this will provide some inspiration to inquisitive minds and spur some efforts to bring some more content into X-Plane.
This will not be a complete tutorial on anything involved in the process! If you're an absolute beginner to making models for MSFS, leave a few words of encourangement if you want to, but otherwise stay in read-only mode!
Despite achieving the same things XP and MSFS speak an entirely different language. Basic elements that can be used in both sims are:
- 3D mesh with UV maps and keyframe animations
- Diffuse textures (DDS format, but without vertical flipping as required for FSX/P3D!)
- Some gauge bitmaps (if in PNG or DDS format?)
- WAV files from the sound set
Preparation:
The L-39C was modeled in GMax, but since there are no exporters for XP for that tool (plus certain incompatibilities to Windows 10), a compatible modeling tool is needed. Either 3ds Max with StepToSky or Blender with XPlane2Blender. Because Blender is freeware and by now well supported in MSFS and X-Plane alike, I chose the latter. For 3ds Max, Dino Cattaneo has written a tutorial on converting a model for X-Plane.
Setting up Blender and XPlane2Blender is fairly easy, having to know that
Getting the model ready for Blender was achieved by importing the latest MDL file of the L-39C into ModelConverterX, deleting anything that will not be needed in XP (custom light splashes, modeled effects or else) and exporting it as a Wavefront OBJ.
This, of course, kills all animations and visibilities present in the model, but at the same time at least forces me to study Blender's armature handling in greater detail.
Import into Blender:
This is pretty straightforward. Just import the OBJ file exported from MCX and make sure to set the axis orientations to "Y forward" and "Z up". Other than that, the 3D mesh, without its textures, will pop right up in the 3D view.
After that, parts should be renamed.
Materials:
X-Plane does not require an extensive material setup as MSFS. As far as I know, only three textures are required per material:
- Diffuse/albedo (alpha channel always controls transparency!)
- Night
- Normal (height data plus specularity in the alpha channel)
Note that the relative location of the texture files also determines the folder X-Plane an Plane Maker will look in! Loading the textures from the same folder that the BLEND file is in will prompt X-Plane to look in the same folder that the OBJ files are in later on. Loading the textures from a folder named, e.g. "Texture" will require having a folder named "Texture" at the same location as the output OBJ files!
Showing the textures on the model:
Here's a small pitfall I ran into. I don't know if it's due to the import or general blender handling, but I had to put a part from "Object" into "Edit" mode once and then, in the UV Editor, associate a valid texture with the mesh. Only after doing that would the texture show up in Blender, Plane Maker and X-Plane
Since this had to be done one part at a time, the process might become annoying pretty quickly. Fortunately, the L-39 only has around 120 relevant parts.
Also, setting Blender's shading options to "Multitexture" and turning on textured shading (ALT+Z) is akin to the small blue box in *Max. The former fortunately only needs to be done once while the latter can be used interchangeably with wireframe and shaded rendering (Z).
Layers/Hierarchy:
To make this short: All parts using the same material have to be located in the same scene layer, since they will be exported in a single OBJ file! So parts using, e.g. the fuselage material will have to be moved to layer 1, while parts using the "wings" material will have to be moved to layer 2, etc.
When adding new parts like bones to the model, watch the layer in which they are created as it should be the same as that of the part they're parented to!
The exporter can also deduct layering from the hierarchy, but I have not tried this (yet). I am pretty sure, however, that the same rule applies, i.e. one hierarchy stack per material.
Using layers also offers a method for quickly decluttering the scene.
The current exporter version (3.5.0) handles 20 scenes maximum, which subsequently imposes a limit of 20 materials per Blender file.
Another drawback is that complex animations, such as landing gear featuring parts using different materials, might require a workaround such as cloned bones to get around the layer limitations.
Exporting:
Getting the OBJ files out of Blender is pretty straightforward and surprisingly quick. Logging in the exporter should be enabled as it will produce a helpful text file.
The exporter allows to set a name for each layer, which in turn will be the name of the output OBJ file. When not dealing with cockpits (I'm not there yet), setting the type to "Aircraft (Part)" suffices.
Output of the OBJ files will occur at the location of the BLEND file. I did not manage to define a different path yet.
Getting the model into X-Plane:
Much as in MSFS, any texture mapped and animated 3D mesh is merely cosmetic. To have your 3D model show up in X-Plane, you will need to create a basic, untextured 3D model that is mainly used for the flight dynamics engin in X-Plane's Plane Maker. It's stored in an ACF file together with references to other objects and lots of systems or sound data. However, being as lazy as I am, I used a simple L-39C, made entirely in Plane Maker, as a basis.
Pre-made model or not, what you will have to do in Plane Maker is declare all parts your simple aerodynamic model as invisible for X-Plane ("Invisible Parts" menu) and then add all exported OBJ files to the model in the "Misc Objects" menu.
Note that the exported parts might not line up with the aerodynamic model, but setting an offset will fix this.
The relationship between 3D models and Plane Maker is covered in a bit more depth in Dino's tutorial.
X-Plane aircraft folder file structure:
This is a bit different from MSFS. You're free to set up any number of subfolders in XP11's "Aircraft" folder. Within your airplane's parent folder resides the ACF file that governs aerodynamics, systems, sounds, etc. plus all other resource folders used by the aircraft.
Your exported OBJ files will need to be located in a folder called "objects" within the airplane's parent folder, with the textures located at a relative location from that folder (see notes regarding materials).
A "liveries" folder governs aircraft liveries. In there, a folder named for the livery, e.g. "Red Stripes" contains an "objects" folder mimicking the same relative layout used by the main "objects" folder, but only containing textures that are relevant to the livery. Note that X-Plane simply distinguishes between liveries by the folder's name. No config file editing needed to make a livery show up.
The first impression:
Once all pitfalls had been cleared, the aircraft should show up in XP in all its basic glory, without visibilities and animations. The shaders already do some nice work, even without the magic of normal maps.
But what good is an inanimate object...
Animations:
X-Plane's handling of animations is a bit tricky and unusual. As far as I know, any animation using the world coordinate system can be done for the part itself, but parts requiring their own coordinate system, e.g. rudders require a parent object like an empty/helper or bone.
For the few parts I've animated so far, I've settled for bones to provide a local coordinate system. One or multiple bone provide the parent object(s) for the part(s) that need(s) to be animated. Once a bone setup was rigged and keyframes were created, the animation is tagged much like for MSFS.
In the bone's "Object Properties" tab, one needs to pick a dataref by either searching for one or pasting one found in the database (mind the index number for things like control surfaces or engines!). "Animation Type" should be "Transformation".
Each keyframe needs an assigned dataref output value, so it's best to load the aircraft in the simulator and use the DataRefTool or Plane Maker to find the usable output value range for the control or system in question.
So if an elevator has a maximum downward deflection of 30 degrees at keyframe 0, the value for keyframe 0 is -30. Keyframe 30, which might show neutral deflection, has a value of "0" and so on. After entering each value, the "key" icon needs to be clicked to add an X-Plane dataref value to the keyframe.
In the "Dope Sheet" view, all keyframes relevant to XP will be shown in an "XPlane Datarefs" line for the current armature's "ArmatureAction" section, which is useful to check that the assignments are present at the correct keyframes.
Note that this method enables compound animations without tons of helper/empty objects. If you, say, have a control yoke that translates and rotates, you'd add the translation to keyframes 0 to 40 and the rotation to keyframes 50 to 90 and then tag each keyframe range with the corresponding dataref and values.
For rotating objects such as wheels and knobs, the keyframing method corresponds to the one used for MSFS, although wheel type animations seem to be content with a keyframe at 0 and 90 degrees of rotation and a corresponding dataref value at each (untested yet).
Animation loops, such as "Tick17" or "Ambient" in FSX are also possible if the right loop cutoff value is specified.
Custom datarefs may of course be used, but will have to be defined externally, e.g. by a plugin or LUA file.
The conclusion so far:
It's a learning curve and involves tons of googling and the occasional exclamation of frustration, but so far, I'm pretty content with having broken new ground in both Blender and X-Plane.
This is where I'm at at the moment:
Note the undeflected elevator and rudder, which means that I've successfully implemented those animations (parts are stuck at keyframe 0 when exporting as OBJ from MCX, as can be seen on the ailerons).
I don't know how far I can take this and if I can keep up the motivation, but my goal is to have all the basics covered. There's still tons of ground to (dis)cover. Visibilities, 3D cockpit models, gauges, systems, sounds and performance figures are still question marks.
Hope this will provide some inspiration to inquisitive minds and spur some efforts to bring some more content into X-Plane.
