2f1346c719
* Breaking up terrain FP wip - macro materials decoupled from meshes. Mesh creation and rendering pulled out from MeshFeatureProcessor into TerrainMeshManager. Stubs added for macro and detail material managers. Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Separated macro material management from the terrain feature processor. Also separated bindless image array handling from terrain feature processor. Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Detail materials separated from terrain feature processor. Also pulled out Aabb2i and Vector2i into their own simple classes Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Changed some classes so that when the SRG changes the classes don't need to be completely reinitialized and can instead just update their indices and push data to the new srg. Fixed an issue where MacroMaterialData wasn't being exposed to ScriptCanvas. Terrain shader reloads should now work correctly. Also added some debug logging to help catch an issue where sometimes detail materials don't seem to load. Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Terrain PR reveiw updates Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Some small PR review fixes. More comments in TerrainDetailMaterialManager.h Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Fixing unused variable causing clang failure Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Fixing unused variable in release. Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Fixing a forward declare that oddly didn't work on linux. Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Fixing linux missing include... not sure why only linux failed on this. Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> * Adding missing include Signed-off-by: Ken Pruiksma <pruiksma@amazon.com> |
4 years ago | |
|---|---|---|
| .. | ||
| CoreLights | 4 years ago | |
| Decals | 4 years ago | |
| PostProcessing | 4 years ago | |
| SkyBox | 4 years ago | |
| README.md | 5 years ago | |
| SceneSrg.azsli | 4 years ago | |
| SceneSrgAll.azsli | 4 years ago | |
| ViewSrg.azsli | 4 years ago | |
| ViewSrgAll.azsli | 4 years ago | |
README.md
There must be only one scenesrg.srgi and one viewsrg.srgi files per game project. They are always located in <DevFolder>/<Project>/ShaderLib, This location can not change, otherwise the asset processor won't be able to find the SceneSrg and the ViewSrg.
Each game project can customize the content of scenesrg.srgi and viewsrg.srgi as needed.
The preprocessor that works on behalf of the Shader Compiler defines the following priority for paths used to search for included files (ordered here from highest to lowest priority):
-
Paths defined in the file <DevFolder>/<Project>/Config/shader_global_build_options.json
1.1. Each path inside shader_global_build_options.json is relative to the <DevFolder>/ path. -
All valid scan folders returned by the Asset Processor with added "ShaderLib/" folder at the end. Here is a short summary of the folders that are scanned by the AP:
2.1. Folders specified in <DevFolder>/AssetProcessorPlatformConfig.ini
2.2. The Asset/ subdirectory within each Gem enabled for the Game Project. (Recursive). Examples:
2.2.1. <DevFolder>/Gems/Atom/Asset/
2.2.2. <DevFolder>/Gems/Camera/Asset/ 2.3. The root folder of each Gem enabled for the Game Project. (Non Recursive). Examples:
2.2.1. <DevFolder>/Gems/Atom/
2.2.2. <DevFolder>/Gems/Camera/ -
Finally, at the lowest priority is the folder: <DevFolder>/Gems/
With that being said, if a project doesn't provide its own shader_global_build_options.json then each time an azsl/azsli calls
#include <scenesrg.srgi>
it will default to
<DevFolder>/<Project>/ShaderLib/scenesrg.srgi
Similarly occurs with #include <viewsrg.srgi>
Because documents may become stale from time to time, the ultimate source of truth on how include paths are resolved is the source file
<DevFolder>/Gems/Atom/Asset/Shader/Code/Source/Editor/CommonFiles/Preprocessor.cpp
Function name: void InitializePreprocessorOptions(...)
And yes, even the location of that file may change in the future ;-).