• 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 Aces Verify Scale Tool problems

Messages
204
Country
portugal
Hello all.

I'm getting some annoying errors when verifying the scale model with Aces Export Tool.

I'm getting broken scale on parts, in the style of:
object_001 has a scale of [1,1,1]
object_002 has a scale of [0.999996,1,1]
object_003 has a scale of [1.00001,1,0.999992]
...

I've been looking at other treads on this matter.
I checked the default scale on 3D Max and everything seems alright.
I tried the built in fix Fix selected model scale! and the Reset Scale from the 3D Max Hierarchy rollout.
Nothing seems to fix this errors... any ideas?
 
Adding an XForm modifier to the object stack will correct the scale error. I usually collapse it before adding anything else to the stack.
 
Here is a workable procedure. Note that you must do this one object at a time:
  1. Select the object you need to reset the scale on
  2. Open the Graph Editors/Track View - Dope Sheet
  3. Locate your selected object and click on the Transform Scale
  4. The existing scale should appear in the form X:100.00 Y:100.00 Z:100.00
  5. If any other numbers appear, a full Reset Transform needs to be applied
  6. Click on the "Hammer" icon, select Reset XForm, click on Reset Selected
  7. Now the scale in the Dope Sheet should be 'normal'
  8. Check the object's Stack, you will see an "XForm" modifier has been automatically applied
  9. Right click on the screen and select Convert to Poly (or Mesh)
 
Here is a workable procedure. Note that you must do this one object at a time:
  1. Select the object you need to reset the scale on
  2. Open the Graph Editors/Track View - Dope Sheet
  3. Locate your selected object and click on the Transform Scale
  4. The existing scale should appear in the form X:100.00 Y:100.00 Z:100.00
  5. If any other numbers appear, a full Reset Transform needs to be applied
  6. Click on the "Hammer" icon, select Reset XForm, click on Reset Selected
  7. Now the scale in the Dope Sheet should be 'normal'
  8. Check the object's Stack, you will see an "XForm" modifier has been automatically applied
  9. Right click on the screen and select Convert to Poly (or Mesh)
And if the object is showing X:100.0 Y:100.0 Z:100.0 already?
The XForm Reset won't do anything and still the object appears as broken scale error...
That's what is happening on some objects... it's confusing :banghead:
 
What are you doing with the "Aces Export Tool?" I don't believe that it actually works properly in any case.

What happens when you do a normal export from Max/GMax?
 
What are you doing with the "Aces Export Tool?" I don't believe that it actually works properly in any case.

What happens when you do a normal export from Max/GMax?
You mean export to .X by ESP 1.0 DirectX file?
It works the same way. In fact the Aces export tool uses the same ESP 1.0 interface, and the exported .X files are identical both ways.
I always used the Aces tool to export, and also to check all that verify options, but these scale errors are driving me crazy...
 
As far as I know, ACES never did finish their Export/Verify tool. I've never had any luck with it at all for exporting. Most of the time it locks up Max2012 when trying to "verify" the scene's objects.
 
As far as I know, ACES never did finish their Export/Verify tool. I've never had any luck with it at all for exporting. Most of the time it locks up Max2012 when trying to "verify" the scene's objects.
I always exported through the Aces tool following the SDK instructions (since FSX/FSXA on Mmax2009).
Yesterday, I loaded the SDK provided Douglas_DC3 max file, and tested the verify tool on Max2015.
Everything seems to work ok, all the checks are performed without any crash, but still, the same scale errors are reported in the style of object_001 has a scale of [1,1,1].

I tried some testing with a simple cube object.
If I change the scale the verify tool spots the error; if I Xform reset it, the error goes away.
The I fiddle around with some transformations, even used some non linear animations to try to mess things up, and the scale error never came back. The verify tool says the object is perfect!

In my models, or even with the FSX SDK DC3, I get this annoying scale errors...
I just wonder what causes the scale of some object to be slightly different than X:100.0 Y:100.0 Z:100.0 that makes the verify tool to report theses errors.
I noticed most (if not all) of these objects that are reported to have scale errors are animated... even some dummies are reported to have these scale errors...
I think it is possible to have a scale error free model; I just don't know what is causing this small scale variations, which are indeed very small, but enough to trigger the verify scale tool.

I now realize that no one else seems to use the Aces tools, as I don't seem anyone reporting these kind of errors. Should I ignore this and move forward?...
 
I now realize that no one else seems to use the Aces tools, as I don't seem anyone reporting these kind of errors. Should I ignore this and move forward?...
This is why I asked what happens if you export .x and .xanim files using the Export (.x) option, then compile using XToMDL.exe? If you get a compiled .mdl file that displays and works properly, then there's no problem!

Yes, I would simply abandon the Aces tool. If I recall correctly, it only ever worked for scenery objects.
 
This is why I asked what happens if you export .x and .xanim files using the Export (.x) option, then compile using XToMDL.exe? If you get a compiled .mdl file that displays and works properly, then there's no problem!

Yes, I would simply abandon the Aces tool. If I recall correctly, it only ever worked for scenery objects.
Sorry Bill but I disagree.
I got some aircraft (and vehicle) models virtually error free from the Aces Export/LOD tool, and they were exported correctly and worked correctly (in FSXA).
The tool will spot for object errors like co-located vertices, duplicate parts, open edges, volume shadow (very handy for vehicles), that can be easily fixed before exporting. The only ones I'm getting trouble to sort out, are these annoying scale errors - if I can't find a way to solve them, at least I will find out what is the cause, and how to avoid them. Now the fixing solutions that the tool provides, that I don't use, because I don't know exactly what i is doing and I'm afraid to mess up something. I use the tool for verification, fix the errors manually, then export. And AFAIK it works ok.
 
I keep a copy of the export error log which accomplishes the same goal when all is said and done.
 
I keep a copy of the export error log which accomplishes the same goal when all is said and done.
Bill, how do you dump the export error log? The only one I use is the xtomdl report log by adding >filename.txt to the end of the command line.
 
Paul, that is the error log I am keeping, save that I call it >buildlog.txt
 
Back
Top