...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. 

Speaking of editors, I'd like to see JACK being improved. It's sad that its author seems to be very averse to criticism, because JACK is a great editor and could become even better. Now it seems to be discontinued.

I don't understand why XaeroX overreacts when some people talk to him. I don't remember anyone attacking him anywhere. 

But ya I agree. I use JACK all the time. 

If you happen to read this, and who knows if you will --

I want to apologize for being an angry beer-drinking guy.

I had a super-frustrating day coding with several layers of unwanted bad news getting in the way of my ideas.

My brilliant thought was "Fuck it, let's get super-smashed, I'm so sick of winter -- let's go!".

I'm quite embarrassed by the idiocy I did. Even more comical, I thought I was thinking.

Anyway, the important part -- you acted with class instead of telling me where to go --- which you probably should have. 

No apology needed as it was pretty hilarious. Welcome back after your hangover :) 

I hope it was hilarious, but obv that is not how I feel about it.

The crazy thing, haha -- my hangover was zero.

My first thoughts when I woke: Wait? WTF? I feel so relaxed. Why don't I have a level 25 hangover? I drank enough to kill small mammals. Maybe I instinctually drank tons of water, but hell if I know.

My second thought when I woke: "Fuck!!! I posted @ func. God dammit. I know not to drunk post. FUCK!!!!!!!" 

It's Spud. 

In retrospect Snug is a much snazzier sounding handle, though.

@Baker: Don't sweat it. 

 

In 2018, I want to see at least one map easter egg about drunk Baker.