 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
top - fitz
bottom - almost any other (in that case I used bengt`s) no ID gamma used AFAIK only fitz and DarkPlaces do nice overbright effect (not counting QW engines) In other gl engines the light is like 50% range of what it should be :( thx for comments demos are wellcome Could you use a higher light value (not worldspawn I mean, but individual light ents) but a 'fade distance multiplier' value greater than 1 (i'm using an fgd file with that on worldcrafts 'smart edit' feature, cant remember the actual key name (anyone?)). I believe this would give a brighter inner light, but without the light spreading too far.
Btw. Why is lighting handled differently in Fitzquake (ostensibly also DP) and regular GLQuake-based engines
The original quake (software) engine used overbright lighting, which means the lightmap brightness can go up to 200%. So, light.exe creates BSP files with lightmaps that go up to 200%. In glquake, since it was such a rush-job (I think carmack said he wrote it in a weekend) there is no overbright lighting, so every part of the lightmap that goes above 100% is flattened to equal 100%. This is why glquake looks just fine in darker rooms, but in bright areas the lighting looks very flat. Fitzquake and darkplaces restore the overbright feature of the software renderer, so that lighting hot-spots will actually be as bright as intended. It's always interesting (and devastating) to find out it was no placebo after all. I guess MHQuake uses "proper" lighting too as I always felt that engine to have the best look of the glquake engines.
I've uploaded four FitzQuake 0.80 shots of the classic kjsp1 map. The first set of two shots show the map using original 8-bit textures, lighting and palette with basically no engine configs loaded. The first shot is without overbright lighting (gl_overbright 0) and the 2nd is with it enabled. Gamma is 1 in both cases.
http://user.tninet.se/~xir870k/fitz_orig_ob0.jpg http://user.tninet.se/~xir870k/fitz_orig_ob1.jpg The next set of two shots show the map using filtered tga textures (based off the originals), new lighting and idgamma palette (the latter being irrelevant here due to tgas, of course) with my std configs loaded. Again, the first shot is without overbright lighting and the 2nd is with it enabled. Gamma is 0.65 in both cases. http://user.tninet.se/~xir870k/fitz_tga_ob0.jpg http://user.tninet.se/~xir870k/fitz_tga_ob1.jpg To me this shows terrible lighting saturation in the textures in both sets, which is also the expected result of the "overbright" lighting. The lighting is saturated already in the engine, which means that adjusting the monitor or other external tweaking is useless. Maybe there's something wrong with my graphics card (Geforce3 Ti 200) or setup, but overbright lighting doesn't look very appealing to me. It instead reminds me of using the loudness button on HiFi equipment and claiming that the sound is then "better" The above results are of course not FitzQuake specific; DarkPlaces and WinQuake has the same saturated look. Are you sure about that? I'm not saying you're wrong but I don't recall seeing the original Quake's lighting go beyond 100% on a texture surface. You can't get beyond the fullbright value of the textures, can you?
True, but how to please every engine then, how to do compatiple source lights (delay 2) that still look good?
blame kjsp textures. they looked fucked even in the standard gl quake with the ID gamma
overbright gives you 100% more light range, not just brighter colors or contrast Willem: Sure about what? The shots are representative of how it looks on my system. I'm also not the one claiming that 200% brightness is the "intended" look, but different engines will present different fullbright levels (i.e. having r_fullbright 1). Turning on fullbright in WinQuake is for me abominable to look at, not to mention the pixellation, light banding and other animation/movement distortions.
neg!ke: I've no simple solutions, but I'm very concerned about lighting that ruins textures/skins, being it coloured, overbright or "fullbright pixels". Just like audio, it's essential to keep the signal dynamic range reasonable without any compression artifacts. Getting it right for all preferences or setups is probably impossible. -_-: There's nothing wrong with the kjsp1 textures, in fact they're outstanding. The problem is how to render them without saturation effects that wipe out the details. A badly configured idgamma palette will also cause problems. And I chose this map because it illustrates the effect clearly, but it can be seen in any map to different extents. aguiRe
Sorry, you posted just before I did apparently. I was asking the original guy who said that Quake did overbrightening in software mode. I didn't think it did but I wanted to find out for sure. Sorry for the confusion! willem: yeah, i'm sure about it. Software quake goes up to 200%. The file colormap.lmp is a lookup table of lighting values for each light level and each palette color, and this table is where overbright lighting (and fullbright pixels) are implemented.
Glquake didn't have overbright, but the creators were aware of this so to compensate they capped the top end of the dynamic range instead of making everything half as bright, so that it at least looks pretty much like quake in most cases. aguirre: I agree with you that it looks bad in kjsp1. I disagree that kjsp1 is in any way representative of quake maps in general. Probably, killjoy was using glquake, and wanted to make the level look washed out by bright sunlight, so he made the textures extra bright, and in glquake, it looked fine. Overbright lighting and fullbright pixels are undoubtedly part of quake as id software intended. There is a problem when you get to the era of mappers who thought glquake was the best thing ever, and didn't test their maps in winquake, so they have textures with random fullbright pixels on them, too-bright lighting near skylights, etc. In these cases, the intent of the creator is obviously NOT to have overbright and fullbrights, and luckily those are easily disabled with cvars if they turn out to ruin the level. r_fullbright looks bad in winquake, but of course it's a developer command so it's not that important. Side note: I need to figure out why the tgas look different than the wad textures. Seems like it would have to be a fitzquake bug? this to turn into an argument who's right or wrong, I just wanted to point out that overbright lighting is no cure without shortcomings and to counteract simplified claims like GLQuake looks like "shit" in comparison.
I just used kjsp1 to make the shortcomings obvious, but it can be seen in any map if there are any overbright areas. This is also important; the areas where it's supposed to work, are the same areas where textures might be saturated. You can see this in the shots above; beneath the overbright area, there's a normal wall that looks the same (no saturation) in both cases. Using fullbright in WQ also shows how the textures are saturated where the overbright lighting is applied, so I think it's appropriate. Whether id actually intended to have the overbright lighting or fullbright pixels or were just forced to use these tricks due to technical constraints at the time, probably remains hidden in the past. But by the same logic, one might claim that the light banding or pixellation were intended, too My guess is that they wanted something better, but couldn't do it with reasonable costs or performance by the time of development. Possibly also in an attempt to counteract the then rather frequent complaints about Quake being just "dull brown and green". Why the tgas are more saturated than the 8-bits is probably caused by the total sum of brightening, I've filtered the tgas to be brighter (without saturation in my engines) together with gamma being my normal setting 0.65. This together with overbrights probably becomes too much. Without overbrights, this map looks fabulous with external tgas. The purpose of my two sets was to show that even in the original and default setup, overbrights cause saturation, while it's then worse with my normal setting and configs. This also shows how sensitive the lighting is, even minor changes to engine/driver/monitor settings may tip it over the edge and create horrible distortion. a moderate case:
http://img182.imagevenue.com/img.php?image=22977_overbrightshamb_122_12lo.jpg Not just ikwhite textures. Well I'm glad to hear the tga brightness is becuase you edited them, not becuase fitzquake loads them wrong. :)
As for the rest, it's probably a matter of opinion whether it generally looks good or bad. For me, the higher dynamic range provided by overbright gives more contrast and less flat-looking lighting. The washed-out appearance of brightly lit surfaces is true to my experience in real life, and looks good to me so long as the mapper does a decent job lighting things. (example: the pentagram room in dm3 looks bad, but that is becuase it is badly lit. It also looks bad without overbright.) Well Fitz actually loads many tgas upside down, but I'm sure you already know about that
Grahf: Yes, that's what I was trying to say before, but the issue probably gets worse if you also use idgamma (which I do). The combination is not nice to look at and alias model shading is basically ruined. Again, several engines have this problem. Well Fitz actually loads many tgas upside down, but I'm sure you already know about that
Oh yes, that problem. I actually fixed it recently thanks to browsing your code :) Grahf, that shambler has a 32 bit TGA texture that I made alot darker (+contrast, sharpen, other tweaks) but I can't tell from the shot if you had -exttex enabled?
If you did and it still looks like that then its proven what AguirRe was saying before - there's no way to account for all setups. If not then its because of a loading issue? Otherwise I'd recommend using the external skins, they look better in my opinion. It says dp next to the shot number - you were just making a point?
Not had the morning coffee yet.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |