If I use a cube it works fine, but a plane doesn’t block anything and doesn’t allow navigation. What is going on here? Are plane blocking volumes just not functional at all?
Left side is cube. Right side is plane. Both are BlockAll and both affect navigation.
Hey @Krileon!
Interesting… It should! I do have a question you may think is silly but… Is it upside-down? It will only have collision on one side. Like how if you go outside of a room in a game and you can see in but you couldn’t see out before- they’re one sided. I’d throw a material/texture on the plane so you can see what the “front” is and try again! But really, let us know if that works or doesn’t just in case! 
It’s not upside down. That was the first thing I tried, lol. The plane blocking volumes just flat out have no collision. They’re acting as if they’re hollow. Happens to cube blocking volumes as well if you set 1 side to 0. Below is with a plane static mesh added to it.
Added collision to the plane static mesh and you can see the nav mesh going onto it. Below is it flipped (no static mesh on it this time). Still no collision.
Plane blocking volumes just flat out don’t work, lol. Below is a cube blocking volume that’s made flat by nearly zeroing out the Z. Also don’t work.
Turning on shade volumes for planes also does not work. See below side by side with cube shaded volume on.
Forgot to mention I’m on 5.6.1. If anyone could check 5.7.2 I’d appreciate it as maybe it’s something already fixed.
Okay, I see what you’re getting at. I didn’t realize it was a blocking volume plane. It has something to do with the fact that the plane blocking volume is technically not a volume because it’s two-dimensional (meaning it has area instead of volume). That likely affects the ability to use navmesh on the surface- I would suggest just doing what you did above- just use a static mesh! You can always give it a cool material, especially if it’s trying to be like a space-y situation for stars and stuff. And of course you can just make it transparent with a transparent material.
That doesn’t work for me. I’m using geometry tools to generate a blocking volume for the entire floor. So instead of 50 meshes with collision it’s just 1 blocking volume. The floor is also generated from an editor utility widget. This clearly has to be a bug otherwise why make plane blocking volumes even a thing, lol.
“Invisible Walls”, triggers, etc.
It could also be something to do with using geometry- geometries don’t have all of the abilities that a static mesh does for some reason, I assume to make them able to be highly modifiable. Once you’ve laid them all out you can combine them using rclick → convert to static mesh, then once you do that you can ctrl + Z to keep the static mesh you made but ALSO keep the geometries, so you can build it out in another level just for modifications. It would really increase performance to convert it all to static meshes, or maybe even one static mesh if it’s low poly and important.
@Mind-Brain , (hello), question:
Does “Generate_Overlap_Events” need to be enabled for navmeshes? One of the biggest things that got me in the past is that default shapes are NOT enabled by default.
My projectiles kept flying straight to hell.
Plane blocking volumes can’t be because their collision flat out doesn’t work, lol.
I don’t want a static mesh, because this has no mesh. I want a plane blocking volume and nothing more. Basically a plane collider. I don’t want the overhead of a AActor either. I cannot possibly be the first person that wants a efficient plane collider, lol.
No, generating overlap events is not required for navmesh. My cube blocking volumes as shown in my above screenshots are impacting navmesh without overlaps.
No it should not. By default the collision hull size of a plane panel is inexistent. If you manually change it to a size that the engine responds to like 10uu in thickness, then it would block things and be considered…
@Krileon you are just doing things wrong really. Don’t use the engine for something that needs to be done in a DCC - particularly when trying to use the engine is just going to make you go nuts.
Also the overhead form AActor is insignificant unless you do things on tick with it. So you are slightly overthinking things. It’s not bad that you are in this case. And it would indeed be best if you figure it out.
But keep in mind that a plane has no volume - so the issue is a combination of your lack of considering that fact on top of epic allowing a volumeless item to be considered a “blocking volume”.
Use a box. Make it 10uu on the side you need flat. Or use a static mesh with a plane and a UBX that is at least 10uu thick.
Then merge the mesh with merge actors instead of whatever this other thing you are doing is…
And after merge actors you usually export and change the final model and the UVs for optimizing.
Thanks for the insight.
Not sure why I didn’t get a notification.
