When using the unity standard shader, a “dot” is showing for lights when the smoothness value is set to 100%.
The screen shot is showing what is happening.
The top red circle shows the dot for a point light which is illuminating the room.
The below red circle is showing the spot light from the player’s flashlight.
I dont know if this is some error with the Unity standard shader.
There was a thread about this a long time ago, but I can’t find it.
Does anyone have any tips on why this happens?
I am using Unity 5.2.
I heard there was some correction to the smoothness calculations now in Unity 5.3+. Does this relate to this issue?
I do get specular aliasing. But I don’t think the two dots are from specular aliasing. The normal map is turned “off”, so there shouldn’t be anyway the aliasing would occur.
I figured out the problems I was having with specular issues. I needed to start creating specular maps using a program like CrazyBump. The texture is inputted into the program, and the specular map is generated. The file is passed to the Unity standard shader. The specular artifacts no longer appear. When not passing in these files, the specular artifacts appear like crazy.
The “specular” map for the Standard shader (if you’re using the standard specular setup) should usually be a flat RGB (56, 56, 56) for almost all non-metal surfaces, maybe a similarly dark slightly blue over the tiles. All the “action” is in the alpha of the specular texture, that’s the smoothness map, and that should have significantly more range in values with the grout being a noisy near “black” and the tiles being nearly “white” depending on how shiny you want them. Since you want very different values from the specular map’s color and alpha channels using the “alpha from greyscale” isn’t a great option.
The program I’m using, which is a $200 program, does not generate information on the alpha channel. It is just generating the RGB portion of the specularity file. After almost two days, I was able to figure out how to use GIMP to copy the RGB channels to the alpha channel of a new specular map. http://graphicdesign.stackexchange.com/questions/8397/gimp-using-an-image-as-the-transparency-layer-of-another-image
The hard part is figuring out how to not touch the RGB when adding the alpha channel in GIMP.
The tiles arent a good example, but I was able to use the process for another model. It is a metalish door, with dirt on the outside. The goal is the dirt has full roughness so it doesn’t pick up the reflection probe (the green light is light the refl probe is capturing):
Yeah, Gimp’s handling of alpha channels is kind of terrible. That’s not really Unity’s problem to solve (pretty much all professional graphics tools handle alpha channels much more gracefully). I’ve been using Photoshop to add unique data into the alpha channel for over a decade now, and the developers of Gimp simply haven’t bothered to make that interface better.
And it’ll never happen, not officially. 5.4 did add the option to use the albedo texture’s alpha for roughness, which is nice, and done for the same reason why it was in the metallic / specular alpha to begin with. Personally I’m surprised they didn’t force the AO and Height textures into a single texture too.
Each additional texture read you add to a shader slows it down a little, and there’s a limit to the number of textures a shader can read. The maxed out Standard shader already comes close to hitting that number and on lower end platforms features were cut explicitly because they’d gone over the limit.
The alpha channel is also a higher image than the RGB in a DXT5 texture.
A plausibly “better” solution, and one that Alloy uses, is to use an asset generation tool within Unity to merge textures together. Unity could conceivably do this for the Standard shader, but again this is more an issue with Gimp being terrible with alpha channel manipulation and user education than something that needs to be fixed on their side. Alloy’s method also has some possible issues with asset reuse causing memory usage bloat.
Unity should just expose a channel picker on texture inputs and then swizzle appropriately in the compiled shader. That’s much less workflow intrusive (and the last thing we need is another half-baked system tacked on).
People are already complaining about running out of keywords, and how much space the standard shader uses in a project . (It can use almost 400 megs by itself!) Adding more options, especially an open ended swizzle option which could add several million variants isn’t a good solution for something that can be fixed trivially in the content, or by writing your own Surface shaders.
