koobas.hobune.stream
Resources.Load() failing in build if Resources folder has too many files
I've seen a number of questions asked about using Resources.Load but I have not found the answer to my problem.
I am creating an application that involves playing video clips. I originally tried using MovieTexture, but the video lagged in the application. I then opted to convert the video into a folder of images/frames and play the video using them. I used Resources.Load over WWW as WWW caused in game lag/delay. This was successful.
However, as I uploaded my third folder of images I found that my application no longer worked when I built it (it still worked in the client). When built, the Resources.Load function found nothing in the Resources folder. After some fiddling, I found a breaking point in the Resources folder whereby if I add one single additional image the built application will go from functional to broken.
Has anyone encountered this before or can suggest workarounds? Preferably without lowering the quality of the images.
I have about 2900 files of various resolution. Total memory is about 1.64 GB.
It seems to be more a problem of size rather than number as replacing the HQ images with lower quality versions allowed it run correctly.
Surely there's a way to play videos without delays. Splitting videos into thousands of individual images seems absurd and asking for memory problems. I think going back and trying to get the videos to play properly would be better than trying to find a workaround.
The reason I opted against using $$anonymous$$ovieTexture was not because it didn't compile, but because playing a HQ video caused the entire application to stutter (not simply the video). For $$anonymous$$ovieTexture to work smoothly, I have to lower the quality of the video to the point where it was unwatchable. The images/frame solution, while not graceful, allows me to play at HQ.
I have encountered this problem before. In my case, it was because I tried to load a file and put it in a variable that had the same filename as a different filetype, which got loaded instead, and Unity foolishly tried to put it into the desired variable type and gave me errors. Lesson: Never have the two files of the same name in the same folder, especially not if they are nof different types.
