subsurface_color = base_color? about openpbr HOT 4 CLOSED

I can imagine a possible use case is e.g. dirty skin where this is modelled as SSS/diffuse blended via subsurface_weight. Then it would be less convenient if the base_color map had to have the subsurface_weight blending baked in to account for this, than just feeding in the skin texture and a dirt texture.

This seems less common though than using the same map for both. Ideally it would use the base_color by default but optionally be independent, though this would require adding a checkbox.

from openpbr.

@brechtvl wrote:

I also can imagine a motivation for this, but at the same time I do not remember seeing good examples where someone painted or captured separate texture maps and it was convincingly better. They may well exist, I was mainly wondering if there were known good examples of that.

Perhaps related to this is that only the subsurface weight and radius at the light exit point is taken into account, while if they are zero at the light entry point you probably don't want that color to bleed to other parts of the surface. Separate texture maps could help compensate for this. I had something automatic for this in a point based SSS implementation long ago, but it's difficult with ray tracing and I'm not sure how valid it was.

from openpbr.

@peterkutz wrote:

We had planned to get rid of the distinct subsurface_color and use just base_color, partially because of an implementation quirk, and partially because nearly always the same texture map was connected to both. But maybe it is common to have separate texture maps for these for some users?

Yeah, we had the same question. The main idea was that people might use diffuse and SSS together for skin and might want two different colors. It seems potentially confusing that the base color is shared across diffuse and metal but nothing else.

from openpbr.

This seems like it could be closed, as in practice we are not going to merge the two colors (at least in the near term). Also it seems it's not clear whether doing that would be an improvement necessarily.

from openpbr.