High numbers of draw calls - is Unity the right tool?

Hi,
I'm trying to create a small modern neighborhood with about 50 houses. As player need to be able to closely approach the house and enter them, the houses need to have enough details to remain realistic enough.
To reduce the cpu/gpu load I've tried combining meshes to reduce the number of object and am using occlusion culling.

Testing a simple environment with 50 houses, only basic inner walls and doors (no furniture order decorations) with an Oculus Rift (consumer version) attached, I get up to 29.000 draw calls!

By combining meshes I've reduced the number of singular object by over 50%. The frustum and occlusion culling both work fine.

29.000 DC can't be what I should be looking for, can it?
So am I missing something to reduce the load or is the current hard/software not really up to a project like this?

By the way, the play using the Rift is pretty okay. Movement has a very slight jitter, looking around looks smooth enough.

Thanks for any suggestions!

Running unity pro 5.4.0
Windows 10 pro
Intel i7 3.4ghz cpu
32GB
Geforce gtx 989 Ti gpu

Marco

 

.

 

How many materials and textures are you using? Have you tried combining textures in an atlas?

 

Any screenshots?

 

I've used the Mesh & Material Baker to combine several meshes into one and create material atlases.
In total I have about 25 single materials (each having 2-4 textures) and 13 material atlases (pretty simple ones).
I tested my original house as it was (no objects combined) and with combines meshes. The Draw Calls dropped from a max of around 2300 to about 1000.
I'm hesitant to combine more objects, partly because I want to find an efficient balance between reducing the number of objects and having a functional frustum and occlusion culling.

The "final" default house now has 664 single objects (of which a couple of dozen are actually combined meshes).

The thing is that I've split walls and floor and such into separate objects for each room so I can assign different materials to the inner sides of the walls later on as decoration. Normally you would create a single wall (or perhaps front, side and back walls), but then decorating the interior would become more of an hassle.

 

This is not right approach. You should use multiple materials on single mesh instead (use of submeshes).
If you don't need to move two meshes relatively to each other, they generally should be one mesh.

 

Sure. Here are some. Please note that this is just a testing scene where I wanted to see what 50 times (instances of prefab) my default house would do to the performance in Unity. Later on I will also add roads, trees and other stuff to make it more realistic.
Oh, at the moment I guess over 95% of the objects is marked as Static.

 

Hi,
I agree. But each house will have to have a unique inside. So my idea was to build one master house, but that each piece of floor, ceiling and wall for each room has to be a separate item so I can easily change the interior faces to another material. Also all doors (inside and outside) and windows should be movable so cannot be combined either.
I was hoping to create 1 default house, then place it throughout the scene, then add decoration (and furniture) to each house by changing the faces of walls, floor and ceiling to match those new materials (wall paper, carpet, painted, etc).

Do I understand correctly that it would be best if I would completely design each house (apart from the moving parts) as one singular object and map a single material atlas to achieve what I want and keep the number of object to an absolute minimum?

 

Yes, you should have main block of house as one mesh ( + of course movable windows/doors etc. ), and define multiple materials, each for single entity you want to change - walls, floors etc, with that approach you should be able to have no more than few tens of batches per house, and still be able to change independently walls/floors materials for each house. Just keep in mind that lot of materials is also heavy on cpu( I think having 50 different materials is much slower than 50 batches, but it all depends on many variables ).

 

Okay, so just to make sure. To accomplish this you would need to make meshes with sub-meshes that you can change materials on?

Also (for my understanding): what if I have say 20 different insides of walls. Each wall object has the same outer material (say bricks) but each interior set of faces should have a different material. Does this mean I would have 1 sub mesh for the exterior (only brick material) and 20 sub meshes for the interior sections of the walls?

 

Adding two images showing the Stats and the Profiler for two 'random' views of the scene with the 50 houses.
Plenty of batch saving, but the fps is way too low considering what still needs to be added to the environment.

 

If you want you can send me this project so I can have a look at it.

 

Sure! thanks!!
It's almost 1GB in zipped format. How can I get it over to you?

 

Dropbox? Wetransfer.com? and send me the link to download to roy [at] tapgames.nl or by PM.

 

Is this going to be a first person game where the player goes inside and outside of those buildings? If so, then I would also recommend you introduce a portal system. The render pipeline is probably getting unnecessarily hit by all that interior geometry when outside. And when inside, you can cull a lot of the geometry outside.

