• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSXA Model won't export

GHD

Messages
12,244
Country
england
Hi Arno,

I would be grateful if you could look at this model please.

It was converted using the latest version of SAMM. It imports into MCX correctly and I can manipulate it, but it won't export as an FSX mdl.



It was OK when converted by a previous version of SAMM.

The model can be downloaded from:

http://www.geo-davison.demon.co.uk/Wessex.zip
 
Hi George,

I will download and test the model tomorrow.
 
Hi,

I got the model and I can see what goes wrong.

I have to remove the animations, else I get another error. But with the animation remove I see there are some vertices that become "not a number". I have to figure out where that happens.
 
Arno, I'm about ready to release SAMM generally. Since SAMM/MCX interaction is likely to be an ongoing "story" and since SAMM is likley to be widely used, do you think it worthwhile to set up a separate forum stream for SAMM support?

Don
 
Last edited:
Hi Don,

I think SAMM will be widely used indeed, so if you would like a separate forum for it, I would be more than happy to setup one for you. I will do so later today.
 
Hi George,

I fixed it, from tomorrow it will work in the development release.

There were some weird animation keys in the object (I would almost say invalid ones). The math in MCX was not robust enough to handle them, but that is fixed now.
 
There were some weird animation keys in the object (I would almost say invalid ones).

Thanks Arno.

Hmm, could this be a SAMM fault? MCX had no problem with a conversion using an earlier version of SAMM.
 
Hi Don,

I think SAMM will be widely used indeed, so if you would like a separate forum for it, I would be more than happy to setup one for you. I will do so later today.

SAMM forum has been setup now. You are a moderator for that forum, so you can make sticky threads, close threads, etc.
 
Hi,

Thanks Arno.

Hmm, could this be a SAMM fault? MCX had no problem with a conversion using an earlier version of SAMM.

I don't know what SAMM does with the animations in the model. With the changes I made ModelConverterX is more robust, so that is better anyway. It is just that I never saw such keyframes in other FS objects. So in the end I think it is better that ModelConverterX can handle unexpected things as well :)
 
Thanks for setting up the forum, Arno. I'll be releasing later today.

Re SAMM's automations, because scenery models don't have access to aircraft variables, SAMM sets up a dummy parameter block and sets all parameters to 0, other than for "standard" keys like l_gear, r_aileron, etc which it "knows" should be something else. Then, when it encounters an animation in the aircraft file, it interpolates using the dummy parameter and leaves only a single entry in the animation table thus saving both memory and FPSs. For keys which are outside the range in the animation data, SAMM uses the appropriate end-key.

Since I expect to continue to improve SAMM in the near term, if you discover something SAMM is doing that it shouldn't, please let me know.

Thanks again,
Don
 
Hi Don,

I am not sure if it is SAMM that is doing the things wrong. But I found animations where the keys show quite illogical values. For example frame numbers of zero in the middle, while the next one has a value again. Or a quaternion of only zeros (which is not valid AFAIK).

But it could very well be that this was in the original aircraft already or that ModelConverterX tries to read too much data.
 
There should only be one key value in any animation table that SAMM converts. As for the quaternion of zeros, I rely on the VB Net quaternion.Slerp method to generate the final rotational value, from the two boundary values.

If you send me the .mdl file, I'll check to ensure SAMM is not the culprit.

Don
 
Hi Don,

In ModelConverterX I see more than 1 keyframe. So maybe I am trying to read too much data then. That would explain why after the first one the data is not so meaningful :).

So you are saying that in a MDL file that SAMM made each animation should be only 1 keyframe long?
 
Too much traffic too fast here.

Yes, Arno, there should only be one key value in any animation table.

Don
 
Hi,

Do you also update the variable that holds the count in the header of the animation table? It is the last int16 before the actual keys starts.

That's what I use to determine how many keys to read. And in the model George posted in this thread I am sure I saw 25 keyframes in some of the animations. But that might be a MCX bug as well of course :).
 
Back
Top