Artifacts when texture loaded via *.mat

[thisnickwasfree]

https://ibb.co/vjM6s6w https://ibb.co/jTP09pD

Look at white artifacts at mobs. They appear when using mat instead mtl. Blending mode does not matter. Link or local file — does not matter too. Both, png and pkm affecte. deffered_lighting set to false. Affected sharp edges and angles, at nearer distance all artifacts disappear.

[Luke100000]

I do not think its a problem with the file format itself, since both do more or less the same thing. The amount of affected values, which can differ, is small, but none of them is known to produce such artifacts. Without further information I can not tell what happens here.

[thisnickwasfree]

What information do you need?

Btw, mat file.

--3DreamEngine material properties file return { { name = "None.002",

    --Shared for all shading
    color = {1.0, 1.0, 1.0, 1.0},  -- color

    emission = {0, 0, 0},     -- emission color, or the multiplier if a texture is present

    roughness = 1.0,               -- roughness if no texture is set
    metallic = 0.0,                -- metallic if no texture is set

    tex_albedo = media.images.spearman01_128,
},

}

[thisnickwasfree]

Interesting… mat with link to pkm — artifacts. mat with link to pkm and mtl with local path to png (without png) — no artifacts. Guess, that's something thumbnail-related…

[Luke100000]

Since I have no clue why this happens I probably need another demo or the project so I can bruteforce my way to the solution. When you load both files you extend them. In the mtl file is therefore a value which fixes the error. Or I'm wrong and there is a problem with texture loading...

By the way, what exactly are pkm files and is there a official documentation? I was scared adding it to the supported files because I have absolutely no idea what it is.

[thisnickwasfree]

I'll make demo a bit later — need to discuss something with 3d-modeller. As for the pkm… It's a file format for etc1/etc2 compression.

https://love2d.org/wiki/CompressedImageFormat

Available since LÖVE 0.10.0 ETC1 The ETC1 format. RGB data at 4 bits per pixel. Suitable for fully opaque images on older Android devices. ETC2rgb The RGB variant of the ETC2 format. RGB data at 4 bits per pixel. Suitable for fully opaque images on newer mobile devices. ETC2rgba The RGBA variant of the ETC2 format. RGBA data at 8 bits per pixel. Recommended for images with varying opacity on newer mobile devices. ETC2rgba1 The RGBA variant of the ETC2 format where pixels are either fully transparent or fully opaque. RGBA data at 4 bits per pixel. EACr The single-channel variant of the EAC format. Stores just the red channel, at 4 bits per pixel. EACrs The signed single-channel variant of the EAC format. Same as above but pixel values in the texture are in the range of [-1, 1] instead of [0, 1] in shaders. EACrg The two-channel variant of the EAC format. Stores red and green channels at 8 bits per pixel. EACrgs The signed two-channel variant of the EAC format.

I use ETC2rgba (in Mali Texture Tool, the converter, it named as RGBA8_ETC2_EAC). Compressed textures are necessary for big projects, using of dds (dxt-compression) is acceptable for desktops, but for Android, for example, etc2 is the only option (well, you can use etc1 or astc, but they are not so good).

[thisnickwasfree]

Demo: https://github.com/thisnickwasfree/3dreamengine_tests commit "artifacts" (well, the only one atm). Look at helm of left spearman, which uses mat with link. The right one uses mtl with path. The obj is the same.

[Luke100000]

Demo: https://github.com/thisnickwasfree/3dreamengine_tests commit "artifacts" (well, the only one atm). Look at helm of left spearman, which uses mat with link. The right one uses mtl with path. The obj is the same.

Thanks a lot, I found the cause: specular should be zero to avoid the error. I'm currently investigating why this happens, looks to me like an error in the maths. In the mtl file, specular is defined with "Ks" (which is 0.0) In the mat file, specular is missing and therefore uses the default 0.5.

EDIT: Found the error too: some incorrect normalization causing errors on sharp edges. Going to be fixed in the next commit.