anisotropic correlation length and update on surface roughness parameter documentation

[LudwigFriedmann]

Original author: @hschoen

Instead of the surface roughness parameter correlation_length use the two parameters surface_correlation_length_axis1 and surface_correlation_length_axis2 accounting for anisotropic roughness:

old "surface_roughness": { "surface_height_rms": 50, "surface_correlation_length": 438 },

new "surface_roughness": { "surface_height_rms": 50e-6, "surface_correlation_length_axis1": 438e-6 "surface_correlation_length_axis2": 284e-6 },

Documentation for surfaceroughness: -- surface_height_rms: the root-mean-square value of the 3D surface height profile in [m]. If the 3D surface profile is not available the mean value of the surface profile along two orthogonal axes can be taken as a best guess. -- surface_correlation_length_axis1: length in [m] at which the normalized auto-correlation function in axis1-direction equals to 1/e (~37%) -- surface_correlation_length_axis2: length in [m] at which the normalized auto-correlation function in axis2-direction equals to 1/e (~37%)

In case the surface roughness is isotropic, identical values can be given for axis1 and axis2 values (alternatively surface_correlation_lengthaxis2 is set to NaN). In order to apply anisotropy the axis1-(unit-)vector must be defined (in the object geometry) for each (anisotropic) polygon of the mesh. To align textures on a mesh, an u- and v-vector is defined in a geometry file. We propose to use these vectors to define axis1 and axis2. In order to obtain the roughness for an incidence plane that does neither contain the axis1- nor the axis2-vector, a linear combination of axis1 and *axis2 correlation length must be used.

[LudwigFriedmann]

Hi @hschoen , thanks for your proposal. In the material specification, the anisotropic roughness would be easy to implement. However, it's likely that texture coordinates in existing 3D models are not oriented according to the anisotropy. I also consider a polygon-specific mapping to be very time-consuming. is there perhaps a more generic approach for specifying the axes? Or would the linear combination be the standard case and only specially prepared models would correctly reproduce the anisotropy?

[LudwigFriedmann]

Original author: @hschoen

@LudwigFriedmann, I am not an expert on 3D-models so I cannot judge what the best way is to define anisotropy axes. However, for the sake of generality it should be possible to define this for every polygon of the mesh. Luckily, for OpenMATERIAL we do not need to solve this problem, but for an actual application this must finally be clarified.

[LudwigFriedmann]

Hi @hschoen, as discussed, I'd subdivide the problem:

Anisotropic material parameters can be defined in material specifications (as described). Local coordinate frames in which such parameters are specified have to be defined in the corresponding 3D models. A scalable approach requires that the latter can be integrated into common modelling processes and that existing 3D models can be retro-fitted.

I'd recommend to have a look at texture-based approaches in this case. Like the additional information used to describe PBR materials, the orientation of local coordinate frames could be stored in textures. Such textures could be created within common modeling workflows. Even though existing exporters would not yet take them into account, they could be manually added to the 3D models later.

What do you think of creating a simple example, such as a cube featuring a texture specifying local material anisotropy coordinates, as proof-of-concept?

[LudwigFriedmann]

Original author: @hschoen

@LudwigFriedmann , I agree that defining an anisotropy texture should be a good way to specify anisotropy. Like as in a displacement map a greyscale should indicate the rotation angle of the major anisotropy axis relative to a reference direction. The direction of the minor anisotropy axis is then obtained by rotating the major axis within the polygon plane by 90 deg counter-clockwise: