I’ve been dealing with kind of a difficult problem in the last few days, and have figured no solution so I thought about asking it here.
I’m trying to make a plane mesh fit the screen by modifying it in runtime according to the camera position and rotation.
I want the plane to be in the same position, but still fit the screen by rotating and changing the position of its vertices.
So what I thought about doing was:
Create a procedural mesh centered in the origin.
Use the camera distance to the plane, its horizontal FOV and its forward vector to calculate the “screen” length in the same axis of the plane.
Use the camera distance to the plane, its vertical FOV and its forward vector to calculate the “screen” height in the same axis of the plane.
Use trigonometry to calculate the distance of the camera to the horizontal and vertical center edges of the screen.
Use those distances to calculate the four corners of the “screen”, by adding two vectors at a time (for example, right edge plus up edge equals up right corner)
Use those vectors to change the plane procedural mesh’s coordinates.
Applying the camera’s world rotation to the plane procedural mesh
That’s a quick summary of what I have tried. However, the result is not the desired one. A few problems I have encountered:
A) The vertical FOV might not be correctly calculated
At first I thought it would be as simple as dividing the horizontal FOV by the aspect ratio, but then I found a function that gave me a slightly bigger value. However, with either of them, the height doesn’t seem to be enough, and it only seems to be correct when I use the same value as the horizontal FOV.
B) The rotation doesn’t have the desired result
When changing the vertices of the procedural mesh, the pivot of the mesh doesn’t change, so when I apply rotation on it, it keeps getting away when I rotate more and more.
Is there something wrong with this line of thought? Any other ideas to accomplish this?
Thank you for the reply.
That’s true, but in that case the plane would be constrained to the camera. I need the plane to be placed in the map by the user and just be there. When it leaves the camera’s FOV, it would not show anymore.
The goal is to use a material in that plane with a mask/opacity/etc. so that it mixes with the map itself. I have been able to accomplish this easily attaching the plane to the camera, but I’m needing this location-fixed pattern as well.
To avoid the mesh rotation problem, I placed it always centered in the camera forward vector multiplied by the distance to the render area. This workaround made me realize that the procedural mesh was no longer needed, and scaling a static mesh did the trick.
However, another problem did come up. The movement of the plane is not smooth, and it shakes a lot along its translation or rotation. Not sure if it has something to do with the mesh being edited every frame, or if it is something to do with the VIVE controllers with which I am controlling the camera. Need to do further research on this.
I’m showing a plane with some random material on it, and I’m moving the camera with a VIVE controller. The plane is not a component of the camera, and its coordinates are calculated entirely on its own, according to the position and rotation of the camera.
As you can see, it shakes a lot, and especially in quick movements, the corners take some time to get filled. In addition, I tried moving the camera with the mouse, and the result was the same, so I believe it is not an issue with the VIVE controller.
I wonder if this kind of mesh update every frame is too heavy to be done…
Thank you for the suggestion! I wasn’t aware of this functionality.
I tried putting an “FInterp To” node in all axis of the location, rotation and scale of the plane, and only then use the result values to set each one of them.
If the Interp Speed is slow, I am able to make a smooth transition from one position to the other (although it takes time to reach it), but if I put a higher value on the speed, the result is the same as before (the plane keeps shaking).
It did seem like a great solution, but I guess the position update every frame might be something that gets lag no matter what…