http://www.quaketastic.com/files/tools/Qompiler.7z

You can now choose what compiling tools(QBSP, VIS, LIGHT) you wish to run and these, along with the settings you choose for the tools, will be saved to a config that you can load on the next run.

Still some small hiccups in the script but everything goes fine. Ill spend the next couple days cleaning and reorganizing the structure of the script.

What compilers do you guys use?

Currently its set to run with tyrutil-ercw, but I'd like to put the descriptions/settings for a couple other tools as well.

Thinking of adding a feature to choose where you dump the compiled maps. Definitely want to add one to show the config names in a list. 

that forced me to turn RTworld off - this is becoming a trend among new maps lately

Any suggestion on how you preserve "RT lighting" on DarkPlaces? Is there a specific light setting that causes overbrights? 

Dunno. Even if I have RTworld on without specific .rtlights files, I never encounter this problem with older maps.

Idea: I seem to remember having read that Tyrutils-ericw can generate .rtlights. Since some of you guys already provide .lits with your maps, I guess it wouldn't be too much of a hassle to also provide the .rtlights for us DP enthusiasts. 

If you can do some research/testing on how to provide .rtlights or what makes the overbright issue occur I would have no issue supplying/compensating one with my next release.

My only quibble is that if it turns out RT lights require certain light settings to not be used then I will not include it. 

I'll look into it. Right now I'm focusing on my noir jazzy-industrial theme music for the Map Jam 8 repack, but as soon as I'm done with it I'll try to find some answers. 

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.