• 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.

Where Did the Autogen Go?

G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
I have found a static model that, for some as yet unknown reason, causes autogen to be suppressed. It is the default Beech Baron.

I will be trying to figure out why over the next few days. In the meantime, I thought I should publicize the problem.

Don

EDIT: I've now had a close look at the listings for the stock Baron. I see nothing unusual - but I haven't given up.

If anyone can think of a possible reason for how autogen can be suppressed by a scenery model, please jump in.

Don
 
Last edited:
G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
I have found the cause of the autogen suppression - an unusual aircraft design technique which resulted in SAMM declaring an aircraft radius and bounding box size of several kilometers.

I'm going to spend the next little while looking for a full solution. If not successful, there is a very simple workaround that I'll implement.

Don
 
G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
Bill (ngix), Arno, if either of you are "listening", as I noted in an earlier post in this thread, the suppression of autogen was due to an incorrect calculation of bounding box size - and I've now implemented a workaround.

Now, I'd like to make a proper fix.

Referring to the stock FS9 Beech Baron 58, some of the early transforms are rescalings by 1000 followed by rescaling by 0.001 - and vice versa. Interim transforms sometimes involved translation of several hundred meters. AIFP (obviously) mishandled these transforms for the purpose of calculating the true size of the bounding box.

Any idea what these unusual transfroms in this aircraft are meant to do?

Any one else who can shed some light on the situation, feel free to jump in.

Don
 
n4gix

n4gix

Resource contributor
Messages
11,674
Country
unitedstates
Don, just as a WAG I suspect that the original source model was incorrectly scaled by the modeler, and that they (ACES?) had to manually rescale the model by tweaking the .asm file when compiling.

Otherwise, there's no legitimate reason for the model to have such an "unnatural" scaling that I can think of! :rolleyes:
 
GHD

GHD

Messages
12,243
Country
england
I've just looked at a model made with FSX GMax in MCX. It imports correctly but doesn't display and it has a huge bounding box in the "x" direction.

I don't know whether it is a fault in MCX, but after exporting as a 3ds model, and importing into GMax, it displays correctly but the bounding box is indeed huge (over 1Km):

 
Last edited:
G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
Thanks Bill. I can't make any sense of those transforms (BGL_TRANSFORM_MAT). As examples, the first four from the aircraft .mdl file follow:

X/Y/Z: 0.000/22.550/-31.883 Rotation/Scale: 0.001/0.000/0.000/0.000/0.001/0.000/0.000/0.000/0.001

X/Y/Z: 0.095/-0.002/0.108 Rotation/Scale: 1000.000/0.000/0.000/0.000/1000.000/0.000/0.000/0.000/1000.000

X/Y/Z: 0.095/-0.002/0.108 Rotation/Scale: 1000.000/0.000/0.000/0.000/1000.000/0.000/0.000/0.000/1000.000

X/Y/Z: 0.095/162516.000/-440662.000 Rotation/Scale: 1000.000/0.000/0.000/0.000/1000.000/0.000/0.000/0.000/1000.000

The translation values have not yet been rescaled to reflect the SUPERSCALE (6). There are a number of transforms similar to these scattered throughout the model.

Since the static model displays correctly, the transforms must be legitimate. But, I can't figure out how to handle them for the purpose of calculating the absolute position of each vertex. Consequently, I've limited the bounding box to a size capable of holding a sphere of radius = model radius specified in the original .mdl file.

George, perhaps Arno is running into the same difficulty as me.

Thanks, guys.

Don
 
n4gix

n4gix

Resource contributor
Messages
11,674
Country
unitedstates
Don, it may also be as simple as one or more objects in the scene, that were "rescaled improperly" by the modeler (i.e., at the "object" level).

Correct procedure is to add an x-form modifier before rescaling, then collapsing the stack to reset the x:n,y:n,z:n scalars in Track View.

Alternatively, one would select one of the object's sub-levels (vertex, edge, face, polygon or element), then rescale the selected sub-object level. Either of these methods is acceptable.

If neither of these two procedures is followed, while the object's apparent size in the viewport will be "correct," the Transformation Scale(s) will be less than the required x:100.0 y:100.0 z:100.0 and Bad Things may well happen... :rotfl:

Since the object may well have been something that's not normally seen (such as the exterior or interior top level nodes, it wouldn't affect the model's apparent size in either the preview window or the sim, but would affect the model's bounding box calculation!

Again, without having the source file to examine, this too is simply a WAG... :D

That said, I think your idea of assuming a size equal to the model radius is a good compromise.
 
Last edited:
You must log in or register to reply here.
Top