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. 

Unless it's a coagula map then boxing it up is fine, but yes. Ahh many a day spent plugging up leaks to be saved by the box only to lose many more days waiting for compile time. Good times. 

Y'all need to put some elbow grease into it. Don't build leaky shit and consider having the patience to fix it if you do. Maybe I'm just not architecturally adventurous enough, but I rarely get leaks in what I build because I pay attention as I go. And when I finish working on an area, I seal up the loose ends and find all the little nooks and crannies and plug them up.
Much, much better than waiting 'till the whole map's done. And not that hard to do! 

Thanks Spike for the detailed explanation and the vocabulary correction. 

The thing is simple. I start playtesting right away. I am precise when it comes to finishing up areas, like you all what you would expext, sometimes I seal them right away and sometimes not, because I focus on gameplay and mood. Since I don't know what works and what not if I don't test it first.

If you are familiar with Unity/Unreal level design, you most likely do the same practice and it is the right way to it. So you ask why skyboxes? I don't seem to need them anymore it seems, but back then some older versions of those engines didn't liked to draw void and made testing out barebone layouts frustrating to look at plus it gave a lot of errors.

Now that I am more familiar with mapping, I can plan ahead a lot more, but I am not genious if you think I can create something just purely thinking about it and that works right away with testing. So sorry if I triggered mfx this time, but I will not change the way I test out things, since it is faster and wiser in the end. Only thing is, I need to be even more precise. 

This tool will batch-convert any PNG files in the current working dir to the Quake color palette and create a WAD2 file containing all converted textures.

https://github.com/maikmerten/QuakeTextureTool 

 

For some reasons I lost the source file of one of my map, hence I'd like to recover the map file by decompiling the bsp file.

I tried WinBspC 1.4, and it failed. It is working with some other map, but no with the one I am trying to recover.

So even though I am on Win7, I set executable properties to execute the file as in winXP (one of the possible options in the properties of any executable file), so that is not the problem.

I am just wondering whether the bsp file has to much complex geometry for the tool, and in this case what are the options to recover.
Is there any other available tool with better capabilities, etc.. ? 

Try and older version maybe. :shrug:

https://www.quaddicted.com/files/tools/winbspc12.zip

V1.2 is on Quaddicted.

Open up WinBSPC and go to Help > Help.

Read through the Help section. Namely Section 1. I believe No CSG would help if the issue is complex geometry.