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

Interesting Result

Art, thanks for sending me the helicopter model.

Yes, I can see that SAMM is not rescaling the bounding box as it should - which in turn is responsible for the enormous bounding box you are seeing.

Looks like I've got a weekend project.

Don
 
Re the extreme bounding box, the good news (for me) is that SAMM isn't at fault. The even better news is, SAMM can fix it (if you want to be bothered).

The HH-65C model contains over 33,000 vertices, the positions of about 6300 of which could be considered extreme. It is these latter vertices that are causing the bounding box to be so large. Their use is a mystery. Perhaps it was some test capability that wasn't deleted. Unfortunately, even if I disable all animations (using Animations: Custom), a few of these extreme vertices are still used. So, if you go out along the boundary of the bounding box in FlightSim and look hard enough, you'll find a few triangles drawns. Some will be untextured, others will use some part of the texture Misc_T. bmp.

It's not possible to tell from the .mdl file to what these vertices are related. But, even with Animations: All, only a few of them are used and only in a couple of places. If you really want to make the bounding box normal - what you can do is, in the aircraft .mdl listing, locate the DRAW_TRI commands which use these vertices (21601-27915) and use SAMM's "delete" function on those commands. (It doesn't seem likely that their rendering contibutes significantly to the displayed model.)

But, I'm going to change SAMM anyway so it considers only the vertices actually used in the rendered model when setting the bounding box dimensions. In the case of this helicopter, this wouldn't fix your bounding box issue, but it may prevent it occuring unnecesarily in other models.

Don
 
Don, it may well be that those are "rogue vertices" that are often overlooked by modelers. Sometimes when trying to "slightly move" a selected vertex in Max/GMax, if one isn't mindful to constrain the axis' movement, a vertex might just "shoot off into space..."

The modeler then notes that there's apparently a "missing poly" and then proceeds to create a new one to "plug the hole." <oops!> :(
 
Bill, funny you should "appear" at this point. I just finished working this problem on a model that looks very much like EagleSoft's Beechjet 400A. I would estimate almost half of the vertices in the model fall into the extreme category. That's not something that is likely to happen by accident.

Perhaps you can help me understand what these vertices are for and how I can work around them since, apparently, they don't contribute to the model.

If you'd like to take this discussion off-line, please send me a PM with your email address. (I'd have sent you a PM instead of bringing up the topic here, but the last time i tried, I got a response saying you can't receive PMs.) Alternately, my e-mail address is in the SAMM readme.

Don
 
Don,

It is likely that when you tried to send a PM some months ago, I'd completely forgotten that I'd "turned it off" sometime last year and forgot to "turn it on" again...

In any case, although I don't have the FSX version of the source, I've checked the FS9 version and find a grand total of 47,775 tri-polys, with nary a stray vertex anywhere...

In any event, you can either PM me of write directly to n4gix at comcast.net... :D
 
Bill, I thought you might like to know that I have resolved most of the issues with the 400a. But, to do so, I had to compute the final position of each vertex in the entire model - including animations.

(Initially, I had made the erroneous assumption that I could compute the bounding box directly from the vertex table in the .mdl file. But, of course, this doesn't work unless the entire model is designed as a single entity. Apparently, in the case of the 400a, some appendages were designed separately with rather lengthy transforms being required to finally place them.)

I still have a minor issue with the Y-axis, but X and Z bounding box sizes are now "bang-on".

Best regards,
Don
 
I'm glad to hear that. Just for the sake of complete information, the B400A model began life as an FSDS FS2002 project, but by the time of initial release had morphed into a GMax FS2004 (FS9) project. It is quite likely that much of the "strangeness" you've encountered is a result of all the transformations involved in migrating it from an .fsc file to .gmax format.

For FSX the entire project was migrated over to Max and basically rebuilt.
 
You must log in or register to reply here.
Back
Top