Fullbright textures..

[Downsider]

Been messing around with this for a while. I want texture with the prefix "fb_" to be unaffected by the lightmap, but for some reason I can't figure it out.

Hopefully someone else can help me out here :/

No matter what I do, the lightmap either still renders on top of it, or the engine just takes a shit whenever the specific brush enters the player's PVS.

[Spike]

replacement texture names:
mytexture_luma
mytexture_glow
one of them, depends on which engine you're using
some engines will use alphablending, others will use alpha testing. if you want it to look identical in both sorts of engines, use only 0% or 100% alpha, not anything between. Just avoid < 5%.

legacy textures:
the quake engine 'blends' lighting by looking it up in a table - the colormap.
Actually, GL engines don't use the colormap though. Instead most expect the last 32 palette indexes to be fullbright, and the others not (FTE attempts to look at the colormap to see how many were meant to be fullbright). This behaviour matches the output of software, but can fail if you have mods using custom palettes/colormaps. ID's glquake does not support fullbrights at all, thus you need a modified engine to get fullbrights in GL.

[Downsider]

Yeah, mate, I threw this in the Engine Programming subforum because I'd like to add it to my engine, heh.

I've looked through the brush loading code, as well as brush drawing, and I can't really figure this out. For the sake of argument, where would one have to look to add this to an unmodified GLQuake?

[Spike]

you would have to generate new textures.
find the pixels with 224+ values and pass them through unmolested. for everything else, clear out the alpha channel to 0.
then upload those 32bit textures.
the add an extra pass to the entire world where you draw only those fullbright textures, after any lightmapping effects.
on anything with more than 2 tmus you can use register combiners/multitexturing. set up the first three stages to do texture*lightmap+fullbright. and that should work on anything past a geforce2.
But yeah, multitexture isn't required. You can just enable blending and do it as an extra pass. GL is state-based so you'll need to undo state changes in order to fix the rest of the scene again.

Ideally, choose an engine that already has ARB multitexturing implemented and optimised.

[Downsider]

The PSP engine does lighting in a second pass. That's the engine I'm working with. Can't I simply mark certain textures as fullbright and ignore the second pass on them?

glpoly_t surface flags?

[Spike]

probably.
however, consider that that requires the entire texture to be full bright.
consider a dark room... actually, consider any room in quake... it has a light. a nice fullbright light. and the textured fitting around the light is just as bright as the bulb. but the floor right next to it is dark.
perhaps a better example is the fullbright runes on maps like dm4. but hey :)

you'll need to provide some way to tag such a fullbright texture as fullbright. by name would work, I suppose. check the miptex_t's name at load time and set a flag on the surface to skip it when rendering the lighting pass after.

[metlslime]

[Downsider]

Again, lol, this is for the PSP.

I'm really only using this for a strange case in which I need it in order to accomplish a special effect I'm trying to replicate from another game. Honestly, I could even be doing it on the compiler's end and it wouldn't make a difference.

And, well, what I've been doing has been working from the start. I just thought it wasn't fullbright for some reason

[ceriux]

lol downsider you should never doubt yourself , your too good at what you do.

[Downsider]

[ceriux]

[Downsider]

[ceriux]

[Spike]

tor?... though I'm guessing half the entry points are blocked - but maybe not all

[ceriux]

every proxy site iv tried on google has been blocked .