Hi, everyone. I know this has been asked before but I’ve never found an answer that satisfied me and I’m hoping something has changed, either with UE4 updates or the advent of some third-party tool. I realise that a player can’t be spawned within a collision box, but I didn’t understand that when I modelled my manor and imported nearly one hundred individual rooms as separate meshes. I’m hoping there’s some better way of doing interior collision than manually applying blocking volumes to every single wall. The rooms are all closed models as well, so I can’t generate collision in any way that I know of without going into Blender and separating all the pieces and then exporting and importing again. I realise that I could do that, but that’s almost as time-consuming as arranging all the blocking volumes.
In my mind, someone somewhere must have developed a tool to do what I find to be a simple thing, which is to generate a separate collision box from each face in the room, rather than generate one collision box that uses each face as one side of it.
If this has not been developed, then I’d like to ask, is it possible to do so in Blueprints or something? Perhaps I can ask our programmer about it if it needs to be done in code. And failing that, is there at the very least some way of arranging blocking volumes that doesn’t require large amounts of guess work and spinning the camera and resizing for several minutes each time I put one down? Maybe something that can quickly snap the collision box’s corners to the corners of a wall of the static mesh?
Thanks a million.
P.S. I’m using version 4.9 of the engine, if you needed to know that.
If you have a complex interior mesh then the automatic generation likely won’t work and you’ll have to do it yourself in Blender. you should be able to create boxes in Blender and snap them to the walls.
Thanks. I’m kind of trying to avoid that if possible. In Blender I could pretty quickly just duplicate the room object and separate all the faces and turn it into collision, then export and reïmport. All these methods are time-consuming and if in the end it’s absolutely necessary to do it one of these ways, I’ll just have to do it. However, to me, these repetitive calculations are the chief reason for a computer’s existence, so I’m hopeful that there’s an alternative that can take advantage of this.
Automatic collision doesn’t really work well with an interior type mesh since all of the complex stuff is on the inside, you’d likely also end up with things not being tight enough on the corners.
It’s mostly just blocked out rooms, and all the other stuff is imported separate, so in most cases I think it would work. I’ve been experimenting with ticking ‘Use complex collision as simple’. Tried that, but tried messing with a few other things as well. Now, it wouldn’t surprise me to learn that the ‘Double-sided geometry’ box were needed, as well as for the mesh to be simple, like a rectangle.
Either way, I did get it working for one room that is a simple rectangle. I remember having problems with another room earlier, and that room was more like a rectangle with an appended trapezoid (so, technically a hexagon), but I’m not sure what options I had selected at that time besides ‘Use complex collision as simple’. It could have been the options or the shape of the room that caused the trouble. I know for that one I did the collision in-engine manually.
In the end, if I can reproduce this method for all the rectangular rooms, I’ll be pretty satisfied with finding another way for the few irregularly shaped ones.
Separately, it’s not a good idea to have each room be its own complete mesh. It’s better to have each wall/ceiling/floor be a separate mesh.
This is because if a room is a full mesh, you will render the wall behind you, even when you’re inside the room looking forward.
And, once your rooms are in multi-mesh format (each mesh is not hollow) then the automatic collision will work fine.
Actually, we’re doing classic Resident Evil style fixed cameras, so it’s a bit different for us. Besides which, only the blockout is one mesh. Props are all separate objects that won’t be rendered when not on screen. With this method, we are so far getting 120 FPS on my semi-outdated GPU (GTX 750 Ti) unless we use loads of completely dynamic lights instead of static. It’s not worth it in my opinion to go in and separate them unless it’s needed for collision. It’s a matter of two triangles at a given time, and the walls generally all share one texture, so we wouldn’t be saving memory there. I also remember having a problem with lighting when I had some walls separate, which is why I started doing it this way. But that was back in version 4.5.
Usually, walls are pretty simple so having it still loaded in memory isn’t going to impact performance that much. Plus, for lighting it helps to have things combined
Oh, absolutely – it’s not on-card RAM I’m worried about. It’s the additional unnecessary transform cost, and perhaps guard band culling/clipping for the GPUs that still don’t have infinitely wide, infinitely fast guard bands.
Then again, multiple components may generate more draw calls, if they can’t be combined. I’d actually love to get some more insight into how that all works out!
In theory, you have a point, but we’re talking about one room at a time in my case, and at most a couple of triangles. On a larger scale, what you’re saying is almost certainly correct, but I wouldn’t see any benefits on this scale, though it would be a fair bit of unnecessary work, not to mention potential lighting problems. I believe multiple meshes, if exported as a single object, should use only one draw call, but the vert count does go up. Again, the scale would have to be much higher for any of this to matter.
When I didn’t know what I was doing, I had a level made mostly of BSP, with hundreds of textures, and a Gothic window that was composed of a million static meshes, with the whole thing using particle effects and dynamic lights all over the place, with horribly optimised camera actors across the board; I got 45 FPS on average. We’re at the point where a lot of this stuff doesn’t matter nearly as much as it once did. I try to keep my texture count and poly count as low as I can without sacrificing quality, but in my heart of hearts I know I’m actually being a bit ridiculous in most cases. It’s basically lights you need to worry about now.
Update: So far, ticking ‘Use complex collision as simple’ has been yielding perfect collision for these interiors. I can drop in a Player Start and navigate the room with no trouble.
However, AI can’t. The navmesh doesn’t appear to recognise the collision generated in this way. This would beg the questions Why, Is there some way to save this collision as proper collision, and Is there a more customisable way of dictating a navmesh. But then something funny happened, which is that I thought I’d simply use a blocking volume for the floor. Well, the moment I put the volume, at its rather tiny default size, into the room, the navmesh volume produced perfect navigation.
Sounds great, yeah? Well, that was in a rectangular room. Though collision has been working perfectly for rooms of all sorts of shapes, putting in a blocking volume doesn’t seem to cause the navmesh volume to produce the navigation wuite as you’d like when the shape of the room is more complex. Or at least, I chose such a room as a test of the limits of this method, and it failed. With no blocking volume, none of the rooms will produce any navigation data whatever, but in this second room (with the more complex shape), it produced very strangely shaped and incomplete navigation once I’d put in the blocking volume.
Any ideas?
EDIT: The first room was not rectangular, now that I think of it. It was an irregular hexagon shape with a doorway jutting out from it as well as a rectangular room joining it, including the doorway between the two. The second room was a rectangular prism as one mesh, with a second mesh forming just one wall that has a bit of a mad shape. Perhaps the separate meshes being used as one object is indeed what’s causing the trouble. Maybe I’ll grab some screenshots later if anyone would like. No time just now.
In order to solve the navmesh problem, it seems that it just involved switching the mesh from static to movable and back to static. In fact, in subsequent rooms, this stopped me needing to use the blocking volume. I really don’t get what governs this, and it may become unstable at some point, but it’s working at least for now.
EDIT: Rather than bumping this, I’ll just leave an edit for anyone that finds this via a search one day. I was still having problems in a couple of rooms but once I found RecastNavMesh-Default in the World Outliner and looked through its options on the Details panel, I realised you can specify the height, and that seemed to be what I hope is the final piece of this puzzle. If the rest doesn’t work, you should be able to get it going this way.