FS2004 aircraft mdl export

[arno]

Ok, let me check that further. Seems like they are doubled already in the x file then.

 

[tgibson]

I think they appear to be doubled because there are two objects (triangles) that make up each light. I don’t know what MakeMDL does with that, and I have no way of knowing exactly what is in the MDL file. Since the two triangles are typically identical objects in the same position it’s hard to know. If necessary I could try to make them unique if it helps.

 

[arno]

I think you get a light already with one triangle, that also how I always made lights for scenery on FS2004. Not sure why two are needed for a lighting light, but I guess that's just how it is.

 

[tgibson]

As far as I know the two object requirement was only for landing and taxi light splashes, not for regular lights.

 

[arno]

I did some testing yesterday and at least for the landing and taxi lights they are doubled in the MDL file. They are once drawn with the alpha parts of the model and once again with the normal parts. So when reading the MDL back MCX has to ensure these two light points are combined into one, else you keep doubling the amount on import/export.

 

[tgibson]

Glad you figured it out. I never understood why GMAX needed the two object requirement.

 

[arno]

Hi Tom,

Why you need two triangles in GMax I don't understand yet. For my test I used one object in GMax tagged as landing light. That results in two lights in the ASM code and in the MDL file. The same for the taxi light. But when I made a strobe or nav light only one light is generated in the MDL file.

In your example with two triangle, you had 4 lights for each of the landing lights in the MDL file. So each triangle seems to give its own light point (which is duplicated again for alpha and non alpha).

 

[tgibson]

It might have just been a bug in the compiler, there were lots of those.

 

[arno]

I have pushed a new development release today. The main improvements are that lights are now written to fs2004 aircraft as well.

I have also improved the reading of the lights from the MDL files. There is a new light_mapping.ini file that can be used to tweak which lights are converted to which effect for fax and vice versa. It's similar to the animation mapping file and allows the user to tweak how the conversation is done. If I am missing certain mappings that should be default, let me know and I can add them.

 

[tgibson]

Hi,

Tried out the landing lights first.. FS9 DC-6B to FS9 DC-6B.
1. There are only two attachpoints in the plane, very good.
2. The landing light attachpoints now seem to be loaded in the correct position, so that's great.
3. The resulting landing lights do indeed give a splash on the ground, so good.
4. The landing lights are rotated by 180 deg. - they are pointed up when they should be pointed down, and pointed back when they should be pointed forward.
5. Changing any of the the rotation values in the Attached Object Editor makes no difference to the orientation of the light splash or the "bulb" - they are always 180 deg. from the desired orientation.
6. Changing the position values in the Attached Object Editor only moves the light "bulb", it does not move the light splash. And by default they are not exactly aligned with each other left/right. The light splash is a few feet outboard from the bulb.
7. Deleting the attachpoint deletes the bulb and splash.
8. By the way the prop animation is actually worse, the prop blades (lever_prop_pitch animation) now rotate when the prop itself rotates (prop_still).

FS9 DC-6B to FSX DC-6B:
1. Only two attachpoints at the right location, good.
2. The landing lights are pointed 90 degrees upward; the green axis needs to be pointed forward. The Attached Object Editor can fix that with (-90.00:0.00:0.00).
3. The water rudder animation needs to be reversed (they are opposite in FS9 vs FSX).
4. The nosewheel steering using c_wheel is incorrect (they are different between FS9 and FSX).

FSX DC-6B to FS9 DC-6B:
1. All the materials set to MultiplyBlendUserControlled are set to Blend in the exported FS9 model, and areas with a black alpha channel in the night texture are transparent at night. AdditiveNightOnlyUserControlled is a better choice.
2. The attachpoints appear to have moved about a foot down from the FSX location.
3. The landing lights are rotated by 180 deg., although the alignment of the bulb and splash to the attachpoint appears to be correct.
4. The custom visibility conditions are not retained, they revert to None.
5. The prop rotation and prop blade rotation are not correct, the same as in the FS9 to FS9 conversion.

FSX DC-6B to FSX DC-6B:
1. The first time I exported, all the animated parts were moved to the center of the plane. The "import the converted model then export it" trick fixed that.
2. The landing lights are rotated 90 deg. upward, the green axis needs to be pointing forward.
3. The bulbs and splashes are offset about 6 inches to the right of the attachpoint.

