WingedKagouti on 19/3/2019 at 08:57

---

That actually sounds like one of the best reasons for cutting something.

"Was it technically difficult to implement?" on its own rarely provides a positive answer to "Does it improve the experience for the player?"

Nameless Voice on 19/3/2019 at 14:00

---

I'm imagining something like Infra's camera, which showed a smaller version of the view.
That worked fine, but I guess Infra's graphics weren't especially complex, and so it could probably afford to render everything twice.

qolelis on 19/3/2019 at 19:42

---

It's a puzzle explorer.

I'm saving all code and assets for the methods I'm archiving, so might use them for something else some day.

Capture camera view:
(https://youtu.be/hmlBSfcQNKo)

In Unreal, I use a SceneCaptureComponent2D to capture a view and then project it onto a render target, which can be painted on for example an object or a UI surface. In the video above I project it onto a plane, which I have attached to the player view at the right distance. I also implemented switching between landscape and portrait mode (mostly because I could and because that's something you can do in real life, so why not...). Zooming is done by changing the FOV. As mentioned before, there are a couple of problems with this method:

* I must handle collisions between the render target plane (camera plane) and other objects (which I never implemented),
* I want to be able to hilight selected objects also via the camera view (the same way I do it via the standard view), which I do via a post process material applied to either the first person camera or the scene capture component. The problem is that the scene capture component applies post process materials only to a lower quality render source, which also significantly alters the captured view, so I had to tweak other settings to make it look somewhat like the standard view.
* For switching between landscape, portrait, and "selfie" mode, I rotate either the render target plane or the scene capture component, which took a while to get right and there are still one case where the view gets turned upside-down, because I'm rotating the wrong way (switching to quaternion rotation didn't help in that case). I also attached the scene capture component to the render target plane to avoid having to update its location, which probably isn't making the rotations any easier.


The scene capture works pretty well in this case (on my antique machine) and wasn't what took the longest to get working. Everything would probably be solved eventually, though.

Capture camera surroundings:
(https://youtu.be/MInVzg2Kcho)

Here I instead capture the view surrounding the camera, which means projecting it onto a fullscreen UI surface. The camera view is shown by cutting a hole in the render target texture via a dynamic material. I only implemented portrait mode, but the idea is to set the correct texture mask in the dynamic material via C++ when switching between portrait and landscape modes. I don't have to deal with collisions, since the render target isn't present in the game world, and don't have to worry about objects not hilighting, because the camera view is the same as the standard view, but now there are other problems to deal with:

* The captured view is projected onto a larger surface, so performance-wise it's worse than the previous method.
* The widget for showing a UI image has a setting for tinting the image with a set colour. This setting is unfortunately always applied, so the captured view will always look different than the standard view. I sort of bypassed this by making it look different enough to appear intentional.
*



Let the camera be fullscreen (without capturing anything):
(https://youtu.be/m-hMzOQj0J8)

This is the candidate for the ultimate and final method. No scene capturing needs to be done, because the camera view and the standard view are one and the same, and is also applied fullscreen. Switching to camera view is still pretty subtle, but I'm working on adding more icons to the camera HUD to make it stand out more. The device in which the camera is included is kind of like a smartphone, so it will have a couple of other apps, of which some will definitely benefit from being shown fullscreen, so making also the camera app fullscreen is good for consistency's sake.

There is also a fourth method, which I haven't implemented yet, but it's basically the first method, but instead projecting onto a UI surface, so I wouldn't have to deal with collisions and could simplify some of the rotations.

qolelis on 9/4/2019 at 20:45

---

Once the deed was done it felt like the right decision. I was going to post a follow-up earlier, but got busy with other things and didn't merge the change into master until only a few days ago. This is what it looks like right now:
[video=youtube_share;PnRKDXSosM8]https://youtu.be/PnRKDXSosM8[/video]

I added a simple border (extra details can be added later) to make it stand apart from non-camera mode, a zoom slider (controlled via mouse-wheel or by dragging the handle), and also a slight tint to the view to make it extra clear that something has changed. Adding a tint might seem ironic after having worked so hard to avoid it, but, now that I have full control over it, it felt like the right thing to do. The other thing I've been working on will share the same border (and might also take advantage of the camera view).

Right now I'm using Unreal's visual UI tool, UMG, to build the interfaces. UMG is nice to work with, but, as you can see in the video, sliders tend to lag quite a bit. I will have to look into that later.



Yup, that's what I came to realize; things were getting unnecessarily complicated for something that didn't really, really need to be.



The performance drop wasn't too severe (on a good day), but that wasn't the only thing to consider, and now I can save the resources for when it really matters.

Judith on 26/4/2019 at 05:46

---

First window models:

(https://postimg.cc/7GbHCnBL) https://i.postimg.cc/7GbHCnBL/obraz.png