A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Now in Beta! Get 1:1 live lessons on any Unity topic or help troubleshooting your project – Connect with an expert on Unity Live Help
Discussion in 'Data Oriented Technology Stack' started by smcclelland, Mar 19, 2019.
Why do you guys not put it on the Github, since the download server is unstable
Probably do to project size.
1) The import-texture-processor script always compile to BC4 or 7, anyway what you set up in the editor. This took time to import. Rename this script extension to .cs0 or mark it as hidden in Windows. Unity does not recognize files or complete folders are hidden in file OS system. You should take care about to have "visible hidden files" under folder properties in Windows first.
2) The Textures are not optimized for ppl are interesting in code only. Textures use 16bit and use a lot layers at 8K. Most of them are >500MB. Change the original Textures to 8 bit RGB and flatten all layers and set them to dxt5/1 in unity.
On my oldest 10 year old cheesy laptop with the first Windows7 64b and Sp1 4GB, I reduced all Textures to max. 512 dxt5. I got 15fps in editor. Absolutely great ECS performance al the way.
Eg. having below 3 frames indicates Texture Swapping at GPU Memory overflow or HDD Swapping. Also Texture sampling is at the core of all Memory Bandwidth costs. The fewer textures we use, and the smaller we make them, the better. The more we use, the more cache misses we are likely to invoke, and the larger they are, the more Memory Bandwidth is consumed transferring them into the Texture Cache. Such situations should be simplified as much as possible to avoid severe GPU bottlenecks in case of weak hardware devices and insufficient GPU Memory.
There is a another temporary optimization you can set in Unity Editor. Set LOD Bias in the Project Settings > Quality to < 1. Values below 1 cause to enlarge the virtual distance to the LOD objects.
Thanks for the so detailed explanation, however nothing of the above has something to do with the real problem. After banging my head against the wall for hours (metaphorically) I discovered this wasn't neither a CPU nor a GPU problem, but a UI design flaw. As a seasoned PC user I did expect the game to respond to mouse commands, but it didn't, so I assumed the game was performing extremely bad, and that assumption was reinforced when I saw the game eating most of my memory and CPU, but that wasn't the case, because when (after hours) the idea of trying with the keyboard instead of the mouse came to my mind, I was finally able to see some action.So, as you can see, all this fuss was caused just because someone forgot to make sure the UI was able to support mouse input.
Never had problem with the default setting and mouse input by default in buidl or editor in MC. Perhaps you USB mosue rate is set to 1000Hz ?
Hmmmm... I don't understand how that would affect this game and this game only?... I think is most likely that you have a newer version where this issue has already been solved... I don't know the version number, but I think I have the very first. Thanks for your interest, I do appreciate it very much.