What is the purpose of a texture with the prefix ~, by the way? Created 4 months ago2020-02-11 02:04:10 UTC by MrMystery MrMystery

Created 4 months ago2020-02-11 02:04:10 UTC by MrMystery MrMystery

Posted 4 months ago2020-02-11 02:04:10 UTC Post #343734
If there's any.

MrMystery MrMysteryBanned
Posted 4 months ago2020-02-11 07:29:32 UTC Post #343735
If I recall correctly, it means it's a light-emitting texture. They don't work out of the box though. Gotta define their light values inside lights.rad.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-02-11 08:37:47 UTC Post #343736
I think its mostly used for textures that came with the mod/game to separate them from normal textures. You can define your own texture lights by using lights.rad or even better by making a point entity info_texlights and entering the info there, having "~" before the name is not required for this to work.

rufee rufeeSledge fanboy
Posted 4 months ago2020-02-11 10:01:10 UTC Post #343737
I wouldn't be too surprised if it was originally intended to denote light-emitting textures but was changed later to being specified in lights.rad. By that point, why change the texture names?
Jessie JessieTrans Rights <3
Posted 4 months ago2020-02-11 12:55:38 UTC Post #343738
It also makes it easy to filter for light textures, even if you do have to make sure to add them to lights.rad or info_texlights
Posted 4 months ago2020-02-11 21:57:47 UTC Post #343740
I beg to differ with the tilde marking light emitting textures. It appears on a number of textures that would never emit light, including the off variants of lights, as well as generic textures like computer side panels and such. Certainly not a bad idea to mark light emitting textures with a tilde though, assuming you don't just call them "light" :P
UrbaNebula UrbaNebulaGoldSourcerer
Posted 4 months ago2020-02-11 23:59:40 UTC Post #343741
Yeah, maybe it was just a marker used by the development team of Quake and HL :P
MrMystery MrMysteryBanned
Posted 4 months ago2020-02-12 01:28:23 UTC Post #343742
They were textures that were meant to glow. The last x amount of colors in the palette would be fullbright so even in a dark area, you'd be able to see them. The feature was only partially implemented before being canned. You can see it in it's working state in the leaked alpha but only in software mode.
Suparsonik SuparsonikI'm going off the edge to meet my maker.
Posted 4 months ago2020-02-15 05:40:25 UTC Post #343746
The last 32 colours - did the Quake engine use the ~ prefix or something else?
Posted 4 months ago2020-02-15 17:04:20 UTC Post #343748
From my experience with the Quake engine, if the colours were from the fullbright range, they would render as such, no matter the prefix.
I got some Quake WADs, and none of them have ~prefixed textures, so.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-02-15 17:44:16 UTC Post #343749
In Quake, the last 32 colors in the palette would always be rendered as fullbright, but only in the software renderer. I guess Valve were originally going to carry this over, but decided not to since the game has hardware rendering support, and surfaces are lit through lights.rad anyway. Interestingly enough, it seems as though some of the textures prefixed with ~ has their colors in the last 32 slots of the color palette, similar to were the fullbrights were in Quake.
Dr. Orange Dr. OrangeSource good.
Posted 4 months ago2020-02-16 07:01:34 UTC Post #343750
Hm, I wonder why it was software only.
Posted 4 months ago2020-02-16 09:21:20 UTC Post #343753
"Hm, I wonder why it was software only."
Because of graphics programming.
When you write your own software renderer, you have complete control over how things render. When you use an API like OpenGL, 1.1 at the time, you get a lot of features, however at the same time, you can't get the easy per-pixel control as you'd have with a software renderer. (it gets a bit complicated)

One would either have to write a pixel shader (which wasn't available back then), or maybe modify the current texture for the current wpoly, before rendering it.

I'm guessing the algorithm went something like this for each pixel in the texture:
if ( texturePalette < 224 )
   color = textureColor * lightmap;
   color = textureColor;
This is the kind of 'control' that I'm talking about. We're basically modifying the texture before uploading it to draw the current wpoly. But, this isn't my area yet and I'm likely incorrect.

Modern Quake sourceports like Quakespasm and Mark V (the ones I've used) support this feature in OpenGL mode, so it's probably not that much of a trouble. :)
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 months ago2020-02-16 11:04:20 UTC Post #343754
Quake's software rendering is actually quite interesting when it comes to lighting. The original software renderer could only render 256 colors in total. That's not 256 colors per texture, or 256 colors * lightmap, that's 256 colors in total on screen. These 256 colors were defined in a single palette that was also used for every texture in the game. Since only 256 colors could be used, they used a precalculated lightmap where each palette index were remapped to another palette index based on its light level. Fullbrights were implemented in a really simple way really; the remapped palette indexes for the last 32 colors of the palette would simply remap to its original palette index no matter the light level. This is why the later released OpenGL renderer doesn't have fullbrights. It doesn't use this remapping since they could just straight up multiply the lightmap with the textures without having to stay to the original 256 color palette.
Dr. Orange Dr. OrangeSource good.
You must be logged in to post a response.