Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MaterialType Default Values Not Initially Applied #5213

Closed
santorac opened this issue Nov 2, 2021 · 1 comment
Closed

MaterialType Default Values Not Initially Applied #5213

santorac opened this issue Nov 2, 2021 · 1 comment
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. sig/graphics-audio Categorizes an issue or PR as relevant to SIG graphics-audio.

Comments

@santorac
Copy link
Contributor

santorac commented Nov 2, 2021

Describe the bug
If you change the default value of a material property in a .materialtype file, that change will not get picked up by .material files of that type.

Steps to reproduce

  1. Set AtomSampleViewer as the active project
  2. Run the AP
  3. Modify MinimalPBR.materialtype by
    a. Set metallic defaultValue to 1
    b. Set roughness defaultValue to 0
  4. Note the AP reprocesses MinimalPBR.materialtype but does not reprocess MinimalPBR_Default.material
  5. Run AtomSampleViewer
  6. Open RPI/Mesh sample
  7. Select a model to preview (recommended materialeditor/viewportmodels/shaderball.azmodel)
  8. Select the material materials/minimalpbr/minimalpbr_default.azmaterial
  9. Note the surface is a rough white surface
  10. In the AP window, the Assets page, find MinimalPBR_Default.material
  11. Right click -> reprocess file
  12. Note in AtomSampleViewer the model is now shiny chrome

Expected behavior
The model should have looked like shiny chrome the first time around.

Actual behavior
You have to manually force the AP to process the material file in order for the appearance to be updated.

Assets required
Use AtomSampleViewer

Found in Branch
https://github.com/o3de/o3de/tree/stabilization/2110

Additional context
As part of an effort to reduce asset processing times when shader are updated, material build dependencies were loosened. They are now too loose, so materials are not reprocessed when they ought to be.

See also #5215
See also #6594

@santorac santorac added kind/bug Categorizes issue or PR as related to a bug. needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Nov 2, 2021
@santorac
Copy link
Contributor Author

santorac commented Nov 2, 2021

To work around this issue, open the Asset Processor window, "Assets" page, right-click on the folder that has all your .material files, "Reprocess folder".

@santorac santorac added sig/graphics-audio Categorizes an issue or PR as relevant to SIG graphics-audio. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Nov 2, 2021
@santorac santorac self-assigned this Nov 2, 2021
@superkitcath superkitcath removed the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Nov 3, 2021
@superkitcath superkitcath added the needs-priority Indicates a PR lacks a `priority/foo` label and requires one. label Nov 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. sig/graphics-audio Categorizes an issue or PR as relevant to SIG graphics-audio.
Projects
None yet
Development

No branches or pull requests

2 participants