We recently switched our Android game to ETC2 with half res 32bit uncompressed as fall back.
The problem is that now the textures in the editor all look half res (since presumably ETC2 falls back in the editor?), which has led me numerous times into “why does this texture look really bad → Ooh it’s half res” type of investigation.
I could disable “compress assets on import” and have everything be full res “not yet compressed” state, but that would push the ability to produce a quick test build at any time multiple hours away, which isn’t great.
Is there another solution/workaround I’m maybe missing?
I suppose you can have it “full res” by default and switch it to half res for the build using a script (and back after the build).
Alternatively you can try switching the editor to GLES3 (if you’re on Windows and not on an AMD GPU) - this would give the Editor ETC2 support.
This was one of the first things I tried, but it doesn’t work since for this to actually take effect it needs a full reimport (complete with re-compressing to ETC2, which takes hours) and then again a full re-import and re-compress to switch back to half 32bit. At least that’s how it works in 2018.4.
But I still want to note that the whole process is somewhat awkward. It wasn’t super obvious that the editor was falling back to the ETC2 fallback, and changing the player settings for Windows when I have the project set for Android, while it makes some sense, it’s un-intuitive.
(I’m not really complaining, since the workaround all in all was easy though, I’m just giving some feedback is all)
It is awkward in some sense, true, but then it does make sense:
Editor uses the same settings as the standalone player (Windows Editor will use the same graphics API as the standalone player, for example). This is done to minimise the differences between player and editor.
At the same time, default Editor graphics APIs have no support for ETC2 (it’s an OpenGL ES only thing), so it promptly decompresses stuff to the specified format, and you get the exact behaviour as if you’d be running on Android that doesn’t have ETC2 support.
I think it should print this in the log somewhere, most likely in the Editor.log file. This part can likely be improved - e.g. by outputting a warning to the console.
This part is not intuitive. I always assumed that when I was switching to another platform, the Standalone player settings had nothing to do with my current Unity experience.
So the “Player” settings, of a different platform than what I have switched my project to, affects how the “Editor” is set up.
Why can’t we agree that it’s a goofy behaviour that wasn’t really intentionally designed, but a byproduct of some other decision that makes sense there, but otherwise, this is super awkward and undocumented to use?
The manual doesn’t even mention it :
If this is intended and designed, maybe write something along the lines of “oh and if your editor is running on Windows, then it affects that as well”.
Cool, so when I’m reading the section about the Standalone player settings in the manual ( https://docs.unity3d.com/Manual/class-PlayerSettingsStandalone.html ) I should really be reading a different page, that is not even linked by this page and contradicts the information in this current page I’m reading.
I offered you my feedback. If it makes sense to you, good for you. God knows Unity has far far worse issues than this.
@AcidArrow Manual is being improved, constantly. I appreciate your feedback, and I will mark this for fixing - in the documentation.
It indeed seems odd that standalone player settings affect Editor behaviour when active platform is different, but would you prefer a separate Editor tab in those settings instead?
If you’re working on a project that targets standalone, it can work on exactly same graphics APIs as the Editor, and having both use the same graphics API would exclude differences between graphics APIs from “same picture in Player and Editor” equation. And having a separate Editor tab in there would just introduce potential inconsistency.
No, completely separate editor settings are probably not a good idea, but it somehow being super clear that these settings are also “shared” for the editor, I think would be a great idea. It being more prominent in the manual would be a first step, but there are things you can do in the editor as well:
Maybe have a a double ** that you can read that these also double as editor settings. Or an in-inspector info - note thing that you add to various menus lately. Or… something, these are from the top of my head, I’m sure if someone makes it his job for a while to find a better solution for this will come up with something better.
I will just say this, I have been using Unity for a decade, and it took you replying to me on the forums to learn about this behavior.
(although admittedly, I haven’t really actually needed it before today)
So I thought I’d switch the editor to Vulkan. And I did. And turns out Vulkan makes the editor insta-crash. It tries to open the project, it shows me the initial Unity splash for a few seconds, then closes silently (no bug reporter or anything).
I am on a TECH release, which is my fault. But I hear 2019.3 is nearing LTS status… which… yeah.
So my only way to be able to use the editor “normally” and have full resolution textures, is to switch the editor to DX11, tick off reimport assets on import, re-import everything so that they’re no longer compressed, and then every time I want to build I’ll have to wait 5 extra hours. Then again break compression when I want to work and re-compress everything for each build.
Can you take a look in the Editor.log and see what’s there? There should be a stack trace from the crash
There have been numerous Vulkan fixes recently-ish, I guess not all of those made it into 2019 branch yet.
No, sorry, I have given up on Vulkan. Even if it somehow didn’t insta crash I have little hope selection wireframe would work, which is the actual problem I am trying to fix.
I guess I’ll have to write my own wireframe shader and switch to it when I want to see the wireframe of a mesh.
