Hey, I’m using the www-Class (Unity - Scripting API: WWW) to load textures from my local file system. I want people to be able to change these textures so I can’t embed them in my project.
This worked fine a while ago but it now started to get REALLY slow for an unknown reason. Maybe one of the latest Unity3D updates caused this?! It now takes about 2-4 seconds for each www-Call which far too long when you consider that I’m just loading local files. The textures are png-files and they are really small as well (16x16 pixels).
The part taking so long is the www-Object itself to reach the status www.isDone==true. Actually accessing the texture afterwards is fast.
Does anyone have the same problem or know why this happens or how to solve it?
We just hit this problem as well with Unity 5.0.2 / Windows 7 x64 using WWW to load local image files using;
var www = new WWW("file:///path/to/file");
Depending on the state of the network connection the local image load is either instant or Unity blocks and the image load takes 3-4secs. The test images are ~50k jpg’s so they should load nearly instantly every time. The same applies for loading other content types, not just images.
We haven’t fully tracked it down yet but using ProcessMonitor we can see that even loading a local file (using WWW with file:///) Unity appears to ask the OS/network stack some things (it loads dlls and does some other weirdness) but doesn’t make an actual outgoing network connection, and then it loads the local file.
We noticed that if there is a gateway in the network settings but no internet connection Unity blocks for 3-4secs and then loads the local image ok. After unplugging the network, disabling the network stack, or updating the gateway (ie. a usual connected state or no connection) Unity loads the image immediately. It’s a strange bug and sometimes seems dependent on whether a full connection or non-connection exists at the first request or not. Plugging/unplugging the network connection while the app is running also makes the images load immediately or with the blocking problem - nothing appears cached from Unity talking to the OS/network stack when making further WWW requests for local files.
The workaround is easy enough for our case - we simply load the local image via a byte array and load it into a texture;
byte binaryImageData = File.ReadAllBytes(localImagePath);
I found it out myself. Unity3D fails to choose the correct network adapter automatically I guess. I have Hamachi installed on my system and it looks like Unity3D first tries to use the network adapter of Hamachi with EVERY new www-request you make. This also affects the Unity3D asset store which is incredibly slow because of this problem.
The solution I found is very simple (but a bit inconvenient for Hamachi users): Disable the network adapter of Hamachi while using Unity3D.
I assume that the same problem can also be caused by other installed network adapters and not only by Hamachi network adapters.