You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would alphatest transparency for brush textures a feature that is within the scope of this source port? Currently the only way in YQ2 to have a texel be fully transparent is to flag a texture as TRANS33 or TRANS66, which results in the rest of the texture being translucent. Supporting an alphatest surface flag would solve this, while also making the given surface cheaper to render (no need for translucency sorting).
KMQuake2 and Quake2Pro use the custom 0x02000000 surface flag to denote a texture that should be alphatested. This ensures that existing textures created for Vanilla Quake II maps aren't improperly rendered, while adding support for exisiting textures designed for the aforementioned source ports.
Alphatesting works well for stuff like grates, fences, and foliage, and I think using the surface flag from KMQuake2 would avoid breaking vanilla engine stuff.
Implementation
Detecting which texels are transparent differs slightly between paletted and true color images.
8-bit textures (WAL and M8) detect use the same method as Half-Life and most Quake 1 source ports: index 255 is transparent, whereas all other texels are opaque.
32-bit textures (TGA and PNG) use the alpha channel. Any texels with less than 127 alpha are transparent, whereas texels with greater than or exactly 127 alpha are opaque. This also should "just work" for 8-bit PNGs, looking at the code used to load them.
In theory, SURF_ALPHATEST should be able to be combined with SURF_TRANS33 or SURF_TRANS66, doing an alpha clip in addition to the regular translucency.
The text was updated successfully, but these errors were encountered:
Blurb
Would alphatest transparency for brush textures a feature that is within the scope of this source port? Currently the only way in YQ2 to have a texel be fully transparent is to flag a texture as TRANS33 or TRANS66, which results in the rest of the texture being translucent. Supporting an alphatest surface flag would solve this, while also making the given surface cheaper to render (no need for translucency sorting).
Quake2Max and FTEQW treat having both TRANS33 and TRANS66 enabled as "TRANS99", denoting an alphatested texture. While convenient for mappers, this breaks many legacy textures that were improperly flagged.
KMQuake2 and Quake2Pro use the custom
0x02000000
surface flag to denote a texture that should be alphatested. This ensures that existing textures created for Vanilla Quake II maps aren't improperly rendered, while adding support for exisiting textures designed for the aforementioned source ports.Alphatesting works well for stuff like grates, fences, and foliage, and I think using the surface flag from KMQuake2 would avoid breaking vanilla engine stuff.
Implementation
Detecting which texels are transparent differs slightly between paletted and true color images.
In theory, SURF_ALPHATEST should be able to be combined with SURF_TRANS33 or SURF_TRANS66, doing an alpha clip in addition to the regular translucency.
The text was updated successfully, but these errors were encountered: