The change in the amount of bits used for transparency will break backward compatibility.
So files created in 2.93 using this setting will not be able to be converted properly to 3.0

I think we need to fix that.

In D11308#300633, @Sebastian Parborg (zeddb) wrote:

The change in the amount of bits used for transparency will break backward compatibility.
So files created in 2.93 using this setting will not be able to be converted properly to 3.0

I think we need to fix that.

transparency bits and occlusion bits are stored in different variables in struct/dna, mat->lineart.transparency_mask and mat->lineart.occlusion_effectiveness, so it will not affect loading. I shifted 2 bits when loading the variable into line art. And if we are to do versioning code, that higher 2 bits in transparency_mask is gonna be lost anyway, and lower 6 bits are preserved as-is. So by doing this we automatically made it (as much) compatible with old files.

In D11308#300842, @YimingWu (NicksBest) wrote:

transparency bits and occlusion bits are stored in different variables in struct/dna, mat->lineart.transparency_mask and mat->lineart.occlusion_effectiveness, so it will not affect loading. I shifted 2 bits when loading the variable into line art. And if we are to do versioning code, that higher 2 bits in transparency_mask is gonna be lost anyway, and lower 6 bits are preserved as-is. So by doing this we automatically made it (as much) compatible with old files.

The shifting seems needlessly complex and it will still break older files without anyway to recover if the material was using the upper bit range for transparency masks.

I don't think this solution is good enough.

I don't really see the point as you already added a new occlusion_effectiveness parameter either way.

In D11308#300954, @Sebastian Parborg (zeddb) wrote:

In D11308#300842, @YimingWu (NicksBest) wrote:

transparency bits and occlusion bits are stored in different variables in struct/dna, mat->lineart.transparency_mask and mat->lineart.occlusion_effectiveness, so it will not affect loading. I shifted 2 bits when loading the variable into line art. And if we are to do versioning code, that higher 2 bits in transparency_mask is gonna be lost anyway, and lower 6 bits are preserved as-is. So by doing this we automatically made it (as much) compatible with old files.

The shifting seems needlessly complex and it will still break older files without anyway to recover if the material was using the upper bit range for transparency masks.

I don't think this solution is good enough.

I don't really see the point as you already added a new occlusion_effectiveness parameter either way.

The entire thing about this is to save a byte in the face data structure as we have to load all triangles, this do save memory.

(Maybe 1 byte don't really mean _that_ much? How to you think?)

Update on the mask bit UI thing:

Me and @Sebastian Parborg (zeddb) discussed about whether we should change the material bit design in Friday. After some experiment with some situations, I found out that we still can't use "automatic implicit assigning" of material transparency mask bits, because in the manual mask bit design, you can have, say, 10 glass materials at the same time and set their mask bits all to bit 1, and they act as a same filter group, and then you want to introduce a second kind of filter with bit 2, and do a bit 1&2 operation, this method will work, but if we use automatic assigning, line art modifier is not gonna know that you want material 1-10 to have the same mask bits, and will also run out of the 8 bits before it get through the list.

A simple example of this would be:

• I have multiple soldier characters with helmet glasses standing behind of some transparent boards, and their visor mesh materials are different, but I want the line art strokes to be filtered together (in this case it's by using visor_bit & board_bit). If use auto assign, we will have a much harder time figuring out the and/or logic behind this.

However, naming each bits for usability is a reasonable suggestion, I suggest adding this naming in Scene, but it's looking a little bit weird as the data there isn't doing anything but just to store a name. I don't want to put the naming in local bGPData because there might be multiple gp objects in the scene for line art, we want the naming be available to all line art modifiers.

I'll also make the transparency bits back to 8 bits and use another variable for occlusion effectiveness, it's just 1MB per 1M triangle, so not a big deal there.

Seems like the hard limit for occlusion effectiveness is still 3.
I can't change it to anything higher in the UI at least.

Also the checkbox to activate it is grayed out until it is checked.
Only the number input field should be grayed out.