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

Auto normal options

arno

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,491
Country
netherlands
Hi,

I am a little confused by the auto normal options in SCASM, maybe somebody can help me shine a light on them.

Simply said the "a" option should make sure that the polygon is facing away from the center and the "ai" makes it point towards to center. That sounds simple.

But now I have also found some macros where the order of the vertices has an influence on this. So depending on the vertices being clockwise or counterclockwise you get another side of the polygon. But does that not work against the principle of the automatic options?
 
Hello Arno,

this is sometimes a tricky issue. While the rule you mentioned works fine in previous versions of FS, in FS-X the drawing order of the vertices (clockwise or counterclockwise) determines which side is visible (and the argument a or ai can revert the visibility again). It seems sometimes easier to experiment (always drawing in one direction and then changing a to ai or vice versa when the "wrong" side is visible.

Regards, Klaus
 
Hi Klaus,

Humm, guess I need to install an old FS again then to see what the designer of the API meant. I am using FSX (with Acceleration) now to test, but it should like that might not always give the right result for the object.

In that case it becomes hard to verify if my tool is reading it correct or not :).
 
Hello Arno,

I think that the A switch means that the vector por the polygon is taken from the first 3 points of the polygon (P1, P2, P3). The direction of the vector (VX VY VZ) is such that the vector is the cross product between (P2-P1) x (P3-P2). The vector is thus normal to the surface. In addition, the LEN parameter is the distance between the RefPoint and the surface. Thus, the separation plane (VX VY VZ & LEN - that divides the 3D world in the region from where you see the face and the region from where you do not see it) contains the face itself. The normal (eg the vector) points to the region from where you see the face. In conclusion the order of the 3 first points is what determines which face is seen.

I may be wrong. I would need to compile and decompile again a Poly made with A and made with AI. I think that AI is equivalent to A followed by a reverse of the 4 parameters. If A gives VX VY VY & LEN, AI would give -VX, -VY, -VZ and -LEN.

Kind Regards (and sorry if I am wrong),

Luis
 
Hi Luis,

I think I would indeed have to compile and decompile some samples as well.

I have read in some places that the order of the vertices (clockwise or counterclockwise) does not matter. That would make sense, as when the first three points determine it there is no need to have an automatic option :).

As I said I guess I need to do some compile/decompile tests to see what SCASM makes of it.
 
Hi Luis (and others),

I think I have found it. With the a and ai options the order of the vertices does not matter in general. The only exception is when the dot product of the normal of the triangle (or polygon) and the vector pointing to the vertex of the polygon (could be first point or average of first 3 points, etc) is zero. In that case the order of the vertices determines the direction of the normal. In all other cases the automatically calculated normal determines which side is visible.
 
arno said:
Hi Luis (and others),

I think I have found it. With the a and ai options the order of the vertices does not matter in general. The only exception is when the dot product of the normal of the triangle (or polygon) and the vector pointing to the vertex of the polygon (could be first point or average of first 3 points, etc) is zero. In that case the order of the vertices determines the direction of the normal. In all other cases the automatically calculated normal determines which side is visible.
Click to expand...

Hi,

Thanks for reporting. By the way - you may have so many combinations of SCASM flags (directives and the like...) that one approach to your tool could be COMPILE_WITH_SCASM followed by DECOMPILE_WITH_? followed by your CONVERTER. There are more than one decompilers that produce very clean code (no A no AI no ... just VX VY VZ LEN).

Kind Regards,

Luis
 
Hi Luis,

I have thought about that approach, but I think I have solved most of the problems now. In that case I don't have to depend on another decompiler for the tool.
 
You must log in or register to reply here.
Back
Top