Ade-gp 0.0.37

tgibson

Resource contributor
#21
I am talking about helper shapes in ADE, not texture orientation in the GP Editor. That is usually not as critical to get the exact angle correct. But Don could add an angle display and then it could be as accurate as helper rotation in ADE.

To rotate a helper by 5 degrees in ADE, you:

1. Zoom in to the yellow circle, until it fills about half the screen.

2. Click on the yellow circle, and note the angle displayed in the tool tip.

3. Drag the yellow circle until the tool tip displays exactly 5 degrees from the original value.

Hope this helps,
 

gadgets

Resource contributor
#22
Tom, re your initial report above, if you still have the Texture_Def.txt and Lines_Def.txt files, please send them to me (mailto:don@stuff4fs.com) so that we are working from the same base.

Also, could I suggest you set out future texture editor problems in a separate thread so that responses on all matters are closer to the corresponding query/report.

As you may be aware, the Texture Editor was a last-minute addition before I went on vacation and only received a cursory level of testing. I normally wouldn't release something at that stage - but at the time it seemed like a relatively straightforward undertaking. (You are paying the price for that now!) On a positive note, the feaure is rather simple-minded, so there can't be that many more issues to report.

Complicating your report above is that I've never tested ADE_GP with a "horizontal" line texture. Obviously, that aspect also has issues which will be fixed today.

George, re the lat/lon mismatches, my suspicion is that it's due to differences in the way Jon and I handle lat/lons. What you might try is placing a node in the long line at the point where it is intersected by the shorter one. If the node and the end point are at the same lat/lon, they should join properly irrespective of the underlying issue. You might also check whether the same issue exists in FS9, which uses flat-earth. (I'll be doing the same thing but you'll "get there" before I will.)

Don
 
#23
What you might try is placing a node in the long line at the point where it is intersected by the shorter one. If the node and the end point are at the same lat/lon, they should join properly irrespective of the underlying issue.
As I said, all of the 'joining' nodes have the same lat/long, either by typing the values into the vertex dialog or by copy/paste the values from one into the other. As you can see, they don't join in FSX.

re the lat/lon mismatches, my suspicion is that it's due to differences in the way Jon and I handle lat/lons.
Surely latitude and longitude are global? The GP Editor and ADE should have exactly the same values.
 

gadgets

Resource contributor
#24
As I said, all of the 'joining' nodes have the same lat/long
No so. In the last file you sent, ADE reports the vertex highlighted in the attachment in position:
N60 07.420
E019 54.300

while the position of the corresponding vertex in the long line is reported as:
N60 07.422
E019 54.288

Surely latitude and longitude are global? The GP Editor and ADE should have exactly the same values
Yes, they are global. But, generally, those quantities are converted to radians before any processing and the computation of X/Ys between two points involves complex arithmetic - especially in the case of FSX which uses "round-earth" in its rendering.

Don
 

Attachments

tgibson

Resource contributor
#25
Hi,

I have changed my definition files several times since then over the course of testing, so I don't have the ones I used in the post above, sorry. I inspected the files almost every time after I made a change in the GP Texture Editor and I never saw any problems in them, other than the swapping of the U and V entries as I described above. Otherwise they always looked perfectly valid. I will send them at the next report, if you like.

I knew that the Texture Editor had not been fully tested yet; that was one reason why I have been putting it through the ringer, one step at a time. I will put further posts into a separate thread, no problem.

Thanks,
 

gadgets

Resource contributor
#26
Tom. No need to send the files. I've found and fixed the problem in the texture editor. Tracing it through to the GP Editor is only a matter of time. And thanks for your extra efforts in debugging the texture editor.

George, it just occurred to me that you may be going to extra effort in texturing lines. While the GP Editor automatically selects the patterned line texture when you first create a line, you may use any texture for the line. In your case, gp_Yellow_20F wold give the same result.

Don
 
#27
No so. In the last file you sent, ADE reports the vertex highlighted in the attachment in position:
N60 07.420
E019 54.300

while the position of the corresponding vertex in the long line is reported as:
N60 07.422
E019 54.288
I agree there could be slight differences. In my case I have found differences of 0.000001 degrees in both lat and long.

This probably occured because the act of selection can cause a minute drag. I should have locked the surrounding polyline before copying/pasting the vertices :eek:

However, the difference in FSX is of the order of the line thickness which is 0.3 metres, much larger than 0.000001 degrees in lat/long.

For typical polygons, round-earth calculations shouldn't be necessary (or make a difference).
 
#28
Here is another one Don.

ADE shows the cusor well to the west of the common boundary of the two polygons whereas FSX shows the aircraft to be on the boundary of the eastern polygon:





How do I ensure that there is a common boundary?
 

gadgets

Resource contributor
#29
However, the difference in FSX is of the order of the line thickness which is 0.3 metres, much larger than 0.000001 degrees in lat/long
Me-thinks you've got one two many decimal points.

0.002 minutes of latitude is about 12 ft./3.5m.

If I switch to D.dddd display, the difference in latitude is 0.000003 - over one ft. or approximately the line width. However, the longitudes are identical. (Jon, I wonder if this is related to the issue I mentioned a day or so in the private e-mail.)

