koobas.hobune.stream
performance optimization
Hi,
I'm currently stuck, cause my pinball game does not perform well. Frames seem to stutter, although the profiler shows about 90 FPS. The problem gets worse if I start the game as standalone (fullscreen, dual monitor setup with horizontal span => 2560 x 1024).
The scene is quite simple. According to stats window, there are 200k triangles, 131k vertices and 340 Draw Calls.
Because of high velocities, I won't like to decrease fixedDelta time (which is 0.02). I use physics for controlling flippers, the "start catapult" and for pinball-collisions.
When I disabled most of the mesh renderers, the performance was slightly better, but still stuttering.
What I did so far to enhance performance:
- use #pragma strict to force static typing (no dynamic type inference)
- Call Find and GetComponent functions only in Awake(), never per frame.
- Removed Rect object creation from OnGUI function
I'm afraid I started to enhance at the low level before really knowing where the performance drop comes from... Any ideas how to track the issue?
I'd like to use the profiler, but it drops performance even more. According to profiler, most of the time is spent in Camera.Render (in editor mode on one monitor) although the scene is quite simple, and in Physics.Simulate. I don't use any fancy Quality Settings (they are set to "Good.").
Can we trust the profiler or is it more reasonable to test timing from within my scripts only? One thing I noticed is, that whenever I hit a certain key in standalone fullscreen mode (for launching the pinball out of the "start catapult"), performance drop is worst, although barely noticeable in editor mode - according to profiler, Scripts aren't a real issue...
The machine I run the game on: Win XP, Core2Duo 2.0GHz, 2 GB RAM, GeForce 8600 GT 512MB.
BTW: I've read a lot about using shared materials in the performance optimization guide... How to use them? Is it that simple that I drag the given material from my Project View onto several meshes in the Hierarchy View? Or is the material copied in this case? Do I have to write script code for using shared materials?
For others, who are dealing with performance issues like me: There's a great talk about this at:
http://unity3d.com/support/resources/unite-presentations/performance-optimization
and a good guide like at:
http://unity3d.com/support/documentation/ScriptReference/index.Performance_Optimization.html
Ah, one thing I forgot to ask: I access other scripts from within a script quite often. Is this a big deal? Don't forget: I cache script compoments in Awake().
Sometimes, the profiler has some peaks, caused by GUI.Repaint (GUIUtility.BeginGUI() and GC.Collect respectively). Does the profiler take the editor and profiler GUI into account or only of the game itself?
I downloaded the .zip, and got DllNotFoundException on SerialPinball.dll. It's definitely in the right directory, readable, etc, so I'm not sure what's wrong with it. Is there some other requirement, like something attached to the CO$$anonymous$$ port?
Problem solved. The issue was due to the plugin, where I'm accessing a serial port. I didn't notice the mistake there, because Unity seems not to have the plugin updated when I tried to reload it.
You should expect to be render-bound, not physics bound (rendering budget can be adjusted in quality settings, physics can't).
Try to recursively GetComponentsInChildren() and hide all the meshes and see if just simulating physics is hitting you. If so, you can try to reduce the number of active rigidbodies and/or avoid embedding colliders in complex transform heirarchies (the physical space is flat w/o parent-child relationships, and needs to model these with implicit joints).
In a pinch, you could try to reduce the number of solver iterations the physics does to get a one-time cut-accuracy-for-speed bump, but it's generally good to hold that in your back pocket as a worst-case-scenario, instead of relying on it.
Since the pinball can collide with quite everything in the scene, I cannot really reduce the number of mesh colliders. If nearly every mesh renderer is switched off, the game runs noticeably faster, but there are still hangs in some frames. If all mesh renderer are switched on again, more frames are stuttering. While the game runs at about 85 FPS, there are some extreme ti$$anonymous$$gs for a few frames: e.g. one frame took 168ms, where Drawing -> $$anonymous$$eshRenderer.Render -> $$anonymous$$esh.SubmitVBO took 96% of the time, resulting in 5.9FPS. Just two measurement steps later, we have 140 FPS again...
The same with GUI.Repaint: while most of the time it has no impact, sometimes it takes up to 80ms.
Reducing the number of iteration count doesn't yield a big performance gain. Is there a place where I can post my script so that others can review and tell me, if I do some really bad stuff in them? Except for the links I posted above, I don't have a clue which other pitfalls there are.
Have you enabled rigidbody interpolation for all fast-moving objects, such as the ball?
Thanks for the hint - I didn't know this setting. Unfortunately this didn't resolve the issue.
I've uploaded my (Windows) project including all graphics and script features:
EDIT: http://rapidshare.com/files/385619894/XRay-Pinball_Reloaded_forum.zip
EDIT: you also need to install Visual Studio 2008 redistributables: http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en and maybe you have to copy pthreadVC2.dll of my installation into the Unity\Editor installation folder.
EDIT: here's my project without the Windows related stuff: http://rapidshare.com/files/385929104/XRay-Pinball_Reloaded_noWin.zip
BTW: This morning I've tested the scene on a high end graphics machine: Quadro FX 3700, 1GB VRAM, 12 GB RAM, Xeon Processor, resulting in the same issue. Weird!
For correct display you should setup your dual screen monitors as horizontal span with a resolution of 2560x1024 (so 1280x1024 each).
The pinball game runs in fullscreen mode. Input: I: to toggle input mode (either get input from COM interface or keyboard. Default is COM). Space: Launch ball Left Ctrl: left flipper Right Ctrl: right flipper ESC: end game R: reset ball
I know collider geometry could be reduced, but as I stated earlier this didn't help. Maybe anyone can tell where my mistake is...? Or if Unity is causing frame stalls from time to time...? Please help!
$$anonymous$$eanwhile I made a simple test scene with a plane tilted by 5 degrees and a rigidbody ball. The rolling of the ball does not look as smooth as expected (some frames seem to take noticeably longer, although not as dramatic as in my pinball game)
Sounds like you should increase the physics framerate, which is 50fps by default at .02. Therefore if the game runs faster than 50fps, the ball won't update every frame, which could cause some stuttering (although using interpolation should largely fix that). With a pinball game, I'd be inclined to use 100fps for physics anyway.
Increasing physics framerate didn't solve the issue. I'd be glad, if you could find the time to look into my project. It's my first Unity project and probably I must have overlooked something important... $$anonymous$$aybe my geometry, maybe my usage of colliders, maybe a scripting issue, transparency issues... whatever
@logindrhenry: Apparently you added Windows-specific things to your project, so I can't look at it, sorry.
You can remove Windows based stuff by: 1) removing SerialPinball.dll from project 2) removing all CO$$anonymous$$ related stuff from PinballControlInterface.cs (so that you only receive keyboard input)
The link to the project without Windows related stuff (as far as I can see): http://rapidshare.com/files/385929104/XRay-Pinball_Reloaded_noWin.zip
