Not even sure how to explain this weirdness. I have this area on my subtool that won't take on the madcap material. I can sculpt across the 2 areas, but this is what I'm looking at. Help.
It looks like you have accidentally painted the matcap material while you were sculpting.
What I usually do is make sure only 'M' is toggled on and then switch my matcap to the Flat Color. Then go to the Color drop down menu and hit 'FillObject'.
That should reset the subtool to not contain any painted on matcap. And you should be able to change matcaps without having that patch on his chest.
I wonder why wouldn't Pixologic just make it spec color channel in usual PBR way, exportable to textures . or maybe just roughness. Wouldn't it be much more helpful instead of this Material channel nobody really use
I wonder why wouldn't Pixologic just make it spec color channel in usual PBR way, exportable to textures . or maybe just roughness. Wouldn't it be much more helpful instead of this Material channel nobody really use
ZBrush is a 2d painting program at its core, not a 3d environment. Rather than manage an entire 3d scene and all the baggage that comes with one, it instead tries to stick to basic vertex data as much as it can. This means there's no actual lights positioned around the model, and no material shaders as you would normally know them. It doesn't even linearly interpolate vertex normals for smooth shading across the model. The document's pixols really only cares about the sampled depth and color value at any point on the model, and from there it fakes a material by comparing it to a corresponding pixel on a spherical image. This is why the lighting is screen-spaced regardless of how you rotate the model.
The bad news is this means you can't use zbrush to paint multiple channels that feed into fancy real-time PBR shaders shown in a viewport that doesn't even exist. The good news is that it means you don't need an expensive GPU and beast of a computer to use it. ZBrush's approach to handling 3d model data is what allowed it up to smoothly work with tens of millions of vertices at a time, even on basic CPUs from 15+ years ago. Since that is a part of what made them industry standard in the first place, it can be argued that this makes it more useful than something which could potentially require a complete rewrite of the program while also resulting in a severe performance hit to anything above 3 subdivision levels.
Replies
Also for questions like this post here.