Error message for modifying shader:Destroying assets is not permitted to avoid data loss

Based on the existing shader, I removed the color of normal larger than a certain value in the map and replaced it with a pure color. There is no problem with loading and display, but this error is reported. Although I can understand it, the code modification in the plug-in is not appropriate. Is there any way?

To clarify, are you trying to modify the existing tileset shader, or did you create a copy of it? Can you tell us what steps it takes to reproduce this error?

I copied the shader from the package into the project, then made appropriate changes to the shader.I attached my shader file. I hope I can eliminate this mistake.
CesiumUnlitTilesetShader1 (22.6 KB)

I copied the shader from the package into the project, then made appropriate changes to the shader.I attached my shader file. I hope I can eliminate this mistake.
CesiumUnlitTilesetShader1 (22.6 KB)

Using the above shader, and then updating a parameter in update, it is found that the modified effect is always visible to the naked eye with a delay change. For example, when updating lod, the default map without modified parameter is displayed first, and then the map effect with modified parameter is updated. I would like to ask whether tile update is in UPDATE or in which function class?
In addition, code replacement of shader files during operation will cause all the tiles to refresh, resulting in visual discomfort. Is there an interface to prevent the loaded tiles from being replaced immediately?

@Kevin_Ring @janine I hope you can give guidance to the error after shader modification above. The whole shader is also written with shadergragh

I downloaded your shader and moved it into my copy of the cesium-unity-samples project. Then I made a material that used it, and dragged it to the Opaque Material on Cesium World Terrain. When I press Play, I get different console errors, but they don’t look anything like yours:

So I can’t tell what’s wrong. Is there anything I should have done differently? And for the record, what version of Cesium for Unity are you using, and which render pipeline?

For your other question, this is a known bug that we want to address, but unfortunately don’t have a fix for. We have an issue open on Github to track it: Changing material parameters does not update material for all tiles · Issue #180 · CesiumGS/cesium-unity · GitHub

I put the shader changes into a fixedupdate, which is visually unnoticeable, but also incurs a performance burden. Thank you for your answer and look forward to further optimization of the plug-in

  • I used unity2021.3.7f1c1
  • using the URP render pipeline
    2023-04-11 09-09-23

  • No other changes

    Scrolling around the scene or clicking Refresh Tileset button will result in an error

I found out today that this material is not for cesium world Terriain, but for Blank 3D Tiles Tilleset. I’m sorry that I didn’t make it clear. Can this problem be solved? The shader I modified was written to simulate the snow effect.
Looking forward to your reply.

Hi @chiqiangzhe,

I haven’t forgotten about this, but because of limited bandwidth, I’ll need some time to figure out what’s wrong. Thank you for your patience.

hello janine, Is there a solution to the problem?

Hi @chiqiangzhe,

I don’t have a solution right now, because I was only able to reproduce it once in my project and it ended up going away on its own. (Perhaps after recompiling the Cesium for Unity Native code?)

Can you try reimporting the Cesium for Unity package to see if the error persists?

I remove and import again,Assign 3D Tile Tileset (non-Cesium World Terrain) to the material ball created using the shader I modified (in my project file)。
The problem still exists, but only after I use my own modified shader。
Too many of the same error information caused great trouble to my development and debugging.
I would have to follow his instructions, download the source code, and change Destroy(the object) to DestroyImmediate(the object,true). But I’m afraid there might be some other unknown problem hidden

Hi @janine ,
I’d like to ask you why you don’t use DestroyImmediate(object,true) when I look at a plug-in. I want to change this and my problem will be solved, but the deletion of this asset will cause more problems. Since I have no experience in modifying the source code, I don’t know how to try it. Could you please help me to try it.

Hi @chiqiangzhe,

It’s because DestroyImmediate(object, true) can end up deleting assets from your asset folder. A Material can be loaded from an asset in your project, so I’m worried that by setting this to true you’d accidentally delete the asset from your project.

I’d like to try and debug it but we can’t consistently reproduce the error on our end. It’s confusing because we’re using Object::Instantiate to duplicate the material, so it really shouldn’t be duplicated as an asset. Is this error genuinely obstructing your progress? Is it preventing you from changing the material?

There is no problem running the project, but the error has been reported, and I am worried that this will affect the performance of the project.
The default shader of the plugin will not be a problem, it should be caused by me changing the shader, but I have no ability to optimize it.The increased complexity of the shader logic causes the tile update flow to be blocked.
It seems that this problem can only be temporary, this should be my rare case.
Thank you very much for your reply

@chiqiangzhe I’m sorry for the inconvenience while developing. We’re planning to make changes to the material system next month, so I’ll keep an eye out for this error as we work. I’ll notify you on this thread when our changes are available.

I had a similar error (“Destroying assets is not permitted to avoid data loss.”) when I made a copy of the material and shader for the Cesisum Tile, as I also have a need to modify it. However, I was able to get rid of the error (for now) by deleting the reference to “green1x1.png” in the “metalicRoughnessTexture” property of the material. Not sure why this reference was there.