Closed jhaverkost closed 2 years ago
Thank you for bringing this forward. I will have to take a look at this when I prepare a next round of updates to the project.
@jhaverkost - Realized I never got around to this, but then again I haven't put much time at all into the project since then. I looked into it a bit and the LODData are marked dirty here. This whole process is asynchronous though, so if you click on a LOD mesh it may be empty until the job completes and then you'll see it update.
You are correct though that it won't save all the files when all the jobs complete. They will get saved when the project is closed or an Save Project
is selected explicitly.
Did you run into a case where this was impacting you in a project in practice?
Closing this issue as there is/has been no activity. Please reopen if needed.
Sorry for overlooking your previous question.
If I remember correctly, this was occurring during a batch process so there was no closing of the project or explicit Save Project that triggered the saving of the asset files meaning it was immediately obvious that there was an issue. We managed to work around the issue (though I can't remember how right now...) so the impact would have been minimal. I mainly just wanted to bring it to your attention. Considering I haven't thought about this in a year, it must not have been that pressing.
Thanks for responding.
When importing a new model via
ModelImporterLODGenerator
, the serialized meshes in the generatedLODData
asset might be empty/zeroed out. This appears to be due to the fact that LOD meshes are generated using Jobs/Coroutines and theLODData
asset is not marked dirty/resaved after those jobs are completed.A quick test involving tracking the
JobHandle
of each mesh generation call and saving theLODData
asset after all jobs are complete appears to produce the expected result where the meshes are actually serialized with vertex count, index buffer, etc. The test used the handles from https://github.com/Unity-Technologies/AutoLOD/blob/master/Editor/ModelImporterLODGenerator.cs#L212 but there are a few otherGenerate
calls that would probably need to be tracked as well.