-
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.
Ade_gp 0.0.96
- Thread starter gadgets
- Start date
Thanks, Floda. The situation is as I hoped it would be. It is the third entry, i.e., 500, which is eliminating the autogen suppression. The other two control visibility and may be used to improve FPS.
I thought that might be the case since, as you can see if you look carefully, the missing line is actually there; it is just very narrow at one end, reducing to 0 width at the other. It was compiled with (a) or (b). (c) would have been OK.
Bottom line, it would seem no one has any reported difficulties with 0.0.95(d).
Don
Found another little issue. When I changed the handling of polys a couple of weeks ago, I neglected to update the associated "Reset" handling. Consequently, clicking the Reset button appeared to have the desired effect, but the ADE records were not updated. Fixed in attached.
Don
Don
Last edited:
Found another minor issue. If vertex position was adjusted on the ADE display and the assigned texture was not square, the corresponding X/Y and U/V values generated was not correct.
As well, during my own work I found it inconvenient to always have the texture positioning adjusted - even if all I wanted to do was tweak the geographic position a vertex. So, I've added an option to not have the texture adjusted. Now, if all you've done is tweaked vertex position (i.e., no vertices added or deleted) you'll be asked if you want the texture position adjusted.
Don
As well, during my own work I found it inconvenient to always have the texture positioning adjusted - even if all I wanted to do was tweak the geographic position a vertex. So, I've added an option to not have the texture adjusted. Now, if all you've done is tweaked vertex position (i.e., no vertices added or deleted) you'll be asked if you want the texture position adjusted.
Don
Last edited:
- Messages
- 12,244
- Country
If you adjust the geographic position of a vertex and go to the editor, ADE_GP automatically adjusts the position of that vertex on the texture to match the change in geographic position. Easiest way to see is to take a simple poly and move one vertex a significant amount. The go to the editor and you'll see that the position of that vertex on the texture has changed.
Now you get to decide whether you want the change or not.
Don
Now you get to decide whether you want the change or not.
Don
If there weren't superimposed vertices, then the warning wouldn't have been issued. Am I supposed to read between the lines and guess that the closing vertex will always be superimposed on the opening vertex in any closed-line situation and hence, that warning should be suppressed?
Then why did you draw one?
Regarding yesterday's new release, it has occurred to me that the issue can be resolved without user intervention in each instance. If a uniform texture has been used and a vertex is moved, then it's highly likely the user wants the texture placement adjusted (as has been the case until yesterday). On the other hand, with a patterned texture, it is highly likely that the user wants the texture placement retained should he/she simply tweak vertex placement.
So, I'm going to implement this approach in place of the message. Once changed, in the first case, an small, unwanted, adjustment in texture placement is unlikely to be noticeable. In the latter case, if texture adjustment was desired, it can always be made by hand.
ADE_GP will always attempt texture adjustment when vertices are added or deleted (so long as the old and new vertex count differ and there are at least two vertices that have remained in the same relative position).
Don
Version 0.0.96(g) attached.
As indicated in the previous post, the user option implemented only yesterday with regard to updating texture placement for modified polys has been removed. The decision as to whether or not to update texture placement is now made solely on whether or not the texture is designated a being "uniform".
This update also suppresses the "superimposed vertices" warning for closed lines where the initial and final vertices overlap.
Don
EDIT: I have also discovered as a result of this activity that several of the uniform "starter" textures are not so designated in the Textures_Def_Base.txt. All the textures in that file between "gp_LineBase" and "gp_Yellow-20F", inclusive, should be specified as "uniform".
As indicated in the previous post, the user option implemented only yesterday with regard to updating texture placement for modified polys has been removed. The decision as to whether or not to update texture placement is now made solely on whether or not the texture is designated a being "uniform".
This update also suppresses the "superimposed vertices" warning for closed lines where the initial and final vertices overlap.
Don
EDIT: I have also discovered as a result of this activity that several of the uniform "starter" textures are not so designated in the Textures_Def_Base.txt. All the textures in that file between "gp_LineBase" and "gp_Yellow-20F", inclusive, should be specified as "uniform".
Last edited:
Version 0.0.96(l) attached. It resolves the issues with long lines and polys discussed in this thread.
While the earlier versions of 0.0 96 appeared to work when there were only a few long (i.e., requiring partitioning for FSX) lines and polys, numerous such lines and polys "broke" it. I have fixed the issue with lines. As for polys, I could find no solution for this issue when partitioning following triangulation. While this approach was very efficient, it only worked well when partitioning was required in only one dimension, i.e., latitude or longitude - but not both. So I have reverted to the earlier approach of partitioning before triangulation. While less efficient, it appears to hold up under load.
Back to you, Jacques.
Don
While the earlier versions of 0.0 96 appeared to work when there were only a few long (i.e., requiring partitioning for FSX) lines and polys, numerous such lines and polys "broke" it. I have fixed the issue with lines. As for polys, I could find no solution for this issue when partitioning following triangulation. While this approach was very efficient, it only worked well when partitioning was required in only one dimension, i.e., latitude or longitude - but not both. So I have reverted to the earlier approach of partitioning before triangulation. While less efficient, it appears to hold up under load.
Back to you, Jacques.
Don
0.0.96(m) attached. It fixes the compiler errors reported in this thread.
However, it may still generate "failed to triangulate" messages for large, complex polys when a 100m partitioning line crosses more than two edges. (This error did not occur when partitioning of polys was done following triangulation. However, as we discovered last week, that method has other difficulties for which I have not yet found a solution.)
So, until I am able to fix one or the other of those issues, there is no alternative but to simplify polys for which triangulation fails.
Don
However, it may still generate "failed to triangulate" messages for large, complex polys when a 100m partitioning line crosses more than two edges. (This error did not occur when partitioning of polys was done following triangulation. However, as we discovered last week, that method has other difficulties for which I have not yet found a solution.)
So, until I am able to fix one or the other of those issues, there is no alternative but to simplify polys for which triangulation fails.
Don