EDIT:
You mentioned occlusion culling. To what extent is this working? Can you enable a wireframe mode to show off what it's actually culling?

 

Hi!
Yes it will be a first person application. Users will be able to walk around in the neighborhood. Look through windows and enter houses. It should look like a real average neighborhood.
I thought about a portal system. But users have to be able to look into the houses (all of them uniquely decorated) so there's no possibility of not having many of the ground floor objects active. This would sort of nullify the savings of the portal idea, unless you have an idea that can work of course. Of so please tell me!!

Yes the culling works fine. Both camera frustum and object occlusion culling. When I enable the Visible option in the editor with the occlusion inspector open, I see objects disappear that are either outside of the camera's field of view or hidden behind say a wall.

 

Are there any examples of games that allow users to look through the windows? Typically, those AAA games do one or a combination of the following:
1. Portal system for interiors.
2. Set dressing to mask the interior.
3. Limit the amount of interactable/enterable buildings, and set dressing for every other building.
4. Create low-resolution proxy/impostor/LOD models for interiors and even exteriors.

Typically, this is a result of profiling the game and finding out that they simply can't support all the features that the game designers originally intended, so sacrifices have to be made.

Do you think you're biting off more than you can chew? Or do you have a feeling that this can be possible?

 

The problem is that it's not really a game. It's more of a serious game. It meant for scientific research so there are a large number of criteria that need to be met.
I've already created a simpler version with 5 houses that you can enter and a dummy neighborhood. That already wasn't smooth, but since then I've learned a lot and thought I could manage a new version. Better made.

So it must be relatively realistic. Game-like solution can break the immersion and that would negatively influence the reliability of the users' reactions. So each house should be comparable but unique Ik decoration and furniture. And users must be able to approach each house, front and back, and look inside. A fake inside might work but the perspective (when moving) should still be realistic.
And users must be able to enter any of the houses (after which you could do a portal of and fake the houses outside).
So option 1 could partially work, but only when the user enters a house. Not before.
I can't see a realistic way to use option 2.
Option 3 would not be acceptable from the scientific criteria for this project. Unfortunately.
Option 4 is indeed an option I've been thinking about too. It would mean a bit of extra work and I'm worried about the switching between the levels. Usually these transitions are visible to the user, but in a scientific setting this could pose a problem because researchers want to avoid anything that might remind the user that it's a simulation and not real.

So yes, perhaps you're right. Perhaps I have taken on something that is too much of a stretch.

Thanks for your suggestions! It really helps determining what a possible next step could be.

Marco

 

Yes LOD is definitely something I'll will work on. Not sure how much it's going to help, but I will look into this. The problem is that transitions between LOD levels should not really be visible and I'm guessing that most of the time the house that are visible will have to be the highest level, while those that can have a lower LOD will probably not be visible (and thus will be culled).

I'm not sure what you mean by making the doors occlusion portals. Can you please elaborate?

 

My first thought when I read your original post was that your mesh combining and OC might be fighting. I'd assume you'd set it up so that you mainly only see the house exteriors, or if inside maybe two rooms at a time, all because of OC. But if you have combined the meshes of things that are in multiple rooms or multiple homes, this would fight your OC, as they would render even when not visible.

 

This is a very good point. As such, it would be worth seeing this in action with a wireframe mode to be confident that this is indeed not the case.

 

You're right of course. I did think of that, as in not trying to create the house in one mesh because the whole OC would be pointless then (except when not having the house in view or completely behind another house). So I made several combined meshes of the both exterior and interior objects. Trying to to find a balance between reducing the number of objects and having the maximum effect of OC.
At the end, at least in the current phase with just bare houses, this still means way too many objects. So perhaps more aggressive combine and loosing some advantages of the OC is preferable.

 

I would think the ideal course is to let the OC do what it wants to do. You should only have draw calls for the objects in view, which would in the worst case be maybe two rooms and an outside view (if you can see through a window).

Outside, you can let OC work its magic. The interiors should be invisible unless seen through a window or open door. Draw calls should be low. If you have a lot of unique, detailed exteriors for the houses, with porch furniture and so on, breaking the houses up into front, back, and side views would allow the OC to work better, and the GPU would only be drawing what the player can see (not the backs of houses). As for the interiors, if there are a lot of objects in a room, you might do mesh combining there (combining just for the room).

 