Hope this helps,

 

[arno]

Hi Tom,

Thanks for testing again.

4. The landing lights are rotated by 180 deg. - they are pointed up when they should be pointed down, and pointed back when they should be pointed forward.

Let me check what is going on there.

5. Changing any of the the rotation values in the Attached Object Editor makes no difference to the orientation of the light splash or the "bulb" - they are always 180 deg. from the desired orientation.

Weird that changing the values has no effect, let me look into that. Sounds almost like the light has a default orientation, just like some of the animation have.

6. Changing the position values in the Attached Object Editor only moves the light "bulb", it does not move the light splash. And by default they are not exactly aligned with each other left/right. The light splash is a few feet outboard from the bulb.

That's interesting, the light and the splash are generated from the same light, so why would one move and the other not.

8. By the way the prop animation is actually worse, the prop blades (lever_prop_pitch animation) now rotate when the prop itself rotates (prop_still).

I did not change that bit, but it is on the list to check the animation distortion.

2. The landing lights are pointed 90 degrees upward; the green axis needs to be pointed forward. The Attached Object Editor can fix that with (-90.00:0.00:0.00).

I need to check the orientations.

3. The water rudder animation needs to be reversed (they are opposite in FS9 vs FSX).

OK, let me add that to the conversion.

4. The nosewheel steering using c_wheel is incorrect (they are different between FS9 and FSX).

What should the nose wheel steering be then?

1. All the materials set to MultiplyBlendUserControlled are set to Blend in the exported FS9 model, and areas with a black alpha channel in the night texture are transparent at night. AdditiveNightOnlyUserControlled is a better choice.

The FS2004 exporter does not write a nightmap for any material that has a blend variation. When an additive variation is used a night map is exported. That was the best mapping I could come up with, as FS2004 only has two types, while FSX has 7 types of emissive mode.

3. The landing lights are rotated by 180 deg., although the alignment of the bulb and splash to the attachpoint appears to be correct.

Same as above it seems, I need to check the orientation.

4. The custom visibility conditions are not retained, they revert to None.

All of them or on certain nodes?

 

[tgibson]

What should the nose wheel steering be then?'

I'm not sure how you want to handle this - the animation keyframes are different for each one. Thus for "real" FSX models I assume your conversion may work OK - I have never created a "real" FSX model to test (I might be able to try a default plane?). My FSX models have been converted from FS9 using a custom xml in the modeldef file so the wheel turns properly when converted to FSX.

Default FSX c_wheel:

    <PartInfo>
        <Name>c_wheel</Name>
        <AnimLength>200</AnimLength>
        <Animation>
            <Parameter>
          <Code>
            (A:GEAR CENTER STEER ANGLE, grads) 0 &gt; if{ (A:GEAR CENTER STEER ANGLE, grads) 0.5 * } els{ (A:GEAR CENTER STEER ANGLE, grads) 0.5 * 200 + }
          </Code>
            </Parameter>
        </Animation>
    </PartInfo>

My custom code to convert FS9 models to FSX:

    <PartInfo>
        <Name>c_wheel_FS9</Name>
        <AnimLength>200</AnimLength>
        <Animation>
            <Parameter>
          <Code>
            (A:GEAR CENTER STEER ANGLE, grads) 0 &gt; if{ (A:GEAR CENTER STEER ANGLE, grads) 0.5 * 100 + } els{ (A:GEAR CENTER STEER ANGLE, grads) 0.5 * 200 + }
          </Code>
            </Parameter>
        </Animation>
    </PartInfo>

The FS2004 exporter does not write a nightmap for any material that has a blend variation. When an additive variation is used a night map is exported. That was the best mapping I could come up with, as FS2004 only has two types, while FSX has 7 types of emissive mode.

I have never seen Blend used in an FS9 aircraft model, it just doesn't make any sense. Thus my thought that AdditiveNightOnlyUserControlled would be a better default choice for any UserControlled material in FSX when converting to FS9.

All of them or on certain nodes?

All of them are gone. You should be able to see that by loading the FSX DC-6B into MCX and checking for any custom visibility conditions (I search for chock and then custom - neither appear).

