Two bugs with changing camera boom length

I’m working on some 3rd person camera BP code, and found what appears to be an overlap event bug and a 1-frame rendering bug.

My game has a number of pawns that player can switch between.

Instead of having camera boom shorten automatically by turning “camera block” on in collision for all pawns, I have it generate an overlap event instead. This allows active pawn to move among other pawns without camera zooming rapidly in and out – instead, I want camera to only zoom in or out when it’s close to intersecting another pawn, so it doesn’t “cut into” other pawn.

first bug I’ve found is that if I only change boom length of camera arm (zooming in and out using mousewheel down and up), it does not generate an overlap event of either begin or end. This is bug #1.

At first, I tried to add a tiny amount to controller yaw input to trigger an overlap event whenever I change camera boom arm length, which sort-of works, but didn’t seem to be consistent. I was able to make it consistent by setting a flag and subtracting same amount to controller yaw input on next event tick.

Then I added code to test zooming in when an overlap is detected, and found a second bug:
if changing boom length allows an entirely-obscured object to be shown, it isn’t drawn for 1 frame (or 1 event tick?)

For example, one of my test characters is wearing a helmet, which is a separate object attached with a socket. If I zoom in on another pawn such that helmet of my active pawn is obscured behind other pawn, once camera pops past other pawn, my active pawn is seen for 1 frame without helmet. If active pawn is far away enough to be entirely covered by foreground pawn, it isn’t drawn at all for 1 frame (and then immediately appears).

This happens in both editor and if I build it and run app.

Hi Brian,

Thanks for report! Could you upload a test project that displays this behavior somewhere for me and then get us a download link? Dropbox or Google Drive are great for this. You can PM me on forums if privacy is preferable:

Thanks!

OK, a cut-down version of my project (22.7 MB which still manifests both bugs) is here:
https://dl.dropboxusercontent.com/u/62705302/boombug.

Right mouse button down will rotate camera with R-L mouse movement.

Mouse wheel should zoom in & out.

These two will allow you to see both bugs.

This has workaround for bug #1 - to see bug #1, remove or detach part labeled “REMOVE THIS FOR BUG #1” in EventGraph in AllGirls_Mouse_Character in folder Girls/AllGirls

If that part is removed, then if you rotate camera so you can zoom in & out near skeleton’s head, you will see that the “Begin” and “End” overlap messages do NOT print out, while rotating camera such that it intersects skeleton WILL print out, showing that merely zooming camera (by changing camera boom length) does not generate overlap events.

Bug #2 is now harder to see, at least on my system, since removing nearly everthing else allows frame rate to be very rapid, so it’s hard to see. However, if you put back workaround for bug #1, you can now zoom in and out near skeleton’s skull such that it obscures knight’s head + helmet, and you can see that she isn’t drawn with her helmet for a frame. You can see this more easily if you position camera so it keeps automatically zooming in & out rapidly, which you can usually get by rotating camera into skeleton’s skull. If skull entirely obscures her helmet, it won’t be drawn. If you can slow down frame rate, that should also show it.

Thanks for project! You can take that link down if you’d like.

As I was guessing, #1 isn’t a bug. What you’re doing is changing Spring Arm component’s length, but that doesn’t actually move camera. Overlap events fire off collision, which requires movement. That’s why it works when you rotate, because camera is actually being moved. By changing length of spring arm, all you’re doing is teleporting camera to a new position, so no overlap events will trigger.

Your workaround for this seems to work as far as I can see, but you mentioned some inconsistency so let me off an alternative solution: add a hidden blocking volume to character behind camera, and move it toward Spring Arm’s location with each scroll. If Do Collision Test is turned on, this should push camera rather than teleport it.

Alternatively, you could drop Spring Arm component altogether and create your own using a Line Trace and custom Trace Channels, which is all a spring arm really is, but that’s up to you.

It took me a bit, but I was finally able to see what you’re talking about with #2. character looks bald for a frame. I’m wondering if this occurs because camera is scaled down. I’m still looking into this, and I’ll let you know what I find out.

So I was wrong about Spring Arm adjustment not triggering overlaps. It looks like if I disable Do Collision Test in Spring Arm component, then zoom in and out behind skeleton, I get overlap prints just fine. Is that not happening for you?

Just to make sure I understand, you want to be able to disable Collision Test and move camera yourself when overlap occurs? If that’s case, you’d probably be better off doing a Sphere Trace around Character that searches for types of objects you want this to affect, and when it gets within a certain distance you shorten spring arm length.

It looks like helmet is actually being occluded automatically, and it takes a frame for it to render again. There are two hacky ways to get around this. In Project Settings > Rendering, you can disable Occlusion Culling. This will turn it off entirely, and anything you want occluded would need to be done manually. other thing you can do is increase Bounds Scale on helmet’s Static Mesh Component, which will make it larger so helmet is rendered even if skull is partly blocking it (use Show Bounds console command to see this during Play).

