[SUPPORT] Line of Sight Visualization

Hi Bebop, thanks for another excellent suggestion. The system currently takes all the required vision parameters at the start and calculates all required values right then to cut down on redundant calculations at runtime. Hence the reason why you don’t notice any changes happening at runtime despite modifying vision angle/radius.

But I believe it should be possible to add in an extra function that could be called to reset the visualization whenever required. I’ll do some tests and if everything works out fine, I’ll roll out a new update next week with said changes.

Hey, I got the runtime vision customization working. I’ll be submitting an update later today to patch it in, but you can easily get it working in your existing project by making a couple of node changes:

Calling this new RefreshVisualization event will enable you to have the visualization reflect any changes you’ve made to the pawn’s vision range parameters at runtime.

The v1.2.3 update is now available on the Marketplace.

New Features:

I. Added support for runtime customization of the Line of Sight visualization: You can now call the “RefreshVisualization” event in the component to manually update the visualization range any time there is a change in the vision radius/angle of your character.

Here is a quick preview showcasing the feature:

Additional Notes: You can find the new blueprint changes by searching for the keyword “Version1_2_3”.

Hi Stormrage256

I purchased this plugin for a project I’m working on and it’s been really helpful. However, I’m trying develop it further to get it to calculate floor area measurements. Is there a way this can be done?
Also is there any intention to develop this into a 3D radar to analysis full room spaces?

Look forward to hear from you. Many thanks

Hi there, could you provide an example scenario of what type of measurements you’re trying to calculate?

Currently, there are no plans to extend this to 3D line of sight since the same algorithm if used in full 3D would require a lot more ray trace calculations/procedural mesh updates and quite likely cause performance issues.

Sure, so I would like to be able to calculate the area coverage of the DirectLosMesh within a level and update that value in runtime similar to the way your vertex count and raycast count is updatng as it is moved in level. That way I can convert it to a total percentage of the level area in which the DirectLosMesh has covered. Hope that makes sense.

Alright, so yea that should be possible. We should be able to do that by calculating the area of individual triangles and adding them all. I’ll test it out and get back to you.

Ok great, that makes sense. Look forward to your response. If you can get back to me this week that would be amazing.
Many thanks

Alright so you can use this method to calculate the area covered by the line of sight visualization:

For reference, this is the formula that I’m using here: How to calculate the area of a 3D triangle? - Mathematics Stack Exchange

Hi Stormrage,

Thanks for the update, I have applied your maths code to my project however the calculations do not appear to be outputting correctly. Also when I move the playerpawn (as seen in the 2 screen shots) the area varies but the box I have imported is a 10mx10m box so the total area should be comparable to 100m2. I’m not entirely sure what units I’m getting in the print text but I’m pretty sure they are not accurate for conversion.

FYI: The testing has the same effect in both 4.27 and 5.0.3, but I’m going to be using this plugin in a 5.0.3 project and everything is functional except the area calculations.

Any ideas on a possible solution? and What kind of result did you get when you tested?

Many Thanks


Well 1 unit in Unreal is equal to 1 cm. So it comes to around 165 and 120 sq.m in this case. But I think I know what’s causing this. I believe the vertices are stored in groups of 3 in the proc mesh section. So the for loop might be looping through the same vertices multiple times causing the area to go higher than the real value. I’ll make the changes and let you know later tomorrow.

Also, I would suggest using the toolkit in 4.27 since I’ve noticed a performance drop after converting to 5.0. I haven’t been able to figure out what is causing it, hence the reason why there is no official support for 5.0 onwards. So before proceeding with 5.0, just make sure that the performance is alright in your project.

1 Like

Yeah I thought it might be cms. Did you have a chance to look at the fix?

Also I have one more feature I’m trying to add to this plugin which is the ability to detect what static mesh actors are overlapping the Direct Lo SMesh via tags. However, I’m struggling to implement it, I tried using GetOverlappingActors and considered a MultisphereTraceChannel for a sweep in a set radius. But I need it to be SM Actors only overlapping the generated Direct Lo SMesh. Any ideas?

Many thanks bud

Alright, the vertices are stored normally. There are no duplicates, it’s just the triangles array that map to these vertices that are stored in groups of 3. The issue was actually related to me not adding both proc mesh sections for the calculations.

Section 0 is the default number of vertices used to display the line of sight. However, if there are obstacles in the visualization area, then additional vertices are added near the edges of said obstacles while the rest of the vision cone can still function with lower number of vertices. These additional vertices are added to Section 1.

After including the additional proc mesh section on a 3000x3000 walled off area, I’m getting an area 8999796. The small difference from the 9000000 is due to the low resolution set for the vision cone to improve performance. The area will still keep changing due to the low resolution and vertices changing from ray casts but it will be around the same value.

To get that, first, make a function to calculate the area. It will have two inputs: one of type ProcMeshComponent object and the second an integer, while the output will be a float value. Then just copy over the following nodes to it:

Now in the Event Tick of the component add the following nodes:

I’m assuming that since you’re using a full 360 degree vision cone. If that’s the case, make sure to set the “DisplayPeripheralLoS?” parameter in the LoSVisualizer component to False. Also make sure to set the Vision Radius to a high enough value while testing in the 100x100 grid so that when you move in one direction, it still covers the whole area. And you should get the correct area now. If not, just let me know and we’ll look into it.

Ok, I’ve tested that and it’s about 99% accurate now. Thanks a million for that!

Did you have a chance to look at the overlapping function? I experimented with all the overlapping nodes but I believe the procedural mesh needs to have its own collision.
You have any ideas for this?
Many thanks

Glad to hear that it’s working. As for the overlapping function, you are trying to get all static mesh actors that are blocking the line of sight right?

Not quite, for visibility reasons I have the directlosmesh going through say furniture. I don’t want the furniture to block the mesh because it will affect the area calcs, so I want to detect the static meshes that sit on the directlosmesh at anytime or the static meshes that the directlosmesh passes through. Similar to like an aircraft radar system, that way I can target anything seen within that area and apply on hit effects like lighting up. Hope that makes sense.

Hi Stormrage,

Did you have a chance to take a look at the above?

Thanks

My bad. I got caught up with work last week. I’ll test it out tomorrow and share the solution if I get it working.

Alright, so there is a single function PerformLoSTrace that’s always called for line trace calculations to update the LoS every frame. So what we can do is just take the hit actor from the result and then store it in an array.

Now in the Event Tick, we can clear this array at the start of every frame and then use this array as required after LoS calculations are done. For example, I tested it by changing the material of the hit actors in this example:

But this doesn’t give us an idea of the actors that are going outside the bounds of the visualization. So I’d also suggest keeping a separate array of all the hit actors from the previous frame so that you can compare it with the hit actors from the current frame and make changes to the ones that are not in the new list.

Hey, no worries, gotta get the bread first :wink:

I tested it out and it works on any actor it hits, however the output I’m after is an overlap interaction. In other words, any actor that overlaps the DirectLosMesh (not blocks) changes material. I have tried to convert your suggestion to incorporate tags to target specific actors to change material, but unfortunately it seems to break the function.

I’m still testing out methods but if you have any suggestion on this? that would be great.

Thanks bud