Another possible source of error when entering matching lat/lon directly is that ADE reports a rounded quantity in the vertex edit window. If you re-enter this quantity, it is used as if it were followed by many 0s and, hence, may represent a significantly different position. Not sure how you can get around that unless Jon (perhaps optionally) adds extra precision to the lat/lon quantities in the vertex edit window or otherwise allows you to get full precision.

Regarding the issue immediately above, I need to discuss with Jon. exactly how he determines Lat/Lon.

Don
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#31
Setting the heading for a helper shape should be easy enough. I never got around to adding a property editor for helper shapes but since they are becoming more important I have added that to my list.

Rotating aprons/polys is more interesting. I do have code to do this somewhere. One issue is what to rotate them about.........
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#32
ADE calculates to an from lat/lon using the ARP as reference. It uses algorithms to convery to and from x/y offsets. This is accurate over the distances seen in airports and works well enough so far. I have used different basis for the algorithms and it is, in fact, possible to tell ADE to use different calculations. If we start to get to a position where accuracies of a few cm or so are needed then it may be that ADE does not have the tools to do that and it would mean introducing new algorithms. As I say it is now possible to change these without re-writing large amounts of code but it is not trivial.

The current algorithms are unit tested to ensure they meet reasonable standards that have been acceptable so far.

I know that the requirements of GP objects may put a strain on this however.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#33
Surely latitude and longitude are global? The GP Editor and ADE should have exactly the same values.
Well that depends on the algorithms used to convert the latitude and longitude offsets in degrees (or radians) to meters (or pixels) on the ground.

If I take two sets of coordinates and calculate distance, bearing and x/y offsets for them then using different algorithms then the results can be different by small amounts that get increasingly large as I move from the reference point. No practical (that is computationally cheap) method is going to be 100% accurate.

ADE has to do two sets of calculations - calculate the offsets of a point from the reference point and the reverse - that is calculate the coordinates of a point from the reference point based on offsets. I know ADE is not 100% accurate. Don is using different methods I am sure and also he has to handle the round earth corrections required for FSX (since the compiler we use is based on the flat earth model of earlier versions.

ADE does not really care about the round earth. It works out the relative coordinates of objects from the ARP and send them to the compiler - that has to figure out how to place stuff on the ground.

It is entirely possible that those working with FS9 will get different results (and maybe less 'errors') than those working with FSX.
 

gadgets

Resource contributor
#34
As it stands, using typical polygons/polylines, it is almost unusable
George, there are two issues at play here. One is why is the FSX position relative to the aircraft is different from that shown in ADE. I suspect it's due to round-earth/flat-earth issues, and I'm currently in communication with Jon privately on that. That being said, such differences being only in the order of a foot or so are probaly insignificant when "flying" which, after all is what this is all about.

The issue of more concern to me is the space between those two objects given that they appear in the ADE display to be adjacent. The bright side of this is, if it can't be fixed, with a little trial and error, the two can be moved with ADE so as to be adjacant. I appreciate that's not a fix, but the effort in doing so is trivial.

Jon, I notice you've posted while I have been writing this. If you are using flat-earth computations which I infer you are, the I can probably accommodate that. However, gp lines and polys need to remain consistent with other ADE objects. While George has shown that the rendered position in FSX is slightly different from that shown on the ADE display, it's not clear to me whether or not other objects are similarly offset. If they are, while the absolute poition is in error, the relative positions are essentially correct and it seems to me that's what is important.

Now that (I think) I've got the Texture Editor to a state where Tom will be happy, and after I fix the horizontal/vertical line texture issue in the editor Tom identified, I'll be in a position to determine what's going on with positioning.

Don
'
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#35
I offer a test.

Create a helper shape at a point in the ADE display that can be identified in FS9/FSX. Convert it to an apron and a GP Poly. The two should be entirely coincident in the ADE display and when compiled should be coincident in FS9/FSX. If not then it should be possible to determine whether the apron is out or the GP Poly or both.

I have no idea of round earth/flat earth. Since FS requires the delivery of coordinates then that is what ADE creates, maintains and manipulates using real world spacial geometry algorithms. If ADE compiles something (based on Bgl comp source of couse) and when the user links ADE to FS the object is in the same place in both then that is the only test I care about.
 
#36
I now have a different problem (triangulation?).

I edited the two adjacent polygons to ensure that the two vertices where they joined were the same and the texture seems incorrect:

ADE:



FSX:



File attached.

I'll check coincident aprons and polygons.
 
Last edited:

gadgets

Resource contributor
#37
The relative position of the third (intermediate) vertex on the ADE display does not seem to correspond to its relative position on the ADE display.

Did you mave any vertices on the GP editor?

Don

EDIT: My guess is that you moved the two right-hand vertices without making a corresponding change in the intermediate vertex - instead of using resize.
 
Last edited:

gadgets

Resource contributor
#40
I did the same when I had only four vertices and it looked ok in FSX.
That was OK because what you did was, essentially, a horizontal resize. With the fifth vertex, by moving the right end, you changed the scaling on only a portion of the top but along the entire bottom, thus stretching the texture to the right of the intermediate vertex but along the entire bottom.

For the texture to be applied uniformly, the vertices on the GP editor must remain in the same relative positions as dictated by their lat/lons.

Don
 
Top