I’ve been stuck on this problem for some time now for one of my plug-ins, and I’ve also posted on the answerhub on it:
but the guys over there were not able to help me unfortunately, so I thought I’d ask the people here as well
In a nutshell, I need to transform coordinates that I get from a third party device (origin in the top left of the primary screen, in pixels) to pixel coordinates in the game viewport, much like the engine already does with the mouse device.
My first approach was to try and figure out how the mouse is translated and do the same thing, but I soon discovered that this is controlled through the FSceneViewport class when in editor mode (the summary says “A viewport for use with Slate SViewport widgets.” so I’m assuming this is used in the editor). However I’m afraid that even though I manage to find a solution using this class, another implementation class might be used when building for release, although I haven’t been able to find any other overrides for the mouse methods in the FSceneViewport in any other parts of the solution, so maybe my fear is unwarranted.
But I digress, the problem with this class though (found in SceneViewport.cpp) is that it’s using a private member (and method parameters in associated functions) ‘FGeometry CachedGeometry;’ to perform the transformation, and there doesn’t seem to be any way to intercept or access it without modifying the engine source, which I would like to avoid since it would make using the plugin harder than needs be.
I got a suggestion on the answerhub to use the:
bool ScreenToPixel(const FVector4& ScreenPoint,FVector2D& OutPixelLocation) const;
class of functions in the FSceneView object which is readily accessible, but unfortunately, the screen mentioned here is just a different coordinate system for the same area, and not the actual O/S pixels, which makes it useless for my purposes
Has anyone already succeeded in doing what I’m trying to do? Or has a good idea on how to achieve it?
I’ve gotten it to work using both engine modifications (just exposing the FGeometry as public) as well as with mem-offset hacks to access the private member, but these methods are obviously not stable enough to use in a release
Any insight / help is much appreciated.