News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Mugwump 
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) 
Yes 
And it allows for overbright areas. 
Rtlights 
@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. 
Over-Whatever 
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. :) 
Help For Mapping In General? 
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. 
Show Pictures Of What You're Doing And What's Not Working. 
What you're describing sound like something that shouldn't be happening at all. 
Will This Help? 
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 
Darkplaces Lightmap Bug 
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. 
Full Vis? -Level4 -fast 
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? 
Khreathor@ 
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? 
Bsp2map / WinBSPC 
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... :( 
Newhouse 
Quake is happiest with rooms and corridors. If you have large open areas vis can take a while. 
Jpl 
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. 
NewHouse 
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. 
Do Not Just Box Your Maps. 
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. 
Box Along 
i dont care about you. 
@mfx 
It was sarcasm, and you don't need to like me. 
@mfx 
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! 
#17617 
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. 
Quake Texture Tool Works Great! 
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 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.