Hi, a quick question about this: in Skyrim, we use a lot of materials for seasonal purposes, but with traditional plugins, we can only apply those to STATICs. If I read correctly, this only applies to armor? Can we hope in the future to apply materials to furniture, activatables, and more types of records? Without the necessity to create alternative records and meshes?
Correct. My end goal is to apply them to the following: - Activators - Addon Nodes - Ammunition - Armor - Art objects - Body parts - Books - Climates - Containers - Doors - Effect shaders - Explosions - Flora - Furniture - Hazards - Head parts - Ingestibles - Ingredients - Landscape textures - Misc items - Moveable statics - Projectiles - Scrolls - Soul gems - Statics - Texture sets (yes, even those just for the sake of sanity lol) - Trees - Waters - Weapons
Of course each one will take time and different optimizations for how they're implemented but that is my target.
* PBR and complex material armor (not to mention on statics and everything else) are becoming more and more popular. As the plugin stands today, it seems to use fallout material files which do not support these materials. So, if the mesh is already patched for CM or PBR, is it possible to use material files only to swap textures around? My assumption is no since the shader type is defined in the material file so I assume that is overridden on the mesh in addition to the textures/whatever else in the material file * Do you have plans to support PBR and complex material? If yes, how? Will you be extending the material file format to include these new material types or doing something else like extra JSON files for the added metadata? * In PGPatcher I am currently working on a material system where MAs can define JSON material files for parallax, CM, or PBR and use those for patching meshes (this is for persistent patching so different from the goals of this mod). I wonder if it would make sense for this plugin to read those same custom material files for this use case?
Just spitballing, really cool stuff here!
I am more than happy to help you implement some of this stuff. PBR in particular has a lot of extra parameters so it can get complicated
I'm going to try to answer this as I understand it and you can correct me if I understood things wrong.
1. At the moment, support for BGSM files extends to only DDS files. I'll be adding support for other fields as well but since BGSM files support negative values, I'll most likely be using negatives to determine if a field should be used or not. Of course there are some fields I either won't be able to implement (wetness and subsurface for example) without hooking into either CS or ENB, so I'm shying away from those for the 1.0 release. There's also a field used in BGSM for whether or not to enable PBR so another option is if it's false, it treats the armor as if it's NOT PBR/CM capable. If it's true, it'll apply the patches as necessary to maintain previous PBR/CM compatibility.
2. The first point kind of addresses this. I do plan on supporting but any additional patches/fields that are required will most likely be included in the MaterialRecord as defined in the JSON file and processed at runtime.
3. That'd certainly be helpful as a system to hook into! I'd like to discuss the possibility for this because updating a NIF at runtime is where all of my pain came from with this mod.
When it comes to rendering and the tech behind PBR, I'm nowhere near the level of a lot of people on here. We should definitely connect about getting that type of support into the plugin!
Material Editor can save material files in JSON form instead of binary form. If you do that and edit them further in a text editor, you can just "invent" your own additional properties or texture paths that don't exist in FO4 and parse them.
Or you make a PR to add a "game" in addition to FO4/76 to Material Editor that has additional properties for Skyrim.
11 comments
Welp it got immediately flagged for suspicious files. Working with Nexus support on getting it resolved. 🫠
It's solved lol- Activators
- Addon Nodes
- Ammunition
- Armor
- Art objects
- Body parts
- Books
- Climates
- Containers
- Doors
- Effect shaders
- Explosions
- Flora
- Furniture
- Hazards
- Head parts
- Ingestibles
- Ingredients
- Landscape textures
- Misc items
- Moveable statics
- Projectiles
- Scrolls
- Soul gems
- Statics
- Texture sets (yes, even those just for the sake of sanity lol)
- Trees
- Waters
- Weapons
Of course each one will take time and different optimizations for how they're implemented but that is my target.
* PBR and complex material armor (not to mention on statics and everything else) are becoming more and more popular. As the plugin stands today, it seems to use fallout material files which do not support these materials. So, if the mesh is already patched for CM or PBR, is it possible to use material files only to swap textures around? My assumption is no since the shader type is defined in the material file so I assume that is overridden on the mesh in addition to the textures/whatever else in the material file
* Do you have plans to support PBR and complex material? If yes, how? Will you be extending the material file format to include these new material types or doing something else like extra JSON files for the added metadata?
* In PGPatcher I am currently working on a material system where MAs can define JSON material files for parallax, CM, or PBR and use those for patching meshes (this is for persistent patching so different from the goals of this mod). I wonder if it would make sense for this plugin to read those same custom material files for this use case?
Just spitballing, really cool stuff here!
I am more than happy to help you implement some of this stuff. PBR in particular has a lot of extra parameters so it can get complicated
1. At the moment, support for BGSM files extends to only DDS files. I'll be adding support for other fields as well but since BGSM files support negative values, I'll most likely be using negatives to determine if a field should be used or not. Of course there are some fields I either won't be able to implement (wetness and subsurface for example) without hooking into either CS or ENB, so I'm shying away from those for the 1.0 release. There's also a field used in BGSM for whether or not to enable PBR so another option is if it's false, it treats the armor as if it's NOT PBR/CM capable. If it's true, it'll apply the patches as necessary to maintain previous PBR/CM compatibility.
2. The first point kind of addresses this. I do plan on supporting but any additional patches/fields that are required will most likely be included in the MaterialRecord as defined in the JSON file and processed at runtime.
3. That'd certainly be helpful as a system to hook into! I'd like to discuss the possibility for this because updating a NIF at runtime is where all of my pain came from with this mod.
When it comes to rendering and the tech behind PBR, I'm nowhere near the level of a lot of people on here. We should definitely connect about getting that type of support into the plugin!
Or you make a PR to add a "game" in addition to FO4/76 to Material Editor that has additional properties for Skyrim.