This would keep the base distribution 'clean' and easy for other mods' to distribute, while still giving a local source for the patches (and/or any assets you may want or need to include). I would not be opposed to distributing the stock-conversion patch through the Textures Unlimited OP and/or repository, but it would have to be done as a separate secondary download that users could optionally install. Am I willing to deal with support for people 'surprised' by the changes? No, makes me depressed every time I see one of those posts) (Do I personally want to include the patches? Yes, absolutely. I learned long ago to not touch stock or other mods parts as part of any 'default' mod setup I simply lack the patience to deal with support requests from people who don't bother looking at what they are installing. Rather it is me trying to pro-actively reduce support posts from people who don't examine the contents of the mods they install, and then come to the forums with posts of 'why are the stock parts looking different'. Please don't take it personally, as it absolutely is not (you've done excellent work on the stock patches). I'll make the change when I have time. Honestly, I had originally thought you'd want to include a generic cfg for use with stock parts and made it with that in mind, but you've made it very clear you do not wish for this mod to be used except in a mod-component scope, so I have instead begun working on my own mod. Willing to investigate potential alternative 'tinting' code, as the current multiplier setup has some very obvious limitations, most notably in regards to the SPEC/MET recoloring (would be impossible to make a part more metallic or smoother than was defined by the original textures). Would still require that mask textures be created for parts, but should allow for re-use of their existing DIFF/SPEC/MET textures, with the recoloring sliders acting as multipliers to the existing values. Hopefully will have time to get this tested (and cleaned up if necessary) in the next few days. I also (possibly/maybe) added in a keyword-based 'tinting' mode to the Masked and PBR/Masked, but have not yet found time to do any testing or verification on that feature. So, will probably be leaving the change in-place on the PBR/StockXXX shaders now that the damage has already been done it was a fix for an actual issue after-all. This was causing all _Metallic multiplier properties to default to zero, and breaking parts that were setup with actual metallic texture inputs (unless I adjusted their config to add the _Metallic property block and set the value back to 1 manually).Īs you shouldn't need to define/adjust parameters unless you are actually using them/changing them from default, I felt this was an important issue to get cleaned up for the Masked and standard PBR/Metallic shaders, as those will most often be used with proper texture inputs. I'm guessing that Unity is using that variable name internally somewhere in one of their files, and it is getting pulled into the shader source from one of the #include's. Have to apologize for breaking it like that, it was not at all what I had intended originally.Īs to the why - Apparently Unity has some sort of internal conflict when the _Metallic property name is used, where it refuses to respect the default value as specified in the shader source file. A quick search to replace _Metallic with _Metal puts it all back in proper order (I had originally not intended to change that specific shader, as you were already using the property everywhere, but apparently I was a bit overzealous with my edits, and didn't catch it until yesterday). Just letting you know as this impacts your stock-patch set. Quick heads-up that I (inadvertently) changed the _Metallic parameter name in the PBR/StockBumpedMetallic shader, which is now named _Metal.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |