bnpr / Malt

Render framework for NPR.
https://malt3d.com
Other
952 stars 75 forks source link

Vcolors Normals Discrepancy (No idea what else to call this) #439

Closed dibli-goost closed 1 year ago

dibli-goost commented 1 year ago

Malt version

Node Groups

Blender version

Blender 3.3

OS

Windows 10

Hardware info

AMD Ryzen Threadripper 1920x 12-Core Processor, 3950 Mhz, 24 Logical Processors | 32GB RAM | Radeon RX 570 Series

Issue description and reproduction steps

In the attached blend file, I have 2 models, both with normals being generated by geometry nodes. The normals are coming from the simplified head meshes which rest beside them. The normals are sent to a vertex color attribute, and sent into malt via a vertex color override.

In the shader, there's a couple of mix nodes which you can use to switch between: Base Normals and Custom Normals, Non Normalized and Normalized Normals, and a slider to turn shading on and off.

Utilizing those nodes, you can compare the differences between the models' vertex colors. As well, you can back out of material preview and check the normals in solid mode, as long as the viewport is set to display attributes. Flipping back and forth, malt seems to be significantly changing the normals on the left model. While the right one stays mostly the same.

Solid mode:

viewport

Material preview:

material preview

When turning on shading, it's much more clear that something drastically wrong is happening here..

shading

This model on the left is the only model that i have that is doing this, the differences between it and the right one topologically shouldn't be contributing to this at all, and the solid mode view seems to be alright. I've deconstructed most of my geonodes set up, I'm pretty confident that the issue here is something to do with Malt.

Attachments

custom normals discrepancy.zip

pragma37 commented 1 year ago

Seems hardware/driver related.
imagen

Edit: Yep, I can reproduce it on my AMD laptop: imagen

pragma37 commented 1 year ago

I found the root cause (setting boolean vector values on AMD seems bugged). As a temp workaround, you can fix it by making sure all your color attributes are of the same type (either color or byte color).

dibli-goost commented 1 year ago

As a temp workaround, you can fix it by making sure all your color attributes are of the same type (either color or byte color).

Quick little question. Which one should I prefer? Like is there a reason to prefer byte color over color? Visually they look the same to me. Only reason I even have multiple types is that some blender add-ons seem to default to one or the other when automatically creating them. 🤔

pragma37 commented 1 year ago

Byte Color is 8 bits per channel, Color is 32.

So Byte Color takes less memory, but the valid range goes from 0 to 1 (0 to 255 internally) and is "compressed" in sRGB space. Color takes more memory, but it can store virtually any value you throw at it.