In U2017.3.0b7, when attempting to set terraindata.splatPrototypes it requires the textures to be read/write. This wasn’t required in previous versions. What’s changed?
TerrainData is missing splat texture 0(tex name), make sure it is marked for read/write in the importer.
UnityEngine.TerrainData:set_splatPrototypes(SplatPrototype[ ])
So just to check a couple of things - are you doing this procedurally? When are you seeing the message?
The honest answer is that a splat texture has always been required to be read/write enabled, it’s just that the build process was setting this at build time it when it found terrain textures, the latest change was to fix issues when the textures could be assigned in other ways and to generally warn that this setting was required.
Yes, it is part of our Landscape Builder asset - so it needs to support multiple versions of Unity. It is always being set in code. To be honest, it has always been an issue updating the Read/Write status as it seems to behave differently in different versions. Some versions require you to first set the TextureImporterType to Advanced or the Read/Write status doesn’t “stick”. Just setting isReadable is often not enough.
We do have a lot of error checking in the editor and at runtime but obviously not enough. Is there a preferred method for making a Texture2D read/write (in the asset database) that always works from U5.4 onwards?
Could you please file a bug report with a minimal reproduction case for this issue and reply in here with the case #? There’s nothing related logged yet.
As mentioned in the other thread, the editor error is being removed and will hopefully be gone for the next patch. However, I would like to re-iterate; the only thing that has changed under the hood is preventing a crash which could occur when calculating the basemap if a non-read/write texture was assigned to the terrain procedurally or from an asset bundle. If Unity knows the texture is going to be on the terrain at build time, it will mark the texture as readable then. The addition of the message in the editor was supposed to alert you to that but it has caused a lot of noise and worry. Additionally, because Unity will still set the texture readable, even if you don’t, this means the error is no longer present at runtime in the built player which is adding to the confusion. So we’ve decided to keep all the error reporting in the players only and to update the docs to explain the editor behaviour.
If you are able, I would recommend rolling back to the version of Unity you were on before and wait for the next patch if you need the patch release.
I’m not sure why it isn’t being raised as a warning. Happy for Unity to alert people to the issue, but IMHO, for this scenario an Error seems a little extreme. We tend to only raise errors when something is broken. If a user needs to change something, we’d typically raise only a warning.
This is happening when loading a scene in the editor, nothing to do with being set procedurally. I had to set all the textures read/write that were used on terrains.