Neither of those are a terribly good idea, though, and may cause significant rendering problems if you have a lot going on in game. Instead, fixing issue with your Spring Arm component should solve this issue so it can’t flip back and forth so rapidly.

It looks like if I disable Do Collision Test in Spring Arm component, then zoom in and out behind skeleton, I get overlap prints just fine. Is that not happening for you?

Not without my workaround by doing a small yaw movement, no. If I use that workaround, I get overlaps, otherwise I don’t, even with Do Collision Test off in Spring Arm component. This is with 4.7.6-2513093. Are you using 4.8.x, which might be different?

Just to make sure I understand, you want to be able to disable Collision Test and move camera yourself when overlap occurs? If that’s case, you’d probably be better off doing a Sphere Trace around Character that searches for types of objects you want this to affect, and when it gets within a certain distance you shorten spring arm length.

Yes. I’ll look into that.

Neither of those are a terribly good idea, though, and may cause significant rendering problems if you have a lot going on in game. Instead, fixing issue with your Spring Arm component should solve this issue so it can’t flip back and forth so rapidly.

flipping back and forth only makes bug easier to see at a high FPS; it’s easy to see at 30-40 FPS, and that happens even when camera does exactly what I want – zooms in past another pawn and stops. So even if I get it working way I want, it will still not draw helmet for 1 frame under some situations.

But this does look like an actual rendering bug – if code changes spring arm length such that a previously fully-occluded object comes into view (for whatever reason), not drawing object for 1 frame is a bug.

If I turn off Occlusion Culling for 1 frame at right time, that might fix it without too much overhead. Edit: is it possible to do this?

I also tried scaling camera back to 1:1:1, but that didn’t change vanishing helmet problem.

Addendum:

OK, after adding some code that makes skeleton not visible when I press a key, doing same occlusion test with skeleton + helmet still has helmet not drawn for 1 frame when I set skeleton to “not visible”. So it’s a rendering problem unconnected to camera boom.

I’ve found a workaround of sorts for helmet rendering bug – turn on Use Attach Parent Bound.

Hey Brian,

Just wanted to let you know that I haven’t forgotten about this issue, and I’m still investigating it. It may very well be a rendering bug, but I can’t seem to isolate its cause. I tried recreating issue in a new Third Person template project, following your character and helmet setup as a guide, and I can’t reproduce problem.

Your project is too complex to send to developers, and I’m afraid I must be missing a step when setting this up from scratch. Are you able to reproduce this in a new project, using new assets? It seems like pertinent actors are character and helmet, and their parents.

I’m glad you found a workaround for now, at least. Thanks for letting us know!

I’ll see if I can reproduce bug in a new 3rd person project.

OK, I’ve got a new 3rd person project based on demo that shows bug.

There is a sphere that can attach to man when you press z

There is also a wall that vanishes when x is pressed and appears when x is released

You can also change camera boom length with g and h.

It is easy to see if you slow frame rate down to 10 FPS with `t.maxfps 10

To show bug, start play

set FPS to 10 or so

move camera about 180 degrees and move so wall obscures just right part of man

you can toggle wall visibility with x and see that sphere (attached or not) takes a frame to appear. Sometimes this isn’t seen if you happen to press x just before next frame is due.

If you attach sphere with z, you can note that sphere is drawn OK if even a part of it is visible past wall.

You can also see that moving camera “through” wall acts same as making wall vanish with x.

very simple changes are in man actor BP and level BP.

Here is a link to 16 MB file:
Dropbox - Error - Simplify your life.

Thanks for test project! I definitely see it when i slow down frame rate. I’m going to run this by developers and see what they think, and I’ll let you know what I find out.

After speaking with developers, this is just nature of occlusion culling. There will be a frame before actor can be drawn again. reason you’re seeing a different between character and attached item is that bounding box on character is quite large, and it is still in camera view. You can see this in editor viewport with “r.visualizeoccludedprimitives 1” and selecting character.

So in your test project, character wasn’t being occluded, but attached actor was, and there was a visible difference when one was drawn and other was not. By enabling Use Attach Parent Bound, as you’ve discovered, you are using character’s bounding box instead of attached item. This is correct way to handle this, so they will both be occluded or not at same time.

I entered a feature request to include an option to occlude actors individually (UE-16759), but currently you can increase bounds on individual actors to a very large size so it’s effectively never occluded.

Hope that helps!

In addition to UE-16759, or perhaps with it, would it work to disable occluding for an actor that is only in effect for one frame? That might work in some instances like my test example.

Like setting a delay before an actor is occluded? I’ll add that to request.

More like a 1-frame (or N-frame?) duration “don’t cull this actor” – for example, instead of using Attach Parent Bound, set “don’t cull this actor” to an attached object just before you know it’s going to be revealed, so it doesn’t appear a frame later because of culling.