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

Be Careful when Rotating Polys with ADE

G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
As I mentioned in an earlier post in another thread, there is still an issue with ADE_GP maintaining texture application when a poly is rotated with ADE and not edited immediately.

I have been in private communication with Jon. The source of the problem appears to be the algorithm Jon uses to calculate the new lat/lon of the vertices after rotation. I'm a little embarrassed to admit that I proposed that algorithm to him.

The algorithm works sometimes -which is generally worse than not working at all. Provided all vertices are well away from the geographic center of the object on the ADE screen (i.e., small scale), you MIGHT get away without editing. But don't count on it. Always edit immediately following a ADE rotation. If you don't and either ADE-GP does not detect the rotation at compile time or you make further changes to that poly, the texture application will revert to what it would be if the poly were newly created.

I seriously doubt we're going to be able to make this work consistently in ADE_GP. ADE_GP needs some reliable mechanism to determine whether or not a move of all vertices is due to simple rotation. It does that by comparing the relative positions of the new and old vertices. But, in recalculating lat/lon after a rotation, ADE starts with the location of each vertex on the screen. Depending on the display scale, each pixel represents a variable distance - which in turn, affects the precision of the conversion back to lat/lon. If the relative positions vary by only a few centimeters, then ADE_GP can safely assume its the same pair of vertices. However, as the distance increases, the likelihood of an individual vertex move being ignored increases.

We'll keep trying, but I suspect the only reliable fix will be for ADE to automatically call for an edit immediately after rotation of a ground poly.

There is not a simpler problem with lines. ADE_GP recalculates the texture application for patterned lines during each edit. For lines that use a uniform texture, it doesn't matter since texture placement is not critical.

Don
 
To make Don feel a bit better the algorithm used to calculate the rotation is a standard one that is found on the internet and is used by ADE for other forms of rotation. It is part of the coordinate geometry set in ADE and I did not create it especially for rotating polys.

The only thing that I needed was the determination of the point around which to make the rotation and I think ADE uses the same method as the GPLibrary. Again however this is coming from the graphics library that determines the bounding box of a complex object and then the center point of that box.

To be honest I am not sure why this method of rotation in ADE is causing problems in calculating the new position of vertices. I do not think there is any other way to do it. One possible issue is that all these calculation are imprecise in some way or another. If the calculation method is different in ADE than the GP Library then that might cause a difference.

I would be really interested to have some more information about a distortion of a poly after rotation. I do have several sets of algorithms so perhaps one is more accurate in this case than the one I am currently using.
 
Glad to have you back with us, Jon - even if only temporarily

To make Don feel a bit better the algorithm used to calculate the rotation is a standard one that is found on the internet and is used by ADE for other forms of rotation. It is part of the coordinate geometry set in ADE and I did not create it especially for rotating polys.

The only thing that I needed was the determination of the point around which to make the rotation and I think ADE uses the same method as the GPLibrary. Again however this is coming from the graphics library that determines the bounding box of a complex object and then the center point of that box.
Click to expand...
Perhaps I just re-invented the wheel. (After my experience with triangulation, I'm leery of any algorithm found on the web.)

I am not sure why this method of rotation in ADE is causing problems in calculating the new position of vertices.
Click to expand...
I'm sure the current implementation is adequate for ADE's internal purposes. Any problems likely are limited to ADE_GP's use of the data. But, I don't see how ADE-GP can be made to cope.

Presumably, your starting point after rotation is the pixel position of each vertex. Depending on scale, small rotations at large scales could result in a vertex not changing pixel position while others moved only one vertex in either or both directions. That would account for one of the symptoms I observed.

The other potential issue is pixel resolution. At large scales, each pixel could represent a significant distance. For an airport 2 miles (~3300m) across E-W, even on a hi-res monitor, each pixel would represent about 2m. or 7 feet when the whole airport is in view. A single pixel move would represent a change of up to 10'ft at each end of an edge - which may not be consistent from edge to edge. How is ADE_GP to differentiate between such results of rotation and genuine vertex moves of a similar distance done at smaller scales?

Is it possible for you to call the editor automatically after rotation of a ground poly? That would certainly take care of the problem.

Don
 
Jon, I've made a fundamental assumption based on our e-mail exchange of yesterday that after rotation, you determine lat/lon of each vertex from its position on the display. You have not confirmed that assumption is correct.

But, if it is, I wonder whether you somehow measuring the angle of rotation and recomputing the lat/lons based on their original r/theta from the geographic center and the change in angle might help. At least that way, you should get consistent results for all vertices and you'd take pixel resolution "out of the equation".

Don
 
Pixels are not involved. It is a straight forward geo calculation.

A Google on calculating terminal coordinates based on distance and bearing from a start point will throw up the general algorithms.

The code below is extracted from my Coordinate Math library. Calculations are not based on deltas other than a new bearing is calculated from the original bearing plus the change in bearing as the poly is rotated. Distance and initial bearing from the rotation point to each vertex is calculated before any rotation. After that a new position is established for each vertex based on the new bearing.

Code: 
                        double lat1 = FSConvert.DegreesToRadians(start.Latitude.Decimal);
                        double lon1 = FSConvert.DegreesToRadians(start.Longitude.Decimal) * -1;
                        double d = FSConvert.MetersToDrad(distance);
                        double tc = FSConvert.DegreesToRadians(bearing);

                        double lat = Math.Asin(Math.Sin(lat1) * Math.Cos(d) + Math.Cos(lat1) * Math.Sin(d) * Math.Cos(tc));
                        double lon = ((lon1 - Math.Asin(Math.Sin(tc) * Math.Sin(d) / Math.Cos(lat)) + Math.PI) % (2 * Math.PI)) - Math.PI;

                        var returnPoint = new FSPoint {
                            Latitude = {
                                Decimal = FSConvert.RadiansToDegrees(lat)
                            },
                            Longitude = {
                                Decimal = FSConvert.RadiansToDegrees(lon) * -1
                            }
                        };
                        point = returnPoint;

ADE will then determine the new offsets for each vertex in the display. However to be clear determination of the new coordinates for a vertex use math based on the coordinates and nothing on the pixel position - pixel positions (offsets) follow from the new coordinates.
 
Thanks, Jon. I had inferred from your e-mails that pixels were your starting point. And, given that assumption, all the issues I am seeing were explainable.

At least now we know what it's not.

Once I fix the issue George has highlighted, I'll do some further testing.

Don
 
Jon, I've done a small amount of preliminary testing and am unable to reproduce what I was seeing earlier in the week - which means that poly rotation with or without other vertex adjustments should be working. (More testing tomorrow.)

George et al, please see if you can break it.

Don
 
I've done some more testing and am still unable to duplicate the problem I saw earlier.

I know I didn't imagine it. Perhaps I wasn't monitoring what I intended.

So, the caution on rotating polys in ADE no longer applies. If you rotate polys and perform other vertex operations, it should all be handled properly at compile time.

Don
 
You must log in or register to reply here.
Back
Top