FS2004 aircraft mdl export

[arno]

That was the FSX version. MDL file attached. It started out as an FS9 model I converted to FSX using the old MCX. It originally used c_wheel in the FS9 model. I don't know why MCX created a custom animation for it.

OK, I'll check that model as well.

It was not reflective in FSX, due to the Reflection Scale being set to 0. I use 0.8 which seems to give about the same amount of reflection it had in FS9 (but quite inferior in appearance in my opinion). It uses a non-default environment file, globalenv_ac_chrome.dds.

I'll modify the default value to something better.

The DC-6B model is set for 229,229,229 in GMAX, as are most of my planes. When I load it into MCX it displays 0,0,0 in the material editor.

OK, I'll check, sounds like a bug in MCX.

That apparently works fine for FS9, but not for FSX.

Seems so, I'll have to revert the change so that FSX works again and then see if I can get the FS2004 export working again.

No, the Specular Texture slot is blank. I don't know why there needs to be anything there? It has nothing to do with reflection, I believe?

If the texture used has an alpha channel (which I suspect is the case), FS2004 will use it for transparency, unless a reflection map is specified in the material as well. That's why if you add the same texture in the specular texture slot as well that it is no longer transparent. Or the alpha channel would have to be removed.
In FSX the blend masks can be modified to ignore the alpha channel, but that is not possible in FS2004.

 

[tgibson]

I had some issues before that the prop animations and visibility conditions got detached from each other. That gave issues when I exported the DC-6B to a FS2004 MDL file. To solve that I kept them together now. But I think you are referring to FSX export here and you mean the visibility conditions are not working correctly in that case. So I guess I need to change this again.

Perhaps this is a problem I’ve seen before. Does the plane look something like this?

with the animated parts displaced to the center of the plane? This often happens to me when converting FS9 aircraft to FSX and later sims. What often fixes this issue is Importing this problem plane into MCX and Exporting it again. Then it displays correctly:

When reloaded into MCX the animations must appear correct - if they are displayed as displaced in MCX then this technique will not fix that.

It would be interesting to compare the X and/or the .asm files of the two versions and check for any differences. That might give you a clue as to the problem?

Another hint might be that this problem was seen early on after FSX was released and it was found that it could be solved by linking the top object in any animated group of parts to a non-animated part. Any animated part not so linked would be displaced to the center of the plane.

So you might want to try the Export-Import-Export trick and see if that works for you. If it can’t be fixed within MCX you could always pop up an information box to the user and tell them to do it.

 

[tgibson]

If the texture used has an alpha channel (which I suspect is the case), FS2004 will use it for transparency, unless a reflection map is specified in the material as well. That's why if you add the same texture in the specular texture slot as well that it is no longer transparent. Or the alpha channel would have to be removed.
In FSX the blend masks can be modified to ignore the alpha channel, but that is not possible in FS2004.

I can confirm that adding the diffuse texture name to the Specular Texture slot makes the material reflective and not transparent, so that is user fixable, at least.

 

[tgibson]

Greg, I'm confused. Does the AI aircraft use _L or _LM textures? If _L, that should be specified in the Emissive Texture slot. But in my hands LightMaps are not yet being handled properly, so you will probably have to wait for that.

 

[gapeters]

Well the initial conversion (FSX to FS9) lists a _l extension dds. With that converted and loaded in the sim, the plane just has no texture and just the grey model. When I remove that emissive extension listed (like most AI aircraft show in MCX, nothing there) then the plane displays correctly day and night but will not show the _l lighmap (windows and tail splash etc). So maybe we are not quite there as you mentioned just was curious. So I will wait patiently. Thanks

Greg

 

[tgibson]

Did you change the MCX emissive slot from dds to bmp?

 

[gapeters]

Yes I changed it thinking that would be the trick and it shows a blank grey model still/as well . If you look at a native FS9 AI model in MCX there is nothing listed texture wise in that Emissive slot. Its just empty. So not sure exactly how or where _l textures are assigned.

Greg

 

[tgibson]

Is the AI plane available for us to look at?

 

[arno]

