P3D v2 Ground poly shift?

[JRobinson]

Let me check, my laptop is not that powerful so I also tuned the settings a bit down.

What does the tessellation actually do?

I think the advanced wave animations rely on tessellation (the ones that change with the wind direction & speed), it's supposed to tessellate polys into the mesh adding more detail as well I think. If you check the "What's New in v2.x" pages in the learning center it tells a bit about it - not much. There was a problem with v2.0 where aircraft would bounce on the runways with tessellation enabled, they fixed that at v2.1 but I'm not so sure this shifting isn't a result of that fix, dunno. Previously, disabling tessellation would also disable shadows except for those associated with the user aircraft, at v2.1 they also fixed it so shadows work with tessellation off which may also have caused this side effect. I think I'm content to leave tessellation off personally, I don't see what it does to the mesh and I don't spend much time over water, but I doubt the GTX780/Titan crowd would stand for it regardless of whether they can tell the difference in the sim or not .

 

[arno]

Let me do some searching on what it does. I assume it uses tessellation shaders indeed to let the graphics card modify polygons. I can see the benefit of that. But I don't see why it should affect position accuracy yet.

 

[GHD]

It is not just scenery objects, xml aprons are also affected. The problem is that the photo-textures are displaced to the south.

I have reported this on the P3D forum.

 

[ralinn]

Seems this is still an issue in V2.3

 

[GHD]

Try switching off tesselation.

 

[nangua]

Hope this thread isn't too old to re-animate, but I thought I'd add a couple of observations.

