Progress Update #28
Better and Worse at the Same Time
I had two main tasks for this sprint: to transition the celestial body highlights to be world-space widgets, and to implement the ability to add an remove entire celestial bodies from the world.
World-Space Widgets
The reason I wanted to make the widgets world-space (WS) was because of the distortion that happens to objects that are at the edge of your FOV. This distortion made the highlights misalign when at the edge of the screen, even when they were at the perfect position on the center of the screen.
Center of Screen
Edge of Screen
The quickest way I could think of remedying this was to put the widgets in the same domain as the planets. This came with lots of unforeseen consequences even though the original problem was fixed.
Problem 1: Input
Now that the widgets were in WS I still needed to be able to interact with them. The solution provided by Epic was to use a Widget Interaction Component. Though I am sure this is useful, I'm guessing that the intended use case is for interacting with widgets while possessing a first person character. Eventually though, I came to find out that the widget components have a 'Receive Hardware Input' mode which, when activated, makes them behave just like screen space widgets when it comes to input.
Problem 2: Collision
I then noticed that further away widgets could not be clicked until the player moved closer. I found this to be the result of the scaling of the widget components. See, to get the widgets in world space to size correctly I had to scale them according to the size of the body; for larger bodies like the sun this meant they were scaled up 120x. This scaling would then make the widget take up the entire screen in some cases, meaning that it would always stop hits from going through to further away widgets. The way I "fixed" this was to make the scale as small as possible by making the highlight take up the entirety of the widget so that as little space as possible on the scaled component would be taken up by emptiness.
Part 2 of this problem which I have yet to fix is that the planets block hits. This means that the red dot would result in a click but the blue dot would not. This is incredibly annoying and an objective downgrade from screen-space widgets.
Now that the widget had to constantly rotate in the world to face the camera there was an oddity that would happen when the camera rotated upside-down. That being that the widget would also go upside-down. I managed to make it better, but you can still see it flicker when the angles are just right.
Problem 4: Rendering
You may have noticed in that video the trail of the info panel. That's not your monitor breaking, that was part of the video and it's the rendering issue I haven't solved yet. The other rendering issue I did manage to solve was the issue of the widget being rendered behind the planets. This was an especially big issue when you would add a noise layer and suddenly the widget would be covered completely:
This was fixed by setting "Disable Depth Test" in the material to true and making sure the blend mode on the material instance was Translucent. Now it renders on top but that kind of defeats the purpose of a WS widget.
At this point you might be thinking "Wow, that sure is a lot of issues for something that should have been a fix. It must be worth it though right?". The answer to that rhetorical question is NO. I really think that in fixing one problem I have created a few dozen and it is worse in almost every way than when I started "fixing" it. I am now thinking that I should revert to the screen-space widgets and instead apply a material to them that will apply a distortion in the same way the FOV does.
Adding/Removing Bodies From the System
In comparison to the WS widgets, this was quite simple. I added a function each for adding and removing bodies, then made a temporary combo box widget element to interface with them.
I also made a widget to confirm deletion of a body as there is currently no way to roll a change like that back.
The background blur on this also acts to stop the player from interacting with anything else until the dialogue is answered.
Then for saving/loading. In a previous update I showed the saving code so I will show the loading code here:
For a little clarification, the loop on line 6 is to check if the current body that is being loaded already exists as part of the map file and thus does not need to create a new actor because creating two actors with the same name crashes Unreal.
In conclusion, I will be reworking the planet highlights (again) in the future as the current rework is less than satisfactory. Next weeks features also may end up making the info panel on highlights obsolete anyway :')
Comments
Post a Comment