Hope this helps,

 

[arno]

Hi Tom,

I'm not sure how you want to handle this - the animation keyframes are different for each one. Thus for "real" FSX models I assume your conversion may work OK - I have never created a "real" FSX model to test (I might be able to try a default plane?). My FSX models have been converted from FS9 using a custom xml in the modeldef file so the wheel turns properly when converted to FSX.

OK, I'll check what I can do in the conversion. So what you do is use your custom definition instead of the default FSX one and then you keep the animations like it is for FS2004?

I have never seen Blend used in an FS9 aircraft model, it just doesn't make any sense. Thus my thought that AdditiveNightOnlyUserControlled would be a better default choice for any UserControlled material in FSX when converting to FS9.

Are you saying that any UserControlled emissive mode should be converted to a light map? Now my thinking is that nightmap is like blend (according to the SDK) and a light map is additive. Hence the mapping I now make, but that can be changed of course.

All of them are gone. You should be able to see that by loading the FSX DC-6B into MCX and checking for any custom visibility conditions (I search for chock and then custom - neither appear).

I'll check again. So you loaded your FSX DC-6B and after conversion with MCX the visibility conditions are lost? Because when I just load the model without exporting it in MCX they are there:

Edit: And also after exportin to FS2004 MDL and importing it again I still see the visibility condition on the blocks.

Another question, to be able to check the orientation of the landing lights I wanted to make a simple test object that has a
A few landing lights pointing in different directions. I was thinking like center light pointing ahead and the other two tilted inwards and downwards a bit (see image). But whatever I try in GMax, they always point in the same (default) direction. Any tips on how to setup such a test object?

 

[tgibson]

Hi Tom,

OK, I'll check what I can do in the conversion. So what you do is use your custom definition instead of the default FSX one and then you keep the animations like it is for FS2004?

Correct. What I do is before conversion to FSX is I change the c_wheel animation tag to c_wheel_fs9 and then convert. Now that I think about it I’m not sure whether the key frames are actually different, but there is a factor of 100 difference in the tag codes.

Are you saying that any UserControlled emissive mode should be converted to a light map? Now my thinking is that nightmap is like blend (according to the SDK) and a light map is additive. Hence the mapping I now make, but that can be changed of course.

I know of a total of one FS9 aircraft that used nightmaps (LM textures), all the rest used light maps. So using blend *for aircraft* is probably not very useful.

I'll check again. So you loaded your FSX DC-6B and after conversion with MCX the visibility conditions are lost? Because when I just load the model without exporting it in MCX they are there:

Edit: And also after exportin to FS2004 MDL and importing it again I still see the visibility condition on the blocks.

I’ve mentioned this before that we are seeing different things here, and I said I suspected a difference in our MCX Options.

Another question, to be able to check the orientation of the landing lights I wanted to make a simple test object that has a
A few landing lights pointing in different directions. I was thinking like center light pointing ahead and the other two tilted inwards and downwards a bit (see image). But whatever I try in GMax, they always point in the same (default) direction. Any tips on how to setup such a test object?

You need to create another identical cube for each light, and parent one to the other. The parent controls the orientation (but is deleted in the final model), and the child is converted to a light. That‘s why there appears to be two of each in the X file. BTW MS suggested using triangle polygons for this purpose, although I think any shape will work. Normally you just make a copy of the object and leave it in an identical location. Link them, then move the parent to the desired orientation. Don’t forget to name the material properly.

Hope this helps,

 

[arno]

Correct. What I do is before conversion to FSX is I change the c_wheel animation tag to c_wheel_fs9 and then convert. Now that I think about it I’m not sure whether the key frames are actually different, but there is a factor of 100 difference in the tag codes.

OK.

I know of a total of one FS9 aircraft that used nightmaps (LM textures), all the rest used light maps. So using blend *for aircraft* is probably not very useful.

That would be another approach. Now I am only using the emissive mode to determine if a write a lightmap or a nightmap. But I could also always write a lightmap when exporting an aircraft (and always a nightmap in scenery).

I’ve mentioned this before that we are seeing different things here, and I said I suspected a difference in our MCX Options.

I guess so. Do you know if you have some of the optimize settings not on their default values?

