Optimisation specifics

Hi Unitiers

I'm hoping to get some help with specifics of my 'game', which is actually more of a medical teaching piece. This will be my first proper build, been using Unity for 4months now.

- Target: webplayer
- currently it consists of 4 scenes that are very similar. Namely:
- vertex counts of up to 200k (a lot I know)
- draw calls currently at about 30 (although I haven't yet applied materials).
- however despite the high vertext count it's still running at almost 100FPS.

Things I've already done for optimisation:

• For my dense meshes (which are made from medical scans and hence why so dense, they'd be complicated+ to retopologise) I've removed the mesh colliders and created a second much lower poly mesh where the objects don't have a mesh renderer component but only a mesh collider enabled.
• As these objects won't be moving at all I've set them to be static. This seems to save approximately 4 draw calls
• When I do add materials I'm going to try and use Unity's in-built ones and keep them simple eg diffuse, and only use 3 or 4 in the entire game
• I currently only have 1 directional light in the game attached to the camera (looks awful)
  

My questions:
1. Is the high FPS I'm getting because it's running off of a fast i7 quad-core CPU and dedicated 6GB graphics GPU? Ie if I was to build for webplayer and view on a laptop with an i5 and in-built graphics chip would the FPS be much lower?

2. As I don't have any moving objects in the scene really, I don't need to use light probes. However I could achieve a nicer lighting effect and reduce draw calls via lightmapping right? I've imported the high density meshes from Blender. Currently if I go to the import model settings and click 'Generate Lightmap UVs' Windows seems to just hang (I assumed because they're so big). Is there a way I can ask Unity to generate them per mesh?

3. Retopologising the dense meshes isn't really an option as it would be too complex, especially with some other models I'm using. Would 'baking' maps somehow in Blender prior to importing help?

4. the profiler says that for the CPU the main bottleneck is (I think ) waiting for the GPU. The GPU says the main bottleneck is RenderTexture.SetActive. I take it this is the rendering of the geometry?






Really interested to hear your thoughts and comments
A

 

Hey arumiat,

1. Yes, your machine is blitzing you game, but believe it or not with the stats you've mentioned it is still very lightweight app. I'd imagine the i5 wouldn't be a slouch either, although that does depend a little on the onboard chipset. Do you have any idea about the 'average' spec of your target users?

2. Lightmapping would produce nice looking results (especially given your using pro and have access to skylight / bounced lighting), but you could also look at using deferred rendering for more active lights with very little performance impact. In the end it comes down to the look you're trying to achieve. Anything specific in mind? Any examples of what you have or what you'd like to achieve?

Re-UV's: If you leave it for a while, Unity may recover and generate the UV's, it could just be a heavy moment cause of the size of the models. Failing that, you should be able to generate lightmap UV's in Blender and import them with the models (Don't know much about doing this personally).

3. Wouldn't worry too much about retopo or anything like that unless you were sure there were performance issues, and in that case, draw calls are usually an issue before vertices. 200k and 30 calls in a scene on desktop is nothing to be overly concerned about.

4. I would usually associate RenderTexture with post-process image effects, although I doubt you're using those. There's a thread here on Unity answers where people are discussing possible causes for it, with some agreement that it's actually caused by the profiler itself running (check the 2nd answer by benni05). Unless your getting performance issues on your target system, it's probably safe to not give this one too much thought.

One other thing to take note of is how batching works in Unity (static or dynamic) - it is based on materials and only meshes that share the same material can be batched. Keep this in mind when you start to work on your materials / textures.

I also notice you say that the objects won't be moving, but you've generated simplified collision meshes for them (which is the right thing to in most cases). What's actually going to be colliding with the meshes? Or are the collisions there for mouse manipulation?

 

If you run the profiler in deep mode then you should get a better idea of anything that is causing bottlenecks, e.g. Scripts or renderers on the CPU or GPU.

If you are building to web player then you can ask friends or colleagues with different rigs to try your app to see how it runs on different machines. Ideally you would have a minimum low spec machine to target, in effect using the unity web player you are limited to DX9 level hardware and above.

 

