Hi all, and hopefully Unity dev team.
Just had a quick question that's been on my mind for a couple of weeks. In what area(s) does the multithreaded renderer really shine in? I'm going to make a wild guess and say draw calls, but I'm just trying to find out where I can get away with more of X (X being whatever the multithreaded renderer takes advantage of).
Loving the cool new stuff in 3.5,
Unity dev team checking in
We got a lot better at drawing scenes that are mostly static geometry, i.e. you don't use skinned meshes everywhere or modify vertices and materials on the fly. The reason is that we need to synchronize all changes between the threads. Anything whose properties didn't change, we can just say "hey, draw this like you did last frame" and it gets processed extremely quickly. Most of the time is spent in the video driver and that happens on a thread far away from any game code.
Skinned meshes are still fine, but they were multithreaded even in 3.4 so you won't notice any difference. Moving static meshes around is fine too, we get the speedup by knowing you didn't change the mesh itself. You want to be a little careful with dynamically created geometry but we've done what we can to make sure it's not slower than before. Fortunately in most games, a lot of geometry never changes.
Hope this helps,
Reading from the release notes... is a multithreaded solution for the webPlayer on the works or we shouldn't have our hopes up?
With 3.5 out now, the performance disparity between WebPlayer and Standalone has just increased twice fold. When trying to sell the web export option to the client, it's hard to not lose the performance argument.
We do static and dynamic batching on the render thread, as well as communicating with OpenGL or Direct3D. It's hard to say which part is more expensive, and typically it's the main thread that's blocking you anyway. To make the main thread fast, you should stay away from too much updating (from script) of geometry and materials.
It's possible to start both Unity editor and player in single-threaded mode to do your own comparison. It's a command line switch: -force-gfx-direct
It will take a bit of effort for us to make this work, mostly because of all the different browsers we have to test. I agree it makes sense to support WebPlayer multithreading, so I'm sure we'll get it eventually. We just ran out of time before 3.5 release.
Thank you Kaspar. Best of luck for making it work!It will take a bit of effort for us to make this work, mostly because of all the different browsers we have to test. I agree it makes sense to support WebPlayer multithreading, so I'm sure we'll get it eventually. We just ran out of time before 3.5 release.
I can't use these two things together.