Strange line of sight behaviour

[JaredP94]

Hi @npruehs!

Been a little while, hope you're well :)

I've been attempting to implement the complete fog of war functionality, with the last step being the line of sight feature. On the demo project, it works as expected, but I'm seeing fairly unreliable line of sight behaviour within my project (video attached below).

I've played around with the Level Height setting of the vision volume but either yielded the same behaviour, or reduced to a value where line of sight was never blocked by objects.

Any advice on where to dig further into this?

Thanks!

UnrealCoH.-.Unreal.Editor.2021-05-18.21-21-01.mp4

[npruehs]

Hey @JaredP94!

Sorry for the late reply. I assume that your actors don't have "Ignores Height Levels" checked on their RTSVisionComponent.

Assuming that's not the case, the plugin will compare the height level of the tile being looked at to the height level of the moving actor. These tile heights in turn are cached when the game starts (ARTSVisionVolume::Initialize) for performance reasons, so my next question would be whether your level geometry (vision obstacles) are in place from the very beginning, or not.

If so, the tile height is determined by casting a ray from "infinity" (Z = 10000.0f) downwards (to Z = -10000.0f) against the HeightLevelTraceChannel of your vision volume, so you'd want to check whether these traces are actually able to hit your vision obstacle.

If so, the resulting Z value is divided by the Level Height of your vision volume (and floored) to get discrete height levels.

If that resulting height level of the tile is above the one of the actor, the actor is considered to have no vision on that tile.

If the actor has vision on a nearby tile, the algorithm continues to check the next tile along line of sight using a simple Bresenham algorithm, until it hits a tile the actor doesn't have vision on.

Does that make any sense to you?
Nick

[JaredP94]

Hi @npruehs,

Appreciate the detailed feedback!

> I assume that your actors don't have "Ignores Height Levels" checked on their RTSVisionComponent.
That is correct.

>so my next question would be whether your level geometry (vision obstacles) are in place from the very beginning, or not.
All objects in question are static and placed in the level prior to startup.

> so you'd want to check whether these traces are actually able to hit your vision obstacle.
I've validated that the objects are well within bounds.

What's interesting is how some objects seem to block vision from one direction, but not from the other, or that objects of equal height seem to exhibit completely different vision blocking. I thought the rugged terrain might have an impact since the demo level is flat, and the shift in terrain is causing some interesting behaviour, but I would expect a bigger tile height to resolve that (and it doesn't really affect the main point of reliable vision blocking from tall objects).

[npruehs]

"objects of equal height seem to exhibit completely different vision blocking"

Technically, this could happen if you're you're not using enough tiles, i.e. we use too few rays to properly sample the heights everywhere.

"some objects seem to block vision from one direction, but not from the other"

This however is hard to explain and sounds more like a bug to me...

Hard to tell without having a closer look on your setup. Any chance you might be able to share your project, or a minimal repro if you're more comfortable with that?

[JaredP94]

> Technically, this could happen if you're you're not using enough tiles, i.e. we use too few rays to properly sample the heights everywhere.
I have experimented with an increased number of tiles, but it did not appear to yield any better behaviour. Interestingly, I did notice that bumping up the tile size seemed to hurt the minimap rendering (but I'll comment further on that when I test further this week).

> Any chance you might be able to share your project, or a minimal repro if you're more comfortable with that?
This is certainly something I can do. It is currently private, so I would need to add you as a collaborator to look at it. I have also made the transition to UE5EA (yay!) so unless you have it installed, you would need to checkout a commit prior to the conversion. Let me know if you're happy with this? Obviously I would like to make it as quick and easy as possible for you :)

Thanks again for digging into this!

[npruehs]

Sure, whatever works for you. I've got UE5 installed as well :)

[JaredP94]

Nice, that should work out the box then!

Don't mind the current state of things, seems upgrading to UE5 has broken quite a few things in our project, most notably around animation. Guess it's time to hop over to control rig once and for all :)

I have added you as a collaborator, please shout if you have any issues getting everything to build and run :)

[npruehs]

Which repo is that? I don't think I got a notification - I might have just missed it, though. Filters show nothing.

[JaredP94]

Sorry for the delayed response!

I see the invitation is still pending - you should be able to access it here: https://github.com/JaredP94/Unreal-CoH

[npruehs]

It says "This invitation has expired."

[JaredP94]

Hi @npruehs, sorry for the delay - life has been a bit busy :)

I've just sent a new invite!