One scenario is an fbx change that, even with the same mesh, unity figures it's different and they unlink, leading to an NRE.
Another scenario is just the underlying object no longer existing.
Another are blendshapes being removed.
The hardness of the problem lies in what we can reasonably do in these and other cases.
One hypothetical idea is to error on generation and show missing reference clearly in the ui, with some utility to help repair, plus some automation to make it easier. We could store the path (which we already to for gameobjects) and attempt recovery based on that. For blendshapes, candidates would be objects with smrs that contain the required blendshapes.
Another hypothetical solution is to support baking, where we create the object hierarchy with the required smr components that use meshes that are copies as an asset (or subasset if we can somehow add it to a prefab asset, which i doubt we can). Here, even if the underlying fbx is changed, for instance, we can still generate. The baked proxy would be generated when the user wants, replacing the original. Also a note that, reusing some unit test code, we could generate our own meshes that have the right shape keys, since we don't actually care about them working.
And there's a hybrid approach, where we autogen the baked proxy as things are added and removed. Generation can use the baked proxy (no point in fallback). We generate warnings during generation, and we visibly show issues in ui. We'd still then want some recovery mechanism, even a simple one such as allowing object swaps.
One scenario is an fbx change that, even with the same mesh, unity figures it's different and they unlink, leading to an NRE. Another scenario is just the underlying object no longer existing. Another are blendshapes being removed.
The hardness of the problem lies in what we can reasonably do in these and other cases.
One hypothetical idea is to error on generation and show missing reference clearly in the ui, with some utility to help repair, plus some automation to make it easier. We could store the path (which we already to for gameobjects) and attempt recovery based on that. For blendshapes, candidates would be objects with smrs that contain the required blendshapes.
Another hypothetical solution is to support baking, where we create the object hierarchy with the required smr components that use meshes that are copies as an asset (or subasset if we can somehow add it to a prefab asset, which i doubt we can). Here, even if the underlying fbx is changed, for instance, we can still generate. The baked proxy would be generated when the user wants, replacing the original. Also a note that, reusing some unit test code, we could generate our own meshes that have the right shape keys, since we don't actually care about them working.
And there's a hybrid approach, where we autogen the baked proxy as things are added and removed. Generation can use the baked proxy (no point in fallback). We generate warnings during generation, and we visibly show issues in ui. We'd still then want some recovery mechanism, even a simple one such as allowing object swaps.