Hi,
I’m on a quest to figure out a very tricky problem, together with @Everynone
We all know the very handy Move Tool in the editor.
Here it is in all its glory:
Well, you surely have noticed that it has a superpower: regardless of where an object is placed, the Move Tool is always rendered exactly at the same scale on the viewport.
I tried rescaling in runtime, which kinda worked but then breaks down at very large distances. I use ludicrous distances of billions of units (the engine works perfectly with a couple of tricks) and unfortunately no other method could work for my game (world composition included)
We know however that the Move Tool is perfectly stable even when the object to move is at basically infinite distance. So the distance in itself cannot be the issue, if the tool is done right
I tried to keep my ‘custom-made Move Tool’ always in front of my camera, but it ended up a very goofy object floating around lazily, practically useless and creating only confusion
I also tried to just ‘rescale’ the material to increase the WorldOffset with the camera distance, which looks like it’s working… until you try to interact with the tool and it doesn’t work, both because the physical collision of the mesh still stays the same and doesn’t rescale with just the material, and again because of the distance limitation.
I’m now trying to use a Capture2D method (which is also failing) but it looks not quite the way the Move Tool is made.
Does anyone know how this amazing tool is actually made?
100 cookie points for whoever has good hints!
I’m not savvy enough to do the actual work but it seems like that would solve sizing issues, then you need to convert from screen space to the world, but I think there is a bit of inbuilt tools for that arleady?
Hi, thanks for the hint
It really looks like one. As far as I can see, widgets are the only ones who can “live” on the screen space and stay identical to themselves whatever happens.
The way I’m trying to recreate it now is by placing my custom-made Move Tool in front of a Capture2D camera, then project it onto a texture, which goes into a widget
I need now to figure out how to interact with the object although it’s projected onto the texture… hmmmmmm
Hopefully this would be the right way to do it?
I’m digging, digging, digging and I found that there are a few classes which are called “Gizmos”.
Apparently they are the Gizmo Actors which we are looking for.
The issue is that trying to spawn such actor is very difficult.
I tried to make blueprints to inherit from them, but without success.
Apparently they have c++ functions to generate their components, here is the path to the .h file, plus a code snippet.
Small issue: I have too little c++ skills to make use of these functions
I’m trying to go the blueprint way, but gizmos seem hard to spawn…
You can call “spawn actor” in a blueprint to spawn a Gizmo Actor, but they have something in their code which makes them disappear as soon as I try to spawn them.
Anyone has any clue on how to have a try on using these gizmos in the actual game?
As this has quickly become a C++ discussion, I moved the thread into the C++ section of the Forum, hoping that some savvy C++ expert will look into this and give us a big hand!
Amazing!
The solution lies in the math library: the gizmo is constantly re-scaled to be always the same size on the screen.
Crazy good quality. It will take quite some work to adapt to my game, but this is it!
Well actually… I was a little too excited
On one hand it is indeed a very good implementation of the gizmo, but there is one issue remaining: when zooming out too far (several km away), although the gizmo stays the same size, it does not interact anymore with the mouse pointer.
In fact it also relies on the collision check operated by LineTraceByChannel.
After a certain zoom out it also starts giving errors due to the immense rescaling needed:
So 75% of the problem is indeed solved, now the final step is: how to make this custom gizmo able to interact with the mouse pointer at ANY infinite distance, like the native UE gizmo does?
I have implemented my gizmo in Polars with a capsule collision around the arrows, which listens to OnClicked. I suppose UE4 still traces, so maybe it doesn’t help at all, but just wanted to share it.
What you could alternative do to avoid tracing is projecting the center of the gizmo and the tip of each arrow to screen space when you click, and check if any of those segments (with the width of your arrows) contain the click position. This way, you don’t rely on PhysX (although you might run into other challenges).