Only just skimmed this (as you linked here from my other post) so what I'm saying might have already been covered, but what I would do is place a script on each house that:

• Disables the renderers on the house's content on Start().
• Enables the renderers if the player opens the door(s).
• Enables the renderers if the player approaches a window.

EDIT: obviously in addition to standard occlusion culling for showing/hiding the houses themselves as the player walks around the neighbourhood.

 

Yeah, I agree. That's basically what I did and still ended up with the Draw Calls maxing around 29.000 when walking around outside. The OC looks to be working just fine, so that does not decrees the number of DC anywhere near enough.
Personally I think mesh combining (to the extend of making a house 1 object, furniture (per floor?) one object, etc) is the only way to go if I want to get those DCs below 5.000. Then the OC would still work, but only on complete houses. I think it would be preferable to have a few extra DCs because a single object house is just in view, than having dozens of DCs because that same house consists of dozens of objects that are just in view.

Or am I missing something important here??

 

Yeah, that's what I have now. Although my houses are still empty apart from walls and doors. OC is working properly and still the Draw Calls max out at over 29.000!

 

How many pieces/gameobjects each building has?

if there's lots of small bolts and nuts included in the CAD(?) models, could clean those up first outside unity..
Also if you disable shadows, is there a big difference in drawcalls?

 

Somewhere between 500 and 600 objects in a house without any mesh combining.
I haven't looked at turning the real time shadows off, although I do work with lightmaps I also want the realtime shadows because of moving objects (like doors, cars, etc). But still I'll take a look at the impact of the shadows.
Thanks!

 

It seems very odd to have so many draw calls for so few objects. It's just drawing and drawing and drawing!

Go through and deactivate things related to lighting, screen effects, and also deactivate stuff in your scene so you can isolate how many draw calls are going to an object, a room, an effect, etc. to start to nail this down by process of elimination.

Also, is there just the one scene camera? If you're playing with multiple cameras, maybe there's something going on with that.

EDIT: I see you're using VR (?). I'm not sure how that works, but I'd be looking there first to see if your multiplying draw calls are coming from that. If you can replace that camera set up with a normal single scene camera, and your DCs come back down to earth, then you know something is going on with the VR.

 

The issues turns up when I create 50 instances of the house, that's the amount of houses I will need, apart from roads, trees and other street stuff and all the decoration and furniture inside the houses (each more or less unique).
I use lightmaps (baked and GI tried both), there is 1 directional light with realtime shadows (which I will need), 1 camera, no effects, no other objects than the houses.

 

Okay just an update.
So I have my base house. Couple of hundred objects, about 25 materials. When the house is duplicated 50 times the Draw Calls run up into the 29.000.
Today I exported (using ProBuilder) my house to an OBJ file. That is every door and window that needs to move separately and the rest into 1 OBJ. The exporter creates one mesh per material. With the house and the doors/windows I ended up with 82 meshes and 28 materials (all single mats, no atlases).
When I duplicate this house 50 times and run it, the maximum number of Draw Calls I get is 6.200. That's 20% of what I got before without loosing quality. OC was on, by the way.
Because this environment will only run on high-end gaming PCs, I would be willing to accept this number (although higher than the 5.000 people talk about). I even tested this test scene with the consumer Oculus Rift and I got no lag or jitter or anything.

The next step would be to combine those material with the same properties (but different textures) into atlases and the meshes into one object to reduce the number of object further.

I am still worried about the end goal. I still not only need 50 houses, but roads, lamp posts, trees, cars, etc for the outside. AND I still need to fill up the houses with furniture, decoration and all sorts of junk you'll find in an average home. Even if I portal to a scene in which the filled-up house is so I can reduce the number of object inside in the exterior scene, I still need a lot of objects inside the ground floor of the house. No dummies or such possible as users must be able to walk up to the front (or back) window and look inside.
All these things will push the number of Draw Calls way up again. At least, that's what I'm afraid of!

 

If you're using OC and mesh combining within that (combining all the meshes in an expected view, like a room or house interior, and separately combining house exteriors and environment), you should be rendering only what's in the camera view at any given time. In that case, your polys and draw calls should be low.

Even in an eagle's eye view outside, you should only see (and render) house exteriors and other environmental objects (sidewalks, streets, street lights, stop signs, etc.) that should mesh combine and produce few draw calls.

It sounds like you're on the right path. Good luck!