Fbx exporter dependency to material

[etherealchain]

In the current implementation, ModelExporterComponent export both model and material asset, which result in the following dependency:

FBX -> MaterialAsset -> MaterialType -> Shader

The result is whenever shader file is updated, fbx will be reprocessed by AssetProcessor, which wastes a lot of time and is not good for fast iteration.

To address this issue, we need to find a way to break the dependency between fbx and material, a possible solution is to use the intermediate asset feature used by MaterialTypeBuilder.
To declare the product as intermediate, one has to set platform name to "common", and set the IntermediateAsset flag on the final product, to achieve that we may need to modify SceneBuilderWorker a bit.

After discussing with @santorac, the ideas are as follows:

1. When exporting material from a scene, export MaterialSourceData instead of material asset
2. Modify SceneBuilderWorker to output an extra "common" job, use this job to output MaterialSourceData and add the IntermediateAsset flag
3. The output job product MaterialSourceData will be put in AssetProcessorTemp folder
4. Because it's an intermediate product, it should be pickup by MaterialBuilder and finish the job

A side note is the model asset will still hold a material asset, as default material. So we have to load it when we are creating model asset, after the material had been built by MaterialBuilder.

[siliconvoodoo]

A side note is the model asset will still hold a material asset, as default material.

Do you know why is that?
Is the proposal a way to change this:

to this:

[santorac]

That's a good observation. For the job dependency, we could use an "OrderOnce" dependency instead of "Order", which is intended for situations like this, where you need to discover the AssetId of something and after that you don't want the dependency to be applied.

(I do wonder if there might be a better option though, I'll ask around.)

[etherealchain]

Ah yes, I see similar handling in MaterialAssetDependenciesComponent::ReportJobDependencies, I will give it a try.

[amzn-mike]

I want to point out that the UUID for the intermediate asset isn't random, it is based on the relative path of the file, so it is possible to get the UUID before AP has processed the file. That said, I'm currently working on the metadata relocation system which will change how the UUID for intermediate assets is generated to be based on the hash of (SourceUUID:BuilderUuid:SubId). All of this should be info available to the exporter.

[etherealchain]

Just want to be sure which part are you talking about.
Looks like the material asset id is generated randomly here
https://github.com/o3de/o3de/blob/40872d3dd7eeebfd8737099828a2a115a59f216f/Gems/Atom/RPI/Code/Source/RPI.Builders/Material/MaterialBuilder.cpp#L187
Am I missing something?

[santorac]

Ah I see, yes that is confusing. That random AssetId is not actually stored or used anywhere, other than a temporary ID in memory. The asset system requires every Asset object in memory to have an AssetId, so we just use a random one. The actual AssetId that the system assigns to the asset in the cache is different.

[santorac]

FBX -> MaterialAsset -> MaterialType -> Shader

This dependency chain isn't quite correct. The FBX doesn't depend on a MaterialAsset, it depends on a MaterialTypeAsset. And it doesn't depend on any MaterialTypeAsset, it only depends on StandardPBR.materialtype.

FBX -> MaterialType (StandardPBR.materialtype) -> Shader