You need to create another identical cube for each light, and parent one to the other. The parent controls the orientation (but is deleted in the final model), and the child is converted to a light. That‘s why there appears to be two of each in the X file. BTW MS suggested using triangle polygons for this purpose, although I think any shape will work. Normally you just make a copy of the object and leave it in an identical location. Link them, then move the parent to the desired orientation. Don’t forget to name the material properly.

I get the lights to export, that's no problem (I see them in the ASM code and MDL file). But I can't make them tilt or alter the direction. I rotated the dummy object and also tried rotating the pivot of the dummy object, but none of that has an effect.

 

[tgibson]

If you are using true Dummy objects I don't think that will work, they may need to have geometry and use the light_land material. I've attached my GMAX landing light test object, perhaps that will help? Landing lights are very tricky and I just copy and paste working ones into any new models. These are animated using the Water Rudder tag (Shift W in FS9, Ctrl W if using FSX). Feel free to remove that, the taxi lights, and the extra LOD cubes to simplify it. I can do that if you need me to.

Note that in the light_land and light_taxi materials use the diffuse color for the color of the lights, and the Opacity value for the brightness of the lights. Higher is brighter.

Sorry about all the extra unused materials, I forgot to remove them. To do that start a new blank GMAX file, File/Merge, choose the test object, select all the parts, and click Merge. Save as a new version. i don't think it matters to the X or MDL files though.

 

[tgibson]

I tried pressing the Reset All to Default button on the Options dialog box and that didn't change the behavior, it still does not include the chocks visibility condition at all when I go from FSX model to FS9 model. I'm at a loss...

PS. Pressing this button changes the Use Conditions parameter to UserSpecified, I assume that should be defaulted to VisibilityCondition when this process is complete?

 

[tgibson]

I looked at some GMAX models for landing and taxi lights that are not animated to refresh my memory.

The orientation is not set by the direction of the geometry, but instead it is the GMAX Pivot Point that determines that. Access that via Heirarchy tab on the upper right of the screen, Affect Pivot Only. Then rotate it as desired. The pivot needs to be oriented so the blue arrow is in the *opposite* direction of the desired light splash (i.e. facing backwards).

 

[tgibson]

Here is a tutorial for creating light splashes in GMAX for FS9. It uses an older version of GMAX but it should give you the idea.

GMAX/FS2004 Landing Lights Tutorial

 

[arno]

Hi Tom,

If you are using true Dummy objects I don't think that will work, they may need to have geometry and use the light_land material. I've attached my GMAX landing light test object, perhaps that will help? Landing lights are very tricky and I just copy and paste working ones into any new models. These are animated using the Water Rudder tag (Shift W in FS9, Ctrl W if using FSX). Feel free to remove that, the taxi lights, and the extra LOD cubes to simplify it. I can do that if you need me to.

Thanks, this test object should help me to see if and why the orientation changes on export. Just for my reference, does the light shine in the direction of the +Y axis when viewed in GMax?

I tried pressing the Reset All to Default button on the Options dialog box and that didn't change the behavior, it still does not include the chocks visibility condition at all when I go from FSX model to FS9 model. I'm at a loss...

That is weird. I think you mentioned before that you already see the visibility conditions lost after import the FSX model, is that right? Because then I need to look at why the reader might loose them. At first I was thinking that collapse modelparts or a setting like that might have an influence, but you changed that already.

PS. Pressing this button changes the Use Conditions parameter to UserSpecified, I assume that should be defaulted to VisibilityCondition when this process is complete?

Yes, I think the default value can change once the changes we are working on now have become stable.

The orientation is not set by the direction of the geometry, but instead it is the GMAX Pivot Point that determines that. Access that via Heirarchy tab on the upper right of the screen, Affect Pivot Only. Then rotate it as desired. The pivot needs to be oriented so the blue arrow is in the *opposite* direction of the desired light splash (i.e. facing backwards).

OK, I tried to move the pivot last evening but without any effect. I'll try again. I think you answered my question about the direction as well here, looking in your test model the opposite of the blue pivot axis is indeed the +Y direction.

Here is a tutorial for creating light splashes in GMAX for FS9. It uses an older version of GMAX but it should give you the idea.

GMAX/FS2004 Landing Lights Tutorial

Thanks!