-
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.
P3D v2 Ground poly shift?
- Thread starter ralinn
- Start date
- Messages
- 1,510
- Country
Arno, I haven't seen where it makes any difference which compiler is used, from what I've seen a PR compiled with the P3D2 compiler works fine in FSX and vice versa with no change in the alignment of things, both PRs compiled from the same .inf & source .tif. I'm very interested to hear your thoughts after your tests.
George, that airport is at 374' MSL so the shift would be minimal, try one at 10,000' MSL and you'll see what I mean. Here are a couple shots from KLXV Leadville, Colorado, this hangar is 55' x 40' to give you an idea how far (something) shifts:
Jim
George, that airport is at 374' MSL so the shift would be minimal, try one at 10,000' MSL and you'll see what I mean. Here are a couple shots from KLXV Leadville, Colorado, this hangar is 55' x 40' to give you an idea how far (something) shifts:
Jim
Cheers Jim,
I concur that the issue gets more extreme with altitude.
We are working on three airports: CA21 (~500m), 2O1 (~1100m) and KBLU (~1600m). Each airport exhibits the same shift which is exponentially worsened by the increase in altitude. At a guess I'd say below 100m ASL the issue would be unnoticeable.
Greg
I concur that the issue gets more extreme with altitude.
We are working on three airports: CA21 (~500m), 2O1 (~1100m) and KBLU (~1600m). Each airport exhibits the same shift which is exponentially worsened by the increase in altitude. At a guess I'd say below 100m ASL the issue would be unnoticeable.
Greg
- Messages
- 1,510
- Country
One thing I noticed at Inverness (X40, 64' MSL) is that I have an afcad boundary fence that butts up against the corner of a building, I used "move to aircraft" to position the vertex while slewing in FSX. In FSX the fence lines up perfectly with the building, in P3D2, exported from the same ADE file and the building placement compiled from the same XML the fence misses the corner of the building by a foot or so. That leads me to believe something is going on besides the PR shifting but I'm not sure what.
Hi Greg, great to see you around!
Hi Greg, great to see you around!
- Messages
- 1,510
- Country
LOL George, here's what I just came up with:
GP was made in gmax and processed through the GP wizard. I dunno, I downloaded the main P3D2 installer last December and I've just been adding the patches since then. It took an act of congress to get the initial 10 Gb download saved to my PC so a full reinstall from the complete v2.2 build is out of the question. I did a fresh reinstall of v2.0 +v2.1 patch at the release of v2.1 and then patched over that to 2.2 beta but like I said I haven't added the v2.2 release version yet. I can't imagine they changed this between the beta and the release version, they gave us the beta on a Saturday and released the public patch on the following Monday IIRC. I think they were all drinking beer over the weekend in celebration of having the 2.2 patch done. I'll attempt to download that late tonight when the internet is good (maybe) and try a full reinstall to see if that changes anything. Did you make that GP with the ADE GP utility? Also which LIB is the little man in and what's his GUID? I'll try him as well...
If we keep messing with this we'll eventually have KLXV done - for FSX anyway...
Jim
GP was made in gmax and processed through the GP wizard. I dunno, I downloaded the main P3D2 installer last December and I've just been adding the patches since then. It took an act of congress to get the initial 10 Gb download saved to my PC so a full reinstall from the complete v2.2 build is out of the question. I did a fresh reinstall of v2.0 +v2.1 patch at the release of v2.1 and then patched over that to 2.2 beta but like I said I haven't added the v2.2 release version yet. I can't imagine they changed this between the beta and the release version, they gave us the beta on a Saturday and released the public patch on the following Monday IIRC. I think they were all drinking beer over the weekend in celebration of having the 2.2 patch done. I'll attempt to download that late tonight when the internet is good (maybe) and try a full reinstall to see if that changes anything. Did you make that GP with the ADE GP utility? Also which LIB is the little man in and what's his GUID? I'll try him as well...
If we keep messing with this we'll eventually have KLXV done - for FSX anyway...
Jim
Last edited:
- Messages
- 12,244
- Country
Well, I think we have proved it is a fault in the GP wizard,
The ground texture was a straight Re-sample, the cross-hatched poly was made with the ADE GP Editor and the little man is {0c943ad1-08a9-41c0-8f23-a460be151b9d} from FSXP_People.
I have downloaded P3D only once, all of the updates have been patches.
The ground texture was a straight Re-sample, the cross-hatched poly was made with the ADE GP Editor and the little man is {0c943ad1-08a9-41c0-8f23-a460be151b9d} from FSXP_People.
I have downloaded P3D only once, all of the updates have been patches.
- Messages
- 78
- Country
Guys,
I have been battling with this problem in FSX for years! We have been trying to tell people about it, but very few believed us, so all I can say is welcome to the party! ha ha ha!
I design scenery primarily for South Africa. Over here the shift in FSX is really bad. Objects we design must be designed off centre for effects to properly align or objects must be placed off centre so that they appear correctly aligned to the ground layer when FSX restarts. The default FSX did not have this problem, neither did FSX with the SP1 update. Since the SP2 update, that is when the problem started. Since Prepar3D uses the SP2 code, they inherited this bug from Microsoft.
What I have found out so far is that the shift is the result of the curvature of the earth as projected in FSX. I cannot explain it exactly. On the equator and the poles, there are no shift, but at certain points in between the degree of shift varies. In Cape Town which is S33 degrees, there is a minimal shift, but in Bloemfontein which is at S29 degrees, the shift is at it's worst. The further north you go, the shift dissipates.
In Prepar3D V2, this bug has been fixed for us in the South, but it appears as if you guys in the North have now inherited it! I have to un-adjust all my shifted objects to fit into Prepar3D V2 and you guys have to re-adjust yours to fit! I never thought I would see the day!
Kind Regards,
Nico Visagie
I have been battling with this problem in FSX for years! We have been trying to tell people about it, but very few believed us, so all I can say is welcome to the party! ha ha ha!
I design scenery primarily for South Africa. Over here the shift in FSX is really bad. Objects we design must be designed off centre for effects to properly align or objects must be placed off centre so that they appear correctly aligned to the ground layer when FSX restarts. The default FSX did not have this problem, neither did FSX with the SP1 update. Since the SP2 update, that is when the problem started. Since Prepar3D uses the SP2 code, they inherited this bug from Microsoft.
What I have found out so far is that the shift is the result of the curvature of the earth as projected in FSX. I cannot explain it exactly. On the equator and the poles, there are no shift, but at certain points in between the degree of shift varies. In Cape Town which is S33 degrees, there is a minimal shift, but in Bloemfontein which is at S29 degrees, the shift is at it's worst. The further north you go, the shift dissipates.
In Prepar3D V2, this bug has been fixed for us in the South, but it appears as if you guys in the North have now inherited it! I have to un-adjust all my shifted objects to fit into Prepar3D V2 and you guys have to re-adjust yours to fit! I never thought I would see the day!
Kind Regards,
Nico Visagie
- Messages
- 34,335
- Country
I'll try to reproduce it. Did you test at an airport at altitude as well, since that seems to influence as well.
Installing P3D 2.2 took quite long last evening, so I wasn't able to test with it. Hopefully I have the time tonight.
- Messages
- 34,335
- Country
It's indeed a nasty issue and since there is so much variation in it, it becomes hard to debug and understand.
The effects offset happened anywhere in FSX. It seems effects are rendered differently from other parts of the scenery.
Since you mention it starts in SP2 it might well be related to the drawcall batching, the shadow offset was also related to that.
Hopefully they can provide a good fix in P3D, because different places of the earth behaving differently is a hell for scenery designers. When we position some object it should just appear where we place it
.
- Messages
- 12,244
- Country
I used Jim's example, KLXV at 3026.054 metres. It works fine using only Resample for the ground textures and ADE for positioning the ASM polygon and library object.
- Messages
- 34,335
- Country
Hi all,
I have been doing some testing at KLXV as well. I haven't been able to reproduce the issue completely yet. But I haven't been able yet to make a resample layer to test the position against.
What I did was place ground polygons made with the GPW, place some poles that align with my grid in the ground polygons and place the same human as George did. I placed them all at the same reference coordinate.
At first I noticed an offset between my ground polygons and the poles. This was because I had drawcall batching enabled for them. As soon as I disabled the drawcall batching the ground polygons and the poles aligned correctly. This happened in both FSX and P3D v2.2. Funnily the shadows of the drawcall batched object were drawn at the right location.
So my conclusion from this is that drawcall batching is a bit buggy and should not be used at airports that are high above sea level.
The ground polygons themselves didn't seem to be moved. They showed at the expected coordinates and those coordinates were the same in FSX and in P3D. The human I placed was also well in line with the ground polygons in both sims.
Like I said I haven't tested with a resample layer yet, but until now everything seems to be working as expected, as long as I have drawcall batching disabled for my 3D objects (the human model btw also has drawcall batching disabled).
More testing tomorrow...
I have been doing some testing at KLXV as well. I haven't been able to reproduce the issue completely yet. But I haven't been able yet to make a resample layer to test the position against.
What I did was place ground polygons made with the GPW, place some poles that align with my grid in the ground polygons and place the same human as George did. I placed them all at the same reference coordinate.
At first I noticed an offset between my ground polygons and the poles. This was because I had drawcall batching enabled for them. As soon as I disabled the drawcall batching the ground polygons and the poles aligned correctly. This happened in both FSX and P3D v2.2. Funnily the shadows of the drawcall batched object were drawn at the right location.
So my conclusion from this is that drawcall batching is a bit buggy and should not be used at airports that are high above sea level.
The ground polygons themselves didn't seem to be moved. They showed at the expected coordinates and those coordinates were the same in FSX and in P3D. The human I placed was also well in line with the ground polygons in both sims.
Like I said I haven't tested with a resample layer yet, but until now everything seems to be working as expected, as long as I have drawcall batching disabled for my 3D objects (the human model btw also has drawcall batching disabled).
More testing tomorrow...
- Messages
- 12,244
- Country
Correct again Jim