I just made a quick verification in Gotshun's new map and it would appear that these overbrights are caused by whacked out RGB values. Run the map in DP with RTworld on (you might need to adjust the lightmaps setting) and type r_editlights 1 in the console. You'll be able to see each light entity. You can select one by pointing the crosshair towards it and read its info in the upper right corner of the screen. Check normal-looking lights, they have relatively low color values like 1.54 1.35 1.19, for example. But the overbright ones are ramped up to 2 or 3 digits before the decimal point. 

That may explain why my retrojam did not have too much issue with RTlights considering I did not use colored lights at all.

I'll definitely make an attempt to compensate but no promises ;)

Thanks for looking. 

I was playing Gotshun's (again!) "lost" levels (the secret level of episode 1, to be specific) when I encountered another cause for overbrights: several spotlights concentrated in a small corridor with normal RGB values but a high radius (350).

Thank YOU for willing to make your maps playable with RT lighting. 

Is there a specific light setting that causes overbrights?

Overbrights are not a bug that is "caused" by any setting. It is a feature of the original WinQuake that was restored in FitzQuake.

https://www.quaddicted.com/engines/software_vs_glquake#overbright_lighting 

Yes, but we're talking about extreme overbrights here, that drown the surfaces in light to the point of annihilating details and even colors of the textures. I'm on my phone right now so I can't post a screenshot to show you what I mean. 

The only way maps will look good when run under RTLights is if mappers restrict themselves to the subset of light features understood by both the classic light.exe and RTLights, and test maps with both baked lighting and RTLights.

If I understand right, Darkplaces parses the light entities out of the bsp, ignores the lightmap baked by light.exe entirely, and then renders the lights at runtime, so you can get sharp, high resolution shadows (and shadows from moving objects) 

And it allows for overbright areas. 

@ericw
if someone provides an foo.rtlights file to override the mapper's lights then the mapper is free to ignore rtlights in their map. they can then provide that extra file if they care (which of course is extra work for an engine other than their beloved quakespasm, using tools that are poorly integrated and rather clunky).
and if they don't then yes, people who insist on using rtlights will get shitty lighting.
no bouncy light so it'll have dark corners. no ambient occlusion. etc. it'll probably look terrible. on the plus side, the parts that are still lit will look a little bumpier. because that's what matters, right?... *cough*
(rtlightless-bumps is what the .lux files thing was meant to be a solution for, though for DP they have to be renamed to .dlit or something, with these there shouldn't be quite the same 'need' for rtlights)

@mugwump
overbrights are a specific term around here that describes how the lightmap stores up to a logical cap of 2 rather than 1. what you're trying to describe would be better referred to as over-saturation.

realtime lighting has no such cap, which means it is MUCH easier to oversaturate thanks to each light's contribution being additive.
this can happen from either scaling a single light's colour multipliers up, or just placing a hundred lights in a smallish area, which happens a lot if a mapper wants to avoid dark corners.
Ultimately if a map doesn't have lights placed with consideration for rtlights then its just going to look bad, and you're probably better off without... its just a shame that its such a pain to reconfigure that stuff on a per-map basis. Sadly the dice have already been rolled in that regard. 

Ah thanks for explaining it so well Spike. I knew the actual overbright was not the correct term but couldn't think of anything else to call it. Over-saturation is definitely what we are discussing here.

It basically looks like how I thought it would go...probably not going to happen from me. :) 

I have been wondering, is there any tutorials or guides how to make 3d geometry, topology, architecture in Quake.. that works also in Darkplaces. Is there some principles or important facts about making rooms and such I have to keep in mind?

Does every vertex point needs to be connected to an another vertex point or what is causing these weird "I didn't know there was a brush and simple ignores drawing them". Time to time it works flawlessly and I don't experience any rendering issues, but sometimes it is something I can't even solve, even if I remake the whole area. I try to look everything in a vertex mode and spot every red triangles and try to do something to fix those spots.. but what am I exactly looking for. What is the actual core of my problems, that is something I would like to know.

In sake of not spending too much time fixing things afterwards, I want make maps that works right away. Simple saying don't do complex geometry doesn't mean anything, unless it is explained what is complex and what is not but still looks complex. Since people seems to make "complex looking" geometry, but that is not called complex? Is anyone else having problems with Darkplaces in general, so is the problem in our maps only or just in Darkplaces. 

What you're describing sound like something that shouldn't be happening at all. 

Same thing happened in my jam 8, and I'm sure I made it really poorly or something. I thought this one was much cleaner when it comes to placing brushes etc. But Still there was moments when I saw some faces disappearing, when looking from different angle or staying in different position.

This time I didn't got any portal errors, but I'm still having these weird issues.

https://drive.google.com/file/d/0BwxYkKdSD855NkxXZGY3SjhMN2c/view?usp=sharing 

What you are experiencing is the Darkplaces lightmap scaling bug that occurs when any one textured surface in your map has a scale other than 1.00 in either x or y. Darkplaces goofs up the lightmap in this case.

See here: http://celephais.net/board/view_thread.php?id=61211

Post number 466 is where it starts then ericw responds with a download.

This bug however should be fixed in ericw's tools after version 0.15.5. 

Does it normally take very long time to calculate "full vis"? I use -Level4 and no -fast.. should should I use them both?

Yes, I'm using ericW tools* 

If VIS takes extremely long, it means you have some leaks or weird geometry. 

Faces disappearing still sounds like the r_useportalculling 1 bug. Any DP user feel like reporting that? 

If map is boxed with skyboxes, can there really be leaks at all? I understand if it is not, then it is possible that one corner might not be connected correctly.. using developer 1 in console doesn't give me any errors about leaks.. is there different commands to find those if there is any? 

None of them are working for what I want to decompile...

Igot nothing but an error message claiming it has a problem and that Windows will find a solution.. and that the program has to stop... my ass...

Anyone already tried such tool ? Any idea of what could be the cause ? Note that I tested that with simple maps, and it didn't fail, so it may come from the map I'd like to decompile... :( 

Quake is happiest with rooms and corridors. If you have large open areas vis can take a while. 

I'm bizzy right now with an old map fron the Startrek Quake mod I recompiled it with winqbsp.
I end up with a load of useless poly's, but I can make a decent map of it by extruding the usefull ones.

I use winqbsp a lot for maps, it needs a bit tweaking to work well, but mostly lead to an effective result.

@JPL: - What goes wrong when you use winqbsp?
You can lead the map to convert, extract and script. Using convert brings up a map file, or breaks when the map has to complex geometrie.
I hardly had any case that it didn't work, only when tha author had scrambled the file.

Case is I still work with winXp. 

What Rick said.
...and maybe don't do a box around the map. It will VIS all geometry inside, extremely increasing VIS time. Just place brushes like you'll do with normal sky. Skybox should work just fine. 

Thats horribly wrong, bad practice and lazy too. 

Ahem! Never said I would let it be boxed forever* I was more interested of these weird not drawing faces etc. I started layouting from the scratch, since I think it has something to do with how I made the castle's main hall area. BTW mfx how is your super professional non-lazy map project coming along. 

i dont care about you. 

It was sarcasm, and you don't need to like me.