Offset in Convert World Location to Screen Location

UFG_02 · December 10, 2014, 8:04pm

There seems to be a strange bug on our designer’s machine (only) that causes the above convert function to report values that are offset up and to the left. We’re using this call to draw some reticle targeting widgets over some of our characters. They line up perfectly except on this one machine. Specifically the offset is (93, 153) pixels.

When we delete and resync the unreal Engine folder, the problem goes away…for a few days. It reared its head again today. This started when we upgraded to 4.6 (from 4.5), It ‘feels’ like there is stale data sitting around somewhere. It does NOT fix it when we only resync the project… must be the engine.

I’ve looked in the registry in case there’s some window dimension info stored there… but no luck. Any ideas? Is any of the data used in the projection or viewport matrices cached anywhere?

Thanks

Pierdek · December 10, 2014, 9:20pm

Check differences in config files, “your module”/Saved/Config/

UFG_02 · December 10, 2014, 11:07pm

OK, thanks. If (when?) it happens again I’ll do a thorough comparison of those ini files.

UFG_02 · December 12, 2014, 2:44am

Well, it started happening on my machine today! Funny how it got a bit more attention cuz of this Here’s what I found: The file Engine/Saved/Config/Windows/EditorGameAgnostic.ini was causing the problem. A good file looked something like this:

[/Script/UnrealEd.EditorGameAgnosticSettings]
RecentlyOpenedProjectFiles=D:/BLABLA/dev-unreal.4.6/BLABLA/BLABLA.uproject
bCopyStarterContentPreference=True
AutoScalabilityWorkScaleAmount=1.000000

while a bad file had this added:

[/Script/IntroTutorials.TutorialStateSettings]
TutorialsProgress=(Tutorial=/Engine/Tutorial/Basics/LevelEditorAttract.LevelEditorAttract_C,CurrentStage=0,bUserDismissed=False)

[EngineBenchmarkResult]
Valid=True
ResolutionQuality=71
ViewDistanceQuality=1
AntiAliasingQuality=1
ShadowQuality=1
PostProcessQuality=1
TextureQuality=1
EffectsQuality=1

[ScalabilityGroups]
sg.ResolutionQuality=71
sg.ViewDistanceQuality=1
sg.AntiAliasingQuality=1
sg.ShadowQuality=1
sg.PostProcessQuality=1
sg.TextureQuality=1
sg.EffectsQuality=1

anonymous_user_208e3372 · December 12, 2014, 5:42pm

Hey, just had the same problem (or something similar).

If you are using UMG and not pure slate to draw, which i just assume here, you need to use ‘Set Position in Viewport’ instead of the ‘Render Translation/Transform’ function. Also make sure you do not use sth like a Overlay Node with centered align or other Panels that align your content, or at least use them wise.

Here is a forum post i stumbled upon: [UMG and dynamic positions][1]

UFG_02 · December 13, 2014, 3:04am

Hi gormed, thanks for the response. Turns out we are calling ‘Set Position in Viewport’. I’m pretty sure it’s the convert call. Luckily the .ini file has not reverted back to the borked version for us… knock on wood. When I manually set it, the problem returns.

fabs · January 5, 2015, 3:21pm

Me too now.

The HHDrawText pretty much just calls HUD::DrawText, and it’s seeing the offset as well. It does seem to be the WorldToScreen (i’ve never seen this working though, it’s always been offset.)
When I check out where the thing is being rendered on screen, it does appear to be at the right pixel position accoding to the render call input. The values the world to screen function (bool APlayerController::ProjectWorldLocationToScreen(FVector WorldLocation, FVector2D& ScreenLocation) const
) retrurn, appear to be wrong.

anonymous_user_9d7112cd · January 5, 2015, 7:00pm

Anecdotally, one of our team members reported that when he resized the viewport window it fixed the issue. Strange that it would affect the non-‘selected viewport’ play options, but anyways.

–tri7 (was UFG 02)

DamirH · January 8, 2015, 8:39am

Heya,

I just started getting the same issue and with the same logic (targeting overlay). However, this is 4.6 and I cannot seem to find the .ini file you noted as being the cause. Nothing seems to fix it for me unfortunately.

EDIT:
Found it. The scalability settings had my resolution set to 75% (auto detect).

Denny · January 8, 2015, 1:15pm

We had the same issues when Resolution Scale is used in the Engine Scalability Settings. This is how we worked with the issue.

fabs · January 9, 2015, 4:58pm

this seems to make things worse, not better, for me. Also, what’s screen percent? The offset I’m seeing appears to be non-linear. Mostly a constant offset, with some linear scaling as the object gets nearer, but also odd behaviour at the edge of vision.

Denny · January 9, 2015, 5:10pm

ScreenPercentage is another word for Resolution Scale. We fetched it via C++.

fabs · January 30, 2015, 8:39am

I fixed it for us, but it’s not something people will be able to use unless they have access to the engine source.

I modified this function:

bool FSceneView::ScreenToPixel(const FVector4& ScreenPoint,FVector2D& OutPixelLocation) const

the issue seems to be that the screentopixel is using the ViewRect, not the UnscaledViewRect. You can see later in the source that the DeprojectFVector2D uses the UnscaledViewRect over the ViewRect, so this looks like an oversight in updating all the code that uses ViewRect while adding the function:

void FSceneView::SetScaledViewRect(FIntRect InScaledViewRect)

Is this already fixed in 4.7? I don’t have access to the preview source.

anonymous_user_9d7112cd · February 11, 2015, 6:24pm

fabs-ulous. I’ve made same change locally and can confirm it fixed it when using the borked ini file. Thanks.

Co · April 1, 2015, 8:28am

Thx fabs() your fix is working for us, the bug was still present in 4.7.3.

If any Epic STAFF member can have a look at this and validate/invalidate that it is a bug or a wanted behavior it would be fantastic.

hjeldin · April 12, 2015, 4:34am

The issue seems present in 4.7.5 too.

ABrookesy · January 10, 2021, 5:24am

Can confirm this works for me - the screen resolution offset appears to be the main culprit: