Ok, since metl mentioned it, the sparkly pixel movement phenomena is temporal aliasing. I want temporal antialiasing in Quake. 

 

GL_NEAREST_MIPMAP_LINEAR is the best compromise IMO. Sparkles are caused more by not using mipmaps than by using nearest filtering, and linear sampling between miplevels eases miplevel transition artefacts. The other improvement is to use screen-space derivitaves from unwarped texcoords when sampling warped textures, otherwise they shift between miplevels as they warp. One of those things you normally don't notice until it's pointed out to you, then you can't stop noticing it. 

yeah my settings are GL_NEAREST_MIPMAP_LINEAR + anisotropic set to the max. The thing i don't like about mipmapping in hardware rendering is how floors (and other edge-on polygons) blur into a solid color, and anisotropic reduces that problem quite a bit. 

Agreed, anisotropic is essential. Different people are different, so I tend to find anything beyond 4x is not that big a deal, but I won't go below 4x. 

It would be nice if there was a way to detect the edge of a face that also corresponds to the edge of a texture and clamp the texture so that it doesn't bleed the color from the opposite side of the texture over. 

I want to see all of the models from Banjo Kazooie converted to mdl, with all of the animations kept intact. The Quake marine's model should be altered to have a backpack on his back that Kazooie occasionally pops out of. Also, the Quake marine can now double jump, and on the second jump the player can see Kazooie pop out of the backpack and flap her wings. Also, I would like to see a map that completely re-creates Gruntilda's lair and... Ahh f*ck it, I'm just going to go play Banjo Kazooie...

Seriously, I would love to see some kind of volumetric fog implementation similar to what is seen in Quake 3. 

Centerprint with constant cheesey rhymes 

Ranger will end up slobbering,
after the Shambler gives him a clobbering.

And so forth. 

...given how well normal fog can be used.

Also pretty sure the edges of objects have the same definition i.e. a straight fucking line, regardless of what texture mode you're in. Anyway, you're all wrong, I've been playing with GL since it first came out and fuck everything else. 

Just adopt Q3 BSP already if you want stuff like volumetric fog. :) 

Another thing that no current Quake engine does, AFAIK, is gamma-correct mip-mapping: http://filmicworlds.com/blog/gamma-and-mipmapping/ 

As you should know by now, the value 187 is actually half-way between o and 255. 

 

 

Wrong. The problem is that that article was very poorly written. Here's the actual equation for gamma-correct gray:

((255^2,2)÷2)^(1÷2,2)=186,083713

Most of the gamma correction articles on the web are poorly written. 

in terms of photon counts, that's entirely correct.
so if you want correct lighting, then you need a pipeline that is actually aware of srgb (eg: vid_srgb 2 - note that you'll need to reload all the textures too).

using hardware srgb extensions to basically disable srgb (yes, backwards, the extensions are all a pain to read, and with drivers giving the wrong results too) gives you brighter darks and also resists oversaturation much better (which makes rtlights+specular much more tollerable).
but yeah, dark areas being brighter kinda hurts the whole quake ambience, and it draws more attention to how rtlights have sudden cutoffs instead of fading to infinity. I'm sure deathmatch players would love it though.

also reduces banding with eg r_lightmap 1.

and regarding gamma-incorrect mipmapping - textures that get darker with distance is a feature, not a bug! :P
(or use dds files that were generated with a proper tool) 

Er wait the thread said "Realistically" ha ha. Inspiring to see all the ideas people have.

P.S. to Qmaster: Will email you soon (i.e. this month). 

That's interesting. I probably should read up on that.

What - Realistically - Do You Want To See In Quake In 2018??

Realtime lightmap generation for in-editor preview. 

+1 editor lighting preview. 

Seconding real-time lighting preview. Lighting a map is one of the worst workflows in quake level design, due to the slow iteration cycle.

When I think about this feature, most lighting edits are very localized (adding/moving/deleting a light, editing radius/brightness/falloff on a light.) An individual light usually touches only a small portion of the bsp. If you start with a bsp with all lighting calculated, you should be able to mark and relight only the small number of affected surfaces, after each edit to a light entity. Then you could get into a flow where you just go in and make a bunch of tweaks, seeing the results almost instantly, until you are happy, and then save the changes back to the .map file.

The hard part I think is that such a tool requires a bsp renderer, a map editor, and a lightmap generator, which are traditionally 3 different programs and everyone wants to use their personal favorite of all 3. Not sure where this new functionality could/should be added. 

What editors support region compiling?

In some versions of radiant, you just drag a brush out to define a region to compile and the editor then only sends that small subset of the map to the compiler, automatically boxed in, with an info_player_start added where the camera was.

That's a pretty straightforward thing to add to an editor, and would massively help you do quick iterations when mucking around with localised lighting. 

The best approach would be to edit the light entities in the engine itself, save a diff file containing the modified light entities, and make the engine call the external light utility to recompile the lights.

Upon parsing the diff, the light/BSP compiler would check which lights were removed/added/modified, and relight only the surfaces affected by them.

However, Quake's lightmap format still has some annoying limitations that restricts the productivity potential of such an approach. Dirtmaps, sunlights and bounce lighting would likely require the.whole lighting to be recompiled anyway. And the lightmap doesn't keep track of which light entities affected each surface. 

 

He's right I've used it in one of the Radiant's before. Would be a great addition to TB.