Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
Occlusion Culling
I realise a lot of stuff falls under v2, but one other thing I've noticed about v1 is that performance of some levels can be very varied, which is something v2 may wish to address, particular since VR can be performance sensitive even on powerful systems.
My favourite level is the Office, because it has so many different rooms to choose from, but it seems that any camera angle looking downwards results in poor performance, as well as in certain directions horizontally. My suspicion is that this is because at certain angles more of the level is in shot, albeit hidden, impacting performance, as changing the angle towards a less busy area of the level produces a noticeable improvement.
This isn't a problem with the smaller levels where no matter which way you look there just isn't as much to render.
Now I don't know whether Unity has occlusion culling support by default, but it's common in large games to "cull" areas that aren't visible; for example, if you're building an interaction in the janitor's closet of the Office level, it is entirely enclosed with no windows or even other rooms that are visible, so as long as the camera is positioned inside that room, everything else in the scene can be culled.
Many of the other rooms are similar, and even those that do have windows can only see the city in at most two directions.
Anyway, just thought I'd throw it out as a possibility for improving performance on the bigger level(s). I realise part of the problem is my poor system, since it only has integrated graphics, but like I say, interactions run fine at other angles on this level, and VR can be demanding, so optimising this will make a difference for most users, even if they might not notice it.
My favourite level is the Office, because it has so many different rooms to choose from, but it seems that any camera angle looking downwards results in poor performance, as well as in certain directions horizontally. My suspicion is that this is because at certain angles more of the level is in shot, albeit hidden, impacting performance, as changing the angle towards a less busy area of the level produces a noticeable improvement.
This isn't a problem with the smaller levels where no matter which way you look there just isn't as much to render.
Now I don't know whether Unity has occlusion culling support by default, but it's common in large games to "cull" areas that aren't visible; for example, if you're building an interaction in the janitor's closet of the Office level, it is entirely enclosed with no windows or even other rooms that are visible, so as long as the camera is positioned inside that room, everything else in the scene can be culled.
Many of the other rooms are similar, and even those that do have windows can only see the city in at most two directions.
Anyway, just thought I'd throw it out as a possibility for improving performance on the bigger level(s). I realise part of the problem is my poor system, since it only has integrated graphics, but like I say, interactions run fine at other angles on this level, and VR can be demanding, so optimising this will make a difference for most users, even if they might not notice it.
Comments
I guess it depends how Unity is designed to trigger the occlusion, I'm afraid I'm not at all familiar with Unity, though I've used a few other engines where occlusion culling is possible. In those you usually have some kind of trigger zones (i.e- rooms) which cause other areas to disappear whenever the camera is inside of them, and you could always make the target areas (or culled areas) bigger or smaller to give you some margin of error.
Was the culling based on the camera's position or its target point? I can see why the latter wouldn't work, but it should be impossible for a camera positioned within a room to see outside of it, at least not without being part way through a wall (this is where you might add the margin for error).
I'm not sure what you mean by this? A camera has a physical position and an orientation just like anything else; based on that physical position you can determine what it cannot possibly see. Obviously the size of the viewpoint introduces a margin of error, where the central position is in a room, but part of the view is up against the wall (so potentially seeing through it), but a reasonable buffer should account for that.
Or do you mean that not all levels contain rooms? I didn't intend to use room as an overly specific term, it's just that in the Office level in particular it has a lot of rooms, many of which are not visible from one another, so when the camera is inside one room, others can be hidden.
Or are you referring to a moving camera? Occlusion culling doesn't have to be performed once only, it can be updated as a camera moves into and out of trigger areas.
Having a 3rd person or free roaming camera definitely shouldn't affect whether you can or cannot do occlusion culling, it just changes what position data you use to trigger it.
It sounds like rooms need to be organised as individual static objects; the contents and characters and props can then be considered moving objects, in which case you get to use an occlusion area to handle them, which can be larger than the size of rooms:
https://docs.unity3d.com/Manual/class-OcclusionArea.html
This way, rooms should remain visible even if you've jammed the camera somewhere in the void between them, as the room is still either visible or not. With occlusion areas handling loose props and characters, and the areas being larger than the rooms, it should prevent them disappearing too soon; means you might not end up culling the maximum possible, but should still get most of them.
While smaller levels may be the right way to go, I'm a little concerned by that direction; performance issues aside, the Office level has a lot of appeal to me especially with v2 adding a timeline, because it has a lot of scope for moving around, e.g- an interaction could start with characters at the stairs/elevator, then by the reception desk, then at their cubicles, in a meeting, and in the boss' office. Unless the timeline is allowed to exist across multiple levels, such a thing won't be possible if they're going to be smaller in future.
I suppose one question that springs to mind is; does the player really need to be able to pass their camera through walls in Play mode?
Obviously I can understand why the extra freedom is good when editing and exploring an empty level, but when you're just playing an interaction it seems like there's no need to be able to move the camera through walls. With that in mind, would it be possible to only enable occlusion culling in Play mode, and prevent the camera from clipping through walls? This seems like it would avoid the issue shown in your animation. If Unity's own culling doesn't support switching on/off at runtime, there's also a script someone created to do runtime culling which should be more flexible, there's another paid one in the asset store that may be more capable, but I have no idea.
The other alternative, since Yiffalicious doesn't have a lot of dynamic movement, would be to use some kind of custom culling, hiding any parts of the level that aren't being used by the current stage of an interaction. To stick with the example above:
- At the entrance, only the entrance area and reception would need to be visible, everything else could be hidden in Play mode.
- After moving to the reception, the areas visible through the doors would need to be made visible too, but others can remain hidden.
- Moving to the cubicles, the hallway and reception would be visible, but entrance can be hidden, along with all self contained rooms, boss' office etc.
- From the meeting room iirc there isn't much visible except through the door, so everything else can be hidden.
- From the boss' office again there isn't much visible from the door.
Basically the culling in this case would be handled in some way by the timeline, probably by tracking which room(s) have active characters at each stage, and culling anything that isn't visible from at least one of those. Combined with a camera that can't clip straight through walls of course; editing would make everything visible again until you're done.One other caveat with the restricted camera is that it would require the timeline to have the ability to change the default camera position as time progresses; i.e- moving the camera from entrance, to reception, to cubicles etc., but I'm hoping this is something the timeline will be able to do anyway, but I couldn't find any mention of it (but I'm playing a lot of catch up on news, so I may have missed it).