Most efficient way of doing dynamic wraparound effect in Unreal Engine

Development Programming & Scripting
, ,
1

As title says, what would be the most efficient way of doing wraparound effect in Unreal Engine? Wraparound meaning the thing you can find for example in classic game “Asteroids” where no matter what object goes to edge of the screen and out of view causes said object to teleport to opposite side of the screen but for some objects teleporting could be switched off.

I have only tested it with very hardcoded system so far where manually placed hitboxes with overlap events trigger the teleportation. This has an obvious problem since it only works with one specific viewport size and with one specific camera type and FOV.

How would one proceed to make this system “dynamic” where when the game starts or even during gameplay there would be a way to place and move detectors so viewport size, camera type, fov and possibly distance are taken in to account so that desired actors will teleport once they are “out of bounds” so to say meaning they are just out of viewport?

I’m assuming it is better to handle with overlap boxes instead of having some check in tick event for every actor that’s on screen since that could affect performance if there’s possibility for many actors being on the screen at the same time… or would it?

2

Make base “Asteroid” actor.

Imagine you have 3x3 grid of screens. Your actor should be in all 9 at once in same local (to its grid cell) location.

So make actor that behaves however you need. Then in that actor make 9 meshes (components), with first one in center cell, and 8 copying local rotation and location from center one just to their cells.

tl/dr, manage actor (component) in center cell, and copy it over to all 8 surrounding it.

When camera moves outside center, snap it back on opposite location.

3

This multiplying all actors by 9 sounds bit like brute forcing and not so efficient, also if i understood this correctly it would only work if camera moves? It also doesn’t solve the thing i started this topic for which is how you can detect objects leaving the screen and a way of doing it when there’s many actors on screen without it being overly demanding.

4

So your camera does not move at all, does not follow player pawn? Exactly like classic asteroids?

Then you have static borders to where actor goes out of screen. So either put those as integer numbers in world space (or calculate them from camera location, fov and distance) then check if actor location is out of bounds, and teleport it exactly to opposite side. You can also check if actors are visible in camera.

If you make camera exactly above 0,0,0 and watching down, then coordinates in world space will be -x to +x and -y to +y, so quite easy math. And if something crossed -x edge place it at same location, just flip x coordinate.

However all particle effects probably will warp around, or at least it will be common side effect of teleporting actors. Probably can be done without annoying smudges.

ps.
And in aasteroids game, you max want to have around 100 moving things at once on screen (i think it is more like 40max). And 40 * 9 = 360 which is nowhere near big number, yes it is decent but unreal can do much bigger.

pps.
In god old asteroids you had some objects right on edge (or in corner) and they were visible on both edges of screen. So 3x3 grid of screens is easiest. I kind of remember it all because i coded that stuff years ago, just not sure in which language and hardware.

Also if camera is looking exactly down and over 0,0,0. Calculating if something is in screen or not is easy trigonometry. I think it is: camera_location.Z * tan(cameraFOV/2), but i did not checked this.

And if you dynamically change during game where edges are, what would happen to actors right on edge and visible on both sides? If for eg you zoom out a bit, there will be empty stripe around edges, but if you zoom in stuff will be outside game area.

5

Asteroids game was only provided as an example for the mechanic. The main point and answer i’m looking for here is how you can detect when an objects leave the visible game area and achieve the wraparound effect with that. And also thoughts about what being the most efficient way of doing it.

6

So your camera can be at any range, any angle, and have any FOV?
And can dynamically change location and forward vector.
And also gameplay area can be aligned to any plane?

for that you need Forward camera vector, normal for gameplay plane, and its location in 3d space.

Then simple vector math:

  • from camera forward vector and FOV calculate all 4 corner vectors (edges of camera “cone”)
  • then calculate where those vectors intersect with your gameplay plane
  • those 4 points will be corners of your gameplay area
  • last thin is checking if point/actor is inside gameplay area.

And then there is problem of actors right on edges, if its ok they just teleport, or you want anything on edge to be visible at both edges.

ps.
I asked my Yellow Rubber Duck to create function for it, but i am too lazy to check if it calculates all correctly.

And it looks wrong.

pps.
You can use “Project World To Screen”

IT will give you info if location is on screen or not. However again edge cases. If you check actor location and part of it is visible while actor location is behind edge, you will have disappearing actors.

7

I understand now that you have been advising for the literal wraparound, i.e. where you must have another actor appear on the right when another is about to go out of view on the left. I’m not looking for that specifically. It is OK for my purposes if the actors teleport.

In ortho view mode i can manage the simple enough check if actor vector abs is greater than ortho width + buffer / 2. Cause math is hard and i suck at it i have no idea how to implement this if you set constrained aspect ratio to false or the camera to perspective mode where FOV and camera distance must be taken in to consideration.

What bugs me about this is that if that’s bad practice to have many actors running math in tick event and if there is possibly a more efficient way of doing it.

I was also thinking of having hitboxes with overlap events filtering actors without specific tag that allows them to teleport. But then issue comes about how to properly move and scale those hitboxes on the edges depending on what type of camera you have and what’s its angle etc. That would at least require less processing if done that way since instead of doing calculation on dozens of actors you would only have 2 calculations for the horizontal and vertical edges…

8

Ok no worries about actors that appear out of thin air or vanish on edges.

Calculating and tracing hitbox on each actor it more resources hungry than some trigonometry done on actors location. Collision actors lags a lot at around 100.

When gameplay plane is constrained to for eg Z=0 math gets much simpler. IT kind of becomes scaling two triangles , so angle and distance to x-Y plane is enough. Simple trigonometry (if you draw camera with cone and gameplay surface)

If you want moving actors you need tick calculations.

Also you want simpler calculation make whole setup simpler:

  • simplest is x-y game surface and camera over 0,0,0 watching directly down, you know distance to 0,0,0 you can calculate gameplay area (or even try and test with some linear scaling). So play area would be: cameara.Z location * something and camera.X Location * something * screen ratio.

  • more complicated: camera at some angle, but along 0-x or 0-y. Then you have rhomb, and need some trigonometry to find corners.

  • and most complicated, vector math, get edges of camera cone , find where they get trough play area.

9

This collision information is new to me. Is it demanding even then when you must have collision enabled anyway for interactions with other objects in the game world? And are overlap and hit collisions equally as demanding?

The old teleport system i managed to do works very well in ortho view with a test cube and because of the precise math it looks like when it just left the screen it already starts to appear from the other side.

I’m still having trouble realizing that trigonometry for the perspective camera with variable fov and distance. Wouldn’t there also be a need to check how big actors mesh is?

For ortho view it’s easy because you can essentially imagine the world as tiles and objects are constrained to be the size of ie 1x1, 2x2 tiles… but for the perspective camera you would have take in to consideration their z scalar also.

When I get to it I will look in to that “project world to screen” and if the whole thing could be solved with that when using perspective camera.