I just bought P3D (so I'm running v2.3) a few days ago, and immediately noticed that some of my scenery created by ADE was out of alignment. Items mis-aligned included polygons and lines drawn by ADE's new Ground Polygon editor, and normal terrain/landclass polygons. I don't see XML aprons being misaligned with other scenery objects or with taxiways and runways; it only seems to be relative to landclass and ground polygons. After looking around, I found this thread, and followed Mr. Robinson's suggestion to turn off tessellation. That fixed the problem. Most of my airports in the area that I'm working on are around 3000 ft MSL, so there seems to be an altitude factor in the shift.

Sadly, if I turn off tessellation, my graphics card (Intel HD 4600 with the latest driver) no longer renders cloud shadows properly, so it's a matter of choosing between nice cloud shadows or slightly mis-aligned scenery at airports.

Hopefully LM will find a way to fix the misalignment in a future update.

Cheers,

David

 

[ralinn]

Hope this thread isn't too old to re-animate, but I thought I'd add a couple of observations.

I just bought P3D (so I'm running v2.3) a few days ago, and immediately noticed that some of my scenery created by ADE was out of alignment. Items mis-aligned included polygons and lines drawn by ADE's new Ground Polygon editor, and normal terrain/landclass polygons. I don't see XML aprons being misaligned with other scenery objects or with taxiways and runways; it only seems to be relative to landclass and ground polygons. After looking around, I found this thread, and followed Mr. Robinson's suggestion to turn off tessellation. That fixed the problem. Most of my airports in the area that I'm working on are around 3000 ft MSL, so there seems to be an altitude factor in the shift.

Sadly, if I turn off tessellation, my graphics card (Intel HD 4600 with the latest driver) no longer renders cloud shadows properly, so it's a matter of choosing between nice cloud shadows or slightly mis-aligned scenery at airports.

Hopefully LM will find a way to fix the misalignment in a future update.

Cheers,

David

Looking at the v2.4 release notes, it seems this issue is still not fixed. Turning off Tessellation is indeed a work around for some but does not seem to work for me.

I'm hoping this is fixed soon as it will be delaying a few of our releases!

- Russ

 

[JRobinson]

Turning off tessellation does seem to fix the shifting for me but as mentioned it really screws the shadows and not just the cloud shadows. I don't think requiring a user to turn off tessellation in order to run a 3rd party scenery would ever fly anyway to be honest. I have a v2.4 release candidate installed and I can confirm the tessellation shift is still there BTW. Seems we have the original batched object shift that we've gotten used to in FSX and now also this new tessellation shift so two different shifts from what I can tell.

I shifted a bunch of placements mathematically with Excel for a previous project, it wasn't difficult once I got the process down. Basically I used a macro in an advanced text editor (textpad) to parse the lats/lons from my placements into columns, pasted those into Excel and applied an offset, then used another macro to parse the corrected lats/lons back into the placement XML. The hardest part was coming up with the offset value which I did by fudging a placement with IS2 in FSX so that it came out where I wanted it in P3D2. Then I compared the lat/lon with that from a "non-fudged" placement and calculated the offset. PITA but it worked.

I guess the same offset should work in the GP wizard, but as it turned out my GP hadn't shifted enough to worry about it and any objects placed on the GP seemed to shift right along with the GP so I didn't need to shift those. They had already been compensated for batched object shift in FSX however.

Jim

 

[ralinn]

Turning off tessellation does seem to fix the shifting for me but as mentioned it really screws the shadows and not just the cloud shadows. I don't think requiring a user to turn off tessellation in order to run a 3rd party scenery would ever fly anyway to be honest. I have a v2.4 release candidate installed and I can confirm the tessellation shift is still there BTW. Seems we have the original batched object shift that we've gotten used to in FSX and now also this new tessellation shift so two different shifts from what I can tell.

I shifted a bunch of placements mathematically with Excel for a previous project, it wasn't difficult once I got the process down. Basically I used a macro in an advanced text editor (textpad) to parse the lats/lons from my placements into columns, pasted those into Excel and applied an offset, then used another macro to parse the corrected lats/lons back into the placement XML. The hardest part was coming up with the offset value which I did by fudging a placement with IS2 in FSX so that it came out where I wanted it in P3D2. Then I compared the lat/lon with that from a "non-fudged" placement and calculated the offset. PITA but it worked.

I guess the same offset should work in the GP wizard, but as it turned out my GP hadn't shifted enough to worry about it and any objects placed on the GP seemed to shift right along with the GP so I didn't need to shift those. They had already been compensated for batched object shift in FSX however.

Jim

Great work!

My work flow now compensates for the batched object shift in IS, so this is something I can live with. Doing things in a particular order will stop it from becoming too troublesome and time consuming.

My biggest concern now is the PR shift which absolutely ruins the quality of the 3 airports I'm currently working on in P3D. For the airport I'm currently working on, it's pretty much being designed for (and in) P3D. I'm creating and finishing the whole scene in one file and will be placing it in P3D before FSX. Of course, this will prove awkward for FSX compatibility if I'm technically placing it in the wrong location.

Do we have any confirmation that LM are aware of the issue?

- Russ

 

[JRobinson]

It's been brought to their attention and Beau Hollis did reply to the thread so they are aware. I think there's a lot of focus on the sim director end of things at the moment so I'm not sure where we stand on the priority list. Maybe v3.0?

I think it might be possible to shift a PR by editing the coords as well, in fact I think Mir did that with FlightBeam KDEN but I'm not sure. If turning tessellation off doesn't make things snap back into place for you however it would be difficult to come up with an offset. I'm a little foggy on the details of the problem right now, I've got two going that are both less than 100' MSL so I haven't been shifting anything. What is it that's so critical with the PR that you can't just let it float around a little and compensate your placements relative to the PR? Not lining up with the mesh?

Jim

 

[ralinn]

Thanks for the update, I'm glad they're aware of it!

There's a few things I can do, but at the moment I'm just tempted to leave it as it is, as knowing my luck it will be fixed before we release!

The main reason I've been hesitating to change the placements is because of the sheer number of placements I'd have to deal with. Lots of vegetation, POIs, clutter and other small misc things will make it a nightmare, especially with the 5 meter shift I've been dealing with because the airport is at such a high alt.

I'm tempted to put an offset on the PR, but at the moment I'm leaving it as a last resort, as I'm not entirely sure of what the consequences will be. I have a feeling it will break quite a few things... like flattening, blending, autogen, etc. It scares me, and I'd be tempted to flip a table if a hotfix is released after I've dealt with all of that

- Russ