Thanks Arowx. I suppose this is good in the sense that if the machine they're on is capable of using the Unity Webplayer, it's going to be have to be running DirectX9 or above, and thus likely also be reasonably modern and have reasonable specs?!

Thanks Nomadking
1. Wow. I really wasn't expecting it to be considered lightweight. I was watching some tutorials on digital tutors about optimisation and they were getting hot under the collar about getting vertices down on a mesh from 132 to 12 or something & I thought egad, I'm in trouble!
- my primary users would be students with standard laptops, and people with standard home desktops (ie not people with dedicated gaming machines, just standard builds you'd buy from PCWorld..
- I'm hoping though that it could also be useful for teaching in the 2nd/ 3rd world where machines won't necessarily be so specc'd.


2. I guess just something like this with nice even lighting would be cool

At the moment my scene looks pretty dire, as you can see in the screenshots with the horrible grey background and harsh lighting.
I'll try leaving the UV generation in Unity running a while longer..

3. Phew!

4. I read that thread in my searches but it didn't 'click' with me. Cool so essentially nothing to worry about currently.

Noted what you say re batching. They discussed this on digital tutors as well.

In answer to your last question regarding the collision meshes: I have another script that is showing/ hiding annotations depending on if their parent game object is visible to the camera (not yet added to the game) These collision meshes are needed for that. However, I could probably exchange these for some primitives (a plane for instance down the centre of the spine) if that would greatly help the performance down the line.

NEW question:
Out of curiosity, I take it though that these scenes would not run well on tablet devices in their current state

 

Remember that tablets and mobiles are improving fast, best way to find out is to test it on one.

With a combination of lower poly modelling and texturing you could probably get away with way less vertices.

 

What @Arowx says is spot on, do a test and find out if you really want to see.

I don't have much experience with tablet/mobile, but I'm fairly certain you'd at least need to do some retopo on your models to get good mobile performance. Also keep in mind that the power of mobile devices does vary quite a lot from top end to bottom (Less so on iOS, more so on Android).

The other points:

1. Typically the lower the vertices you can get away with the better, so it is good to reduce them when you can, but as with anything you just need to weigh up the time it takes to do the work vs the gains. For mobile, sure, worry about every vert. For PC, check on a few machines around your target spec, then decide - your scenes are going to increase in complexity much, so it'll be a fairly accurate benchmark.

2. Thats a fairly simple style in that video, most of the work is done by the lighting. You could almost get away without any textures if you don't need any detailing on the models (The white lines on the liver right at the start appear to be in texture, so details like this). If you want any parts of the models to be turned on or off, lightmapping wouldn't be the best solution, and lightmapping would also increase your download size (since you're creating unique textures for every surface). Personally I'd look at a dynamic lighting solution with just material colour (or vertex colouring if you want better batching), although if you are considering mobile as a possible target platform, be sure your particular setup is supported on mobile.

Re-collisions: Best practice is to always go for the simplest collisions possible without compromising what your trying to do. Reduced meshes are fine, but if you can use physics primitives instead its the faster option. I wouldn't worry about this too much right now, you aren't asking a lot from the physics right now so I doubt you'd see much performance change. Just something to keep in mind as best practice (and potentially more important if you go for mobile).

 

Thanks again both. For my current projects I will only need to be able to play off desktops and laptops so I'm happy to hear that currently I should be okay. I'm planning a few projects for mobile though so it's good to know those points for my approach and that's why I was asking.

In terms of lighting:
I do plan on hiding and showing meshes PLUS I couldn't get the 'Generate Lightmap UVs' to work ('Windows circle of death') so I have been looking at deferred lighting as you suggest. This was a good read on forward vs deferred shading.

It seems like I get an immediate improvement in draw calls, and also rendered geometry when I switch to deferred lighting from forward rendering.




Interestingly though the FPS stays the same.

--------------------------------------------------------------------------

As a 3D modeller I'm just trying a 3 point lighting setup, it needs tweaking but already looks a bit nicer than the single directional light.

The points with the colliders and vertices noted, thanks.

 

In the end, your final look will ultimately be decided by the shaders you use for your materials. Visually, there's only so far the default Unity ones will take you, but lucky it's a very big non-Unity specific topic, so there's a lot of information out there about it.

Good luck!

 

Just as an update for any modellers who may read this, I've been a bit of a mug and overlooked a very simple tool, available to most 3D modellers that greatly reduces vertice count, the decimate modifier. I dropped my scenes vertex count from 195k verts to a total of 50k (and could probably go further), with no change to the look of the mesh. Boom!

 

To take this a bit further, I've built my first test build of my game =)


On a high-end GPU I'm getting 60fps (measured through a C# script within my game). I sent it to my sister though who has a pretty decent i7 CPU with a dedicated Nvidia 2GB GT740M(admittedly low-end) and it was running down at 15fps and crashed chrome a couple of times =(.

So I'm now at the stage whereby I need to start tinkering. Here's what my profiler has to say on the matter


So it seems like the GPU is the bottleneck, rather than the CPU. I'm using the Marmoset skyshop addon to provide image-based lighting. I have deferred lighting selected.
My plan is to
1. switch all materials from the Marmost IBL to the mobile Marmoset IBL versions (I'm using very basic shaders)
2. remove one of the directional lights from my scene, - I currently have 2 directional lights, on top of the Skyshop HDR image-based lighting
3. try shrinking all my textures down further, - my skybox has six sides at 512px each, and the HDR panoramic texture is 4096, - yikes!
4. read up on lightmapping (since decimating my meshes Unity will generate lightmap UVs) and use this within the Skyshop addon. This is almost definitely worth it as all my meshes are completely static?

Any other advice as to what I should try?
Or how people like to profile? For instance I read and have tried playing my game and disabling game objects one-by-one but it doesn't seem to do anything to the frame rate?

 

I'm also wondering.. all the meshes in my game are individual currently. If I was to combine the individual meshes into these 4 groups, each signifying a single mesh (they are the groups of meshes that can be toggled on/off), it should help performance a degree too, right?

 

Using Skyshops bake function here are 2 profilers from the same scene. First screenshot WITHOUT bake, second WITH bake.


There's a modest improvement, but it seems like it's the RenderTexture.SetActive that is the real resource hog. Despite some googling and searches on here I'm still not clear what this is referring to, any pointers greatly welcomed.

 

Can I ask why you are using the marmoset lighting/shaders, as I thought they were advanced shaders that provide reflections, but the screenshots you are showing only need a default or specular shader?

I would guess that marmoset passes a texture to the gpu for reflections and that shows up as the RenderTexture spike.

 

I actually invested in it for projects later down the road where the better looking shaders will be useful and wanted to get familiar with the asset. I was also fed up with the contrasty lighting provided by 2 or 3 directional lights.

I know now I can use actually global illumination to achieve a similar softer lighting effect like the IBL provides. So going back to global illumination instead and using Unitys default shaders is something I could try?

What were your thoughts on combining my meshes into the groups shown?

 

Just save the scene as a new scene, and then set the scene up with the bare 'bones' minimum shaders you need and test it (e.g. mobile diffuse). Then you will be able to find out if marmoset is causing the performance problem you detected. Also contact marmoset and see if this is a known problem or if there is a workaround/solution.

The key thing is even if your app looks amazing if it's slow and unresponsive you might as well give the user a set of 2D images. Think about what the user is going to do with your app and focus on making that a great experience then work on the graphical tweaks, also if you have a 5.x license and you're development window allows for delivery using 5 you might want to consider migrating to 5.x's new shader system.

You can also look into the graphical sleight of hand that is Imposters, where you render amazing quality images of an object from 360 degrees then show the player/user the appropriate image depending on camera view. It tends to be used for distant objects where there are lots of duplicates, soldiers, trees ect but it is also used on the web for those 360 degree views of cars and phones.

On combining the meshes, remember that Unity will automatically subdivide any mesh with over it's 65k vertex limit. But this does not appear to be related to the performance glitch you mentioned previously.

It sounds like you're hitting the common platform/performance problem area common to Unity, the gap in performance and range of performance across platforms e.g. mobile and pc.

The logical approach would be to build and test on the lowest performance platform you want to target and then add optional features for higher end platforms.