Hello Guys,
I’ve been reading about Unity 3.5 and some doubts popped over my head, in the Multithreaded Renderer.
I am someone who always plays with terrain, not just because of my extension, P|Terrain, but because I really love terrains, and the biggest problem I have with terrains is their inability to be loaded quickly, or in background, thus blocking the main thread. This might or might not be a problem depending on what you’re going to do, but it is always unwanted.
What I couldn’t grasp yet is if the renderer will get a thread of its own and that’s all, or if, in the programming side of things, we will be able to manipulate this thread in some way, I mean, we can dispatch draw calls by instantiating new objects while the renderer will do its work, thus not blocking my script execution thread, or this only means that while the renderer is in a new thread, anything else stays the same (in other words, no relief to my problem).
Do you guys have any insight on how this will work?
Thanks!
At a guess it just means the skinning and geometry submission (draw calls) will be done on one core, leaving the other core for physics and scripts. They will like most threaded stuff, meet up at the end.
You don’t need to do anything or change anything. Unity is already doing this stuff and you haven’t noticed (skinned meshes).
the scripts will still remain all in the same thread, thats not gonna change (can’t, you would lose more than you gain as every single operation would be mutex locked. Keep in mind, the engine is and will remain on the C++ side, not .NET). The change is that the processing for the rendering no longer hogs the same thread too, that it happens on other threads to open up more cpu for programmed interactivity.
Thanks hippocoder and dreamora.
About the thread, I know that, the script thread will not change, as Mono is still interpreted from the C++ side. My doubt lies in the supposition that, once the renderer and the script is in different threads, instantiation commands will not hang the script thread while populating an object. This may not save me from the .SetHeights() problem with terrains, for example (as I imagine the blocking part of that lies in the actual population of data rather than passing the data to the renderer), right? Maybe it will make it a bit faster as this second part will be moved to another thread, though?
Just trying to figure out how this will actually affect what I’m doing, and how can I benefit from it in the end, if I can at all.