MCX does not differentiate between light map and night map yet. For FSX this is controlled by a material attribute (forgot the name now), but I need to make sure it is defined in the fs2004 x file correctly as well.

 

[gapeters]

Thanks Arno. Will wait until that seems to be addressed. Otherwise, so far so good in a couple of attempts. Will keep playing around with it!

Greg

 

[arno]

Hi,

I have fixed the nightmap vs lightmap issue now, so in the next development release that will work.

@tgibson, in FSX we can set only animation or visibility condition on a node. Can that be done for FS2004 as well? I have reverted the change I made to the visibility condition optimization so that FSX MDL files export correctly with the vsibility condtions again. But now I need to make sure the FS2004 model exports fine as well. With the visibility condtions on the model parts, it can be that the animation of the prop is one or two nodes higher on a scenegraph node. But since the animation and visibility condition have the same name, the visibility condition is applied at the node of the animation as well. Hence the question if they can be assigned seperately?

 

[tgibson]

I think the answer is yes, but keep reading in case I do not understand you, and for a limitation.

When I load the FS9 CV-440 plane into MCX the blurred prop uses a still prop animation tag and a blurred prop visibility tag, both on the SceneGraphNode, not on the ModelPart. This is OK since the still/slow/blurred prop animations are the same. This exports OK. However, if I set the blurred visibility condition in the ModelPart and remove it from the SceneGraphNode, the resulting blurred prop in FS9 never appears - it never displays no matter the prop rpm.

BUT, if I reassign the animation to prop_blurred (so it matches the visibility condition), it DOES appear in the sim. Therefore, you CAN split the visibility and animation of props between SceneGraphNodes and ModelParts, BUT they must match - i.e. be identical tags. I tested this with the slow and still props and they all need to match to display.

BUT, I also have lever_prop_pitch animations on the prop blades (so they change pitch visually), which are linked to the prop hub (which is the prop_still part). This arrangement works OK:

SGN = SceneGraphNode
MP = ModelPart
A = animation
V = visibility condition

SGN (a = prop_still)
__MP (prop hub0 (v=prop_still)
__SGN (a = lever_prop_pitch)
____MP (prop blade 1) (v = prop_still)
__SGN (a = lever_prop_pitch)
____MP (prop blade 2) (v = prop_still)
__SGN (a = lever_prop_pitch)
____MP (prop blade 3) (v = prop_still)

So it appears that non-prop animations can be mixed and it still work OK. Only the still/slow/blurred animations and visibilities must match.

Hope this helps,

 

[arno]

Hi Tom,

Thanks, but if you let the names of the animation and visibility condition match like you did, then actually the visibility condition is already on the SGN that has the animation assigned. The fact that the condition is also on the MP below it does not matter anymore. So I guess for FS2004 I have to move them together again (like I did with the change that broke the FSX export).

 

[tgibson]

I don’t quite understand what you said above, there is no visibility condition set on any SGN in my tests, they are all on the MPs. The SGNs only have animations set. But if that somehow causes SGNs to acquire a visibility condition from a linked MP below it in some way then I guess that’s something I didn’t know was possible?

 

[arno]

In the FS2004 X file you can only use the name of the animation/visibility condition on a node or part. So if you assign a certain prop animation you automatically get the visibility condition with it. That's why I asked if they can be assigned separately in gmax.

But I have been working on some changes this morning already and I think I'll get it working without breaking FSX.

 

[tgibson]

Ah, OK I didn’t understand the question. In GMAX you just name the prop part prop0_still (for example) and the compiler adds the animation and visibility condition to the part when compiling. You don’t need key frames or anything else. I have never checked if there is a way to do that with a key frame animated part instead, so I don’t know about that.

But AFAIK there is no way to assign more than one tag to a part - animation or visibility. The way you assign tags is by naming the part the name of the tag. So if the animation and visibility tags have the same name you would get both, I assume. The way we got around this was to link parts together so they inherited the parent part’s tag.

I also assume this is one reason why MS changed the tagging system in FSX and beyond, to allow more flexibility in assigning tags.

 

[arno]

Ok, I think I have a useful way now to export. So let's see if that works.

 

[arno]

I have pushed a new development release now. It should address most of the issues mentioned above, except for the animations that are reversed and the VC.

 

[tgibson]

Looks like we are getting close with these issues! Using this latest development version:

Converting FS9 CV-440 to FSX. (Import, FS9 plane MDL, immediately Export Object as FSX MDL file).
1. The blurred props are not transparent if you load an MDL file without textures. Using Set Default Transparent on the material fixes that. Loading an MDL that also loads its textures works OK.
2. The light map is always present, day and night. It cannot be controlled with the light switch. The materials' Emissive Mode properties are set to Additive, when they could be AdditiveNightOnlyUserControlled to fix that.
3. Right engine prop blade twist animation is OK (see below).
4. Animations OK.

Converting FSX CV-440 to FS9.
1. The plane is transparent, rather than reflective. When loaded into MCX the converted plane is transparent as well. Adding the diffuse texture name into the Specular Texture slot fixes this.
2. The areas where the LightMap texture has a black alpha (controlled by the light switch) is transparent at night. Adding the diffuse texture name into the Specular Texture slot fixes this.

Perhaps MCX could add the diffuse texture name to the Specular Texture slot when the material is supposed to be reflective?

3. The prop blade twist animation of the right engine is only one half of what it should be (lever_prop_pitch). The left engine is fine. Both are OK in the original model.
4. Other animations OK except for prop and wheel rotations, which are backwards (already known).

Converting FS9 CV-440 to FS9.
1. The plane is reflective, with the diffuse texture name already present in the Specular Texture slot if reflective. Good.
2. The prop blade twist animation of the right engine is only one half of what it should be (lever_prop_pitch). The left engine is fine. Both are OK in the original model.
3. Other animations OK except for prop and wheel rotations, which are backwards (already known).

Thanks,

 

[arno]

Hi Tom,

1. The blurred props are not transparent if you load an MDL file without textures. Using Set Default Transparent on the material fixes that. Loading an MDL that also loads its textures works OK.

There is nothing I can do about that. To set the correct material attributes MCX has to be able to find the texture, so that it can check if there is an alpha channel or not. Without having a texture MCX can not automatically set the right properties for a transparent texture.

2. The light map is always present, day and night. It cannot be controlled with the light switch. The materials' Emissive Mode properties are set to Additive, when they could be AdditiveNightOnlyUserControlled to fix that.

I did use Additive as emission mode indeed, I'll change it to AdditiveNightOnlyUserControlled insstead as that seems a better default value.

1. The plane is transparent, rather than reflective. When loaded into MCX the converted plane is transparent as well. Adding the diffuse texture name into the Specular Texture slot fixes this.

Does the FSX model have any material settings that indicate there is a reflection and no transparency that I am missing on import? At this moment I don't see a way to manually detect this, as it seems there is no specular texture set for FSX. Or is the blend environment by inverse diffuse alpha setting set on the material maybe?

2. The areas where the LightMap texture has a black alpha (controlled by the light switch) is transparent at night. Adding the diffuse texture name into the Specular Texture slot fixes this.

Is that controlled by the lightmap? Or is this the same symthom as you described in 1. above? E.g. does the alpha come from the diffuse texture?

Perhaps MCX could add the diffuse texture name to the Specular Texture slot when the material is supposed to be reflective?

But how should MCX know it is supposed to be reflective? There needs to be some material setting for that then.

3. The prop blade twist animation of the right engine is only one half of what it should be (lever_prop_pitch). The left engine is fine. Both are OK in the original model.
2. The prop blade twist animation of the right engine is only one half of what it should be (lever_prop_pitch). The left engine is fine. Both are OK in the original model.

I have seen weird things on the DC-6 with the prop twist as well. In MCX it looks OK, but when exporting to FS2004 MDL not anymore. I need to check what causes that.

4. Other animations OK except for prop and wheel rotations, which are backwards (already known).
3. Other animations OK except for prop and wheel rotations, which are backwards (already known).

Indeed, I am working on that. I have some idea on how to fix this already.