yea I am.
And putting a light in the map fixed it.
I just wasted hours waving my fist at the sun, wondering wtf was going on lol. 

Awesome! Happy the tool could help! 

I'm having no luck when googling for a solution to this:

I've got a folder with several images in 32-bit color PNG format, to turn into textures. Batch converting them into TGAs isn't a problem, but I'm finding no way to automate the process of converting each TGA image into a MIP texture and packing the resulting MIP files into a WAD file. Fimg helps a lot when it comes to individual textures, but it doesn't perform batch operations and has a few usability quirks that doesn't make things easier when creating dozens of textures.

Is there no tool for this? 

No idea about a batch tool (Wally is supposed to do that but it doesn't seem to work), but you'd better convert your images to 8-bit indexed to Quake palette before mipping or your submips can suffer some color corruption. It happened to me when working on my SinCity wad. 

http://www.moddb.com/groups/quakedb/downloads/texture2quake

Would something like that help at all? And I'm sure you are familiar with texmex / wally. 

I've had some success using gfxgale and xnconvert

I know the GIMP has a scriptable plugin for batch stuff too. 

My little compiler is almost done.

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

You are now able to create and load configs that will save the values you set for qbsp, vis, and light.

Simply Extract the zip into a folder called "Qompiler". Put any .maps you wish to compile in the Qompiler folder and double click Qompiler.bat. 

foogs: Holy crap, texture2quake seems exactly like what I need.
I had actually forgotten about TexMex and Wally...

Mugwump: Corrupted submips aren't a problem for my specific case. Retroquad recreates all submips, and my need for WADs is mostly for map editor support, because the game itself is going to use external textures. 

Hi all,

For some reasons I'd like to convert a bsp file into map file. Is there any tool being able to do that ?

Thanks a lot in advance

JPL 

 

 

Thanks

/me gonna check this, and re-post if not working ;) 

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.