News | Forum | People | FAQ | Links | Search | Register | Log in
TyrUtils V0.11
TyrUtils v0.11 has been released:

*Support BSP2 format (qbsp requires the "-bsp2" command line option)
*qbsp: Fix animating texture bug when brushes are textured with alt-animations
* qbsp: Fix a crash in tjunc calculations
* qbsp: Exit with error if verticies exceed 65535 (BSP29 limit)
* qbsp: Add experimental "-forcegoodtree" command line option (thanks Rebb)
* vis: reduce "leaf recursion" error to a warning and continue processing

Download from the utils page as usual (Win32 / OSX / source).
First | Previous | Next | Last
Screenshots - 
1x res
https://www.dropbox.com/s/60oyen21bv83nc3/1.png?dl=0
https://www.dropbox.com/s/hdiiyktnsm56e6l/2.png?dl=0

2x res
https://www.dropbox.com/s/rsbvrohtens5ouc/1-2x.png?dl=0
https://www.dropbox.com/s/7eham7t5t8a9j68/2-2x.png?dl=0

16x res
https://www.dropbox.com/s/rtp7cildc0khzp2/1-16x.png?dl=0
https://www.dropbox.com/s/3ckqik3odfx4ko1/2-16x.png?dl=0

textured comparison, 1x res and 16x res

https://www.dropbox.com/s/xpz05jtj2p4dve7/start-1x.png?dl=0
https://www.dropbox.com/s/2pr08ltxp1bq1fs/start-16x.png?dl=0


Takes a fscking long time to compile at 16x res. Looks pretty awesome. File size for .lit2 at 16x res is 7mb, 2 floors were converted to func_detail and are the only areas with the higher lightmap. Took 20 minutes to compile 16x compared to 20 seconds on normal. Normal .lit is 449kb.
This is on my start map for retrojam 3.

I dunno if model lighting works well on 16x (model light is based on the floor luminosity rather than light entity), seems to get light or dark but doesnt always correlate to floor lighting. Probably needs more testing.

I think 2x scale is nice. 4x scale is probably going to be what most people will aim for. 8x at a push. I can't see myself wanting 16x normal lightmap res. 
Hrm 
i think I prefer the blurry lightmaps in those examples... the high res ones just look like crummy doom3 shadows. 
 
You'd likely want to approach lighting differently when at high resolution. Rather than do a single light entity that will cast stark shadows, which is ok when you have blurry lightmaps, you'd want a few slightly separated lights combined so that you get a penumbra effect to the shadows. 
 
thing is that adding more lights increases light time by a lot since each light is traced on every face, regardless of visibility or whatever. :( 
Append 
i think the solution is to scale the antialiasing and the soft effect to now match the new resolution of the lightmap. 
 
Yeah, you're probably right... thought -soft or -extra really affects compile time...

speaking of, ericw warned me this might happen on twitter... here's jam5_scampie with 16x lightmap and no other fancy options

http://scampie.net/etc/ohgosh.jpg

seems we hit some limits here? 
Couple Of Notes 
Thanks for the initial testing!

Careful with -extra/-extra4, they do make the compile roughly 4x/16x longer, and this will stack up with -lightmapscale to give you really long compiles. "-soft" should have much less performance impact, not sure exactly, but it does work against the resolution gain by blurring the lightmaps.

"-lightmapscale 0.25" with no "-extra" should be the same compile time as "-extra4" with no "-lightmapscale", as they both have to compute a 4x res lightmap.

Fifth: I think you found a bug with mdl lighting, and I got a comment from MH about the code being missing for that, so I will look into that.

necros: yeah I agree the 16x does look like a bad stencil shadow. scaling the "soft" effect is a good idea, haven't yet looked into that. 
Also 
Rather than do a single light entity that will cast stark shadows, which is ok when you have blurry lightmaps, you'd want a few slightly separated lights combined so that you get a penumbra effect to the shadows.

There IS a convenience option for this, which I stole from q3map2, setting "_deviance" "8" on a light entity will turn it into an 8-unit radius sphere of lights. Default if you use _deviance is to create 16 lights, but you can customize it with "_samples". This will slow down compiles of course! 
Oh, Sweet! 
Also, everyone disregard that pic I posted... I had forgotten to copy my .lit2 files into the right directory (necros, your compile gui doesn't copy .lit2 files for me you scum!!!!), and had made some out of date .lit files because it seems that when you generate a .lit2 file, no .lit file is created so you get out of sync really easily. 
Lol 
source is here good sir. ;)

but yeah, I should try to get around to that if this is going to become a common lighting thing.

I'm still not convinced 16x is necessary. 2x or 4x with scaled blur effects. Oh and deviance lights, utterly badass. 
Fifth 
Nice thumbnails, asshole. 
Fifth's Textured Shot 
easily prefer the 1x lighting. But yeah could be because lighting method/other cvars unchanged. 
 
Also, everyone disregard that pic I posted... I had forgotten to copy my .lit2 files into the right directory

so post the fixed shot shrimptease 
 
TRIP REPORT ON 16x RESOLUTION AND -EXTRA4 AND -SOFT

After 2.5 hours, a 337mb .lit2 file was made. Quakespasm crashed with AllocBlock: Full even with "-heapsize 655360" 
 
lol... and how many lights and faces were there? :P :P :P 
Yeah 
Sorry about that, the "AllocBlock: full" is when you exceed the hardcoded lightmap limit in QS. Even if it did load, performance would be awful because dynamic lights are all rendered on the CPU. The 8x and 16x options are probably best avoided, or only used very selectively.

jam2_scampie looks pretty nice with "-extra -lmscale 0.25", though, and only takes 4 minutes to light.

I really need to code the thing that automatically lowers the resolution on faces with no detail. 
 
It's jam2_scampie, so it's not excessive, but it's reasonable for a proper sized map.

4x resolution seems to be the max for this level, generating a 23mb .lit2, anything more and the .lit2 is too large to be loaded.

These are comparisons with -extra and -soft between standard .lit and .lit2 with 4x res.

area1, lit, textured
area1, lit, lightmap
area1, lit2, textured
area1, lit2, lightmap

area2, lit, textured
area2, lit, lightmap
area2, lit2, textured
area2, lit2, lightmap

The gains in this map are mostly in the spotlights being a bit sharper... but it's not very noticable when set against these textures. Perhaps a less noisy/dark/ugly set would be a better test? I'll give my Jam5 a go, since 4x isn't too excessively long to compile. 
Hm 
Yeah it really doesn't add anything to jam2_scampie in those comparisons, even the upward pointing spotlights probably look better in the vanilla version 
 
To be fair, I also don't rely on shadows that much in my lighting. Mostly because Quake is so blurry (and I suck at lighting...)

As a bonus though, in my Jam5 map I notice I can actually get some lighting on some of the detailed faces I wasn't able to light correctly. The blue crystals and grass bits actually receive lighting on their small little faces much better... experimenting a bit now with the hanging vines to see if I can make them cast shadows, which I opted not to do because they were so blurry previously. 
Hrm... 
does "_shadow" "1" not work on func_illusionary? 
It Should Work 
This latest build needs the '-fence' commandline flag to do the tracing through fence textures. But without that, a func_illusionary with _shadow 1 should cast a solid shadow 
 
no... again my bad... I kept saving jam5_scampie.map and not saving as jam5_scampie_16.map which is what I was compiling... *headdesk* 
Jam5 
Added shadows to the func_illusionary hanging vines compared to the released version... the differences here are subtle. It's all in the details, you can get some nice crisp shadows, and in some cases that really pops and is noticeable... but often the subtle nice differences in the lightmap are lost when mixed with textures. Again, -extra and -soft, the .lit2 is 4x resolution.

area1, lit, textured
area1, lit, lightmap
area1, lit2, textured
area1, lit2, lightmap

area2, lit, textured
area2, lit, lightmap
area2, lit2, textured
area2, lit2, lightmap

area3, lit, textured
area3, lit, lightmap
area3, lit2, textured
area3, lit2, lightmap

area4, lit, textured
area4, lit, lightmap
area4, lit2, textured
area4, lit2, lightmap

area5, lit, textured
area5, lit, lightmap
area5, lit2, textured
area5, lit2, lightmap 
 
Basically... not sure it's worth an extra ~25mb of download for general use. There's some nice treats and bonuses here and there, but unless you're doing some really detailed shadow casting, it may not be worth it?

My maps and lighting style may be a bad example though, I tend to light and make bright highlights rather than cool shadows due to the low res nature of Quake's light maps 
 
Thanks for the comparisons Scampie.
It's entire possible this isn't really a useful feature for quake's visuals, or at least for most maps.

I guess the main thing it gives you is the ability to have harder edge shadows without stairsteps. e.g. for sunlight casting an angled shadow, with the default resolution, you have to blur quite a lot to get rid of the stairsteps. So the problem may be, the harder edged shadows may not be desirable anyway.

Regarding file size, the optimal way to use this is just enabling it on brushes that need the higher res, and this will both shrink the .lit2 file as well as have less of a performance hit. I'd recommend never using the map-wide resolution setting on a release version of a map, and only using the per-brush setting. 
Nah Brah 
I will make sure that all my maps are minimum 16x res shadows...

I wont play by your rules!!!! 
 
would global 2x res be worth doing? Filesize prolly wouldn't be too bad? 
 
Like I said, don't call this a bust or anything yet. I'd approach my lighting differently if every/most things had crisp shadows, because I'd want to highlight those more often rather than the ugly blobs we currently have and use a bunch of blurring to make look passable. 
 
are there any quake maps that actually use cast shadows really well? We should test on those. I'm thinking like, dm2 and dm4 have a lot of shadows behind grates and stuff. 
 
dm6 stairs maybe? 
 
Don't know that it's the best test case, but dakyne is what came to mind first. 
DM2 
here's DM2, compiled with -extra4 -soft -dirty -dirtscale 1.5 -dirtgain 0.9 -lightmapscale 0.25 (4x resolution)

area1, lit, textured
area1, lit, lightmap
area1, lit2, textured
area1, lit2, lightmap

area2, lit, textured
area2, lit, lightmap
area2, lit2, textured
area2, lit2, lightmap

area3, lit, textured
area3, lit, lightmap
area3, lit2, textured
area3, lit2, lightmap

area4, lit, textured
area4, lit, lightmap
area4, lit2, textured
area4, lit2, lightmap

Obviously DM2 wasn't made with this in mind, but I think this does show were some of the higher resolution lightmaps can make a big difference. 
Cool Stuff There Scamps 
DM2 is definitely a good showpiece for this new feature 
Awwww 
just tried to compile dm2 at 16x with all those settings...15min compile to make a 93mb .lit2 that is too big and crashes :_( 
 
I was testing fte with a 173mb lit2 before I started messing with projected lights.

(side note: xz compessed it to 14mb, so if you can cope with the load times then its not completely impractical to distribute, just use 7z or xz instead of zip or gz - assuming lit2 was a finalized file format anyway) 
#413 
I prefer the blurry lit1 shots in all of those examples. 
#413 
scamp - any chance you could post a shot of area3 with 2x instead of 4x? 
Area Light Support? 
Wait dont we have area lights support in these compilers? If so then you can have sharp bases for the lights that widen out and look super sweet with this new resolution.

http://area.autodesk.com/userdata/forum/3/3dsmax_viewport_shadows.jpg 
 
Not going to bother with 2x. That goal isn't 'find a compromise where higher resolution and American McGee's lighting from 1996 looks good'. The goal is to make a high resolution lighting system, and make THAT look good. 
Alright Hitler 
keep your trousers on. 
 
I disagree. I don't like the 16x lighting. The hard edges and sharp shadows don't look good to me. What I'm looking for is a 2X, maybe a 3x, improvement in resolution. That would give me what I need to make Quake levels look better than they do today while still retaining the look that makes them work. 
After Testing 
I came to the conclusion that either 2x or 4x could be the new standard for modern mappers. I'm certainly going to map with this in mind. 
 
I think one of the factors making the DM2 shots look bad is the unnatural approach id took to lighting back then, using multiple lights to represent light from the sky as this screenshot taken at Scampie's location 3 indicates - http://puu.sh/hVGCZ/4ed3224645.jpg (taken with DarkPlaces and r_editlights 1 for the sake of convenience).

As a result, you get shadows being cast in several different directions, in a location where one sees a sky above and no other light source and thus expects all shadows to be cast in the same direction. Consequently it ends up looking weird when they aren't. This wasn't quite so prominent with lower lightmap resolution.

I think of all the screenshots Scampie took, the one at location 4 looks best, and that's not surprising since there is only a single light source there - http://puu.sh/hVH6K/089cd1541c.jpg - and thus it looks more realistic. However, as others have said, even in location 4 there is the issue of the shadows looking unnaturally sharp a la Doom 3 and the increased resolution can produce that old problem of better quality media appearing dissonant with the low fidelity of most of the game.

Nonetheless, ericw, I think once people have worked out what combination of compile options works best for a given scenario, this will be a really nice feature and I wouldn't be discouraged by the mixed results so far. 
 
Correction: the first screenshot in my previous post is actually Scampie's location 2. 
Multiple Lights For Skies 
AFAIK id never had the ability to scale lights using the options we have now, they certainly never had things like skyboxes casting light in pretty much any uniform direction. 
 
Yes, like I said, DM2 obviously wasn't lit with this in mind, of course it looks terrible. The test was for curiosity, and to see how much of a difference higher resolution lightmaps make on a map which relies heavily on shadows (as opposed to my maps, where I rely more on bright highlights of light)

And yes 5th, the original tools had no falloff options, no sunlights, -extra was the only compile option for added quality.


Anyone know a decent decompiler? I'd actually like to take a stab at relighting DM2 with a proper sunlight setting 
No Need For A Decompiler... 
all the map sources have been released by romero... you can pretty much just use that to redo everything.

No idea where you can find the files, it used to be on romero's website but that hasnt worked in a while. 
 
oh... must be on quaddicted somewhere. 
Ah 
Scamps... 
Warren 
I disagree. I don't like the 16x lighting. The hard edges and sharp shadows don't look good to me. What I'm looking for is a 2X, maybe a 3x, improvement in resolution. That would give me what I need to make Quake levels look better than they do today while still retaining the look that makes them work.

Remember that at the moment, soft edges are not working correctly as they are not scaled to the resolution.

One of the things that might be interesting to explore with the new resolution is to have shadows change hardness based on distance of light to shadow caster to shadow receiver. If you can fake that, or if you need to resort to light arrays, either way, that would be one way to exploit the higher resolution without it just looking like lame Doom3 stencil shadows. 
Area Shadows.... 
Yea that is why I was asking about area shadow / Area Lights support.

With the new BSP / Material lighting option you can get that effect. But the light source is always visible as GEO. Not a bad thing I guess but be nice to have BSP materials cast light and then be tossed out once compiled or with no rendering or collision. 
Area Lights 
Couldn't find anything on how area lights are implemented in raytracers, but the _deviance/_samples keys can probably emulate it (or they may be the same thing as area lights?) 
 
I'm not sure too much more needs to be done for softer edges, assuming you light with higher resolution in mind.

Here are some shots of my relighting of DM2. No, it's not true to the original; this is more to get a feel for how decent high res lightmaps look when you light with them in mind. No comparisons.

Shot1: Textured | Lightmap
Shot2: Textured | Lightmap
Shot3: Textured | Lightmap
Shot4: Textured | Lightmap
Shot5: Textured | Lightmap
Shot6: Textured | Lightmap
Shot7: Textured | Lightmap
Shot8: Textured | Lightmap

Download if you want to see it in action or compare things or just look at the .map file... realize that this isn't a proper release, needs a .lit2 compatible engine, and will likely break if file formats change...blah blah blah... 
Oh 
above shots are 4x resolution lightmaps, with -soft and -extra4. 
Ok 
1 comparison, to show the sorts of details in play here... compare to shot3

textured | lightmap 
Er 
actual link to lightmap comparison

sorry my head is broken it's 4am 
You Mean 4xAM 
 
 
For screenshots showing off lighting, those are some of the blackest images I've ever seen. 
 
That said, once I level them in Photoshop, VERY nice. 
DM2 Link? 
Scampie can you reupload your DM2 again? that link is dead. 
 
sorry, the download link was owned by caps... this is why you do things when you are awake and paying attention....

http://scampie.net/privfiles/DM2_lite_052215.zip


warren: yeah, sorry... my monitor apparently doesn't look like anyone else's and my screenshots always come out too dark :| 
Ok Here's An Idea 
If we are going down the road of .lit2 + special engine support...

Could we introduce lightmaps on liquid surfaces as part of lit2's features?

Quake's ugly fullbright water is one of the big immersion-breaking things imo, and it would be cool to update that a bit :} 
 
Thanks Scampie. DM2 looks a million times better. I recently ported DM2 over to Quake 3 and give it a similar treatment.
http://i1187.photobucket.com/albums/z382/AndehGX/quake3/axq1dm2.jpg

Also, does anyone still have Gypsy's .ent and virtuoso pack for Quake 1? I lost it in a format, and his links are dead :/ 
 
Could we introduce lightmaps on liquid surfaces as part of lit2's features?

Yes plz! (need to have some way to make lava fullbright though!)

--

I calibrated my monitor (brightness was way too high) and adjusted levels on my screenshots in post #435 and reuploaded them, hopefully they aren't super dark anymore? Think the map itself is actually lit too dark, but it's not terrible. 
Lightmapped Liquids 
Hah, the same request came up in the inside3d thread. I think it can be done in a way that's backwards compatible, without needing special support in lit2. It'd probably be a "-litwater" flag for qbsp and light; qbsp would use it to chop liquids on the 256 grid (they aren't normally chopped), light would generate lightmaps instead of not. Pretty sure engines not supporting lit water will just ignore the lightmaps (but need to verify this.)

According to LH, DarkPlaces will already render them. 
 
Could we introduce lightmaps on liquid surfaces as part of lit2's features?

This doesn't actually need LIT2 at all. You could do it with a regular light tool and some engine modifications.

It would also need QBSP modifications because by default liquid surfaces aren't subdivided as much as solid ones.

But you probably don't want this at all, because in most cases it actually looks worse than fullbright water. 
 
yeah, you can't light water without going into a whole consideration of how light interacts with water. eventually you'll put a fancy portal2 water shader alongside 300-poly monsters and you get this silliness:
http://quakeone.com/~files/ss_e2m1_FN3.jpg 
 
mmm yeah, you're right... in Lun's example pic, that water would just be standard Quake water, except tinted bright yellow by the bright yellow lights. 
 
I don't have the game right now to check, but didn't Quake 3 just have lightmaps on top of simple Quake-esque water?

Coupled with transparency, it didn't look too bad if I recall? 
 
http://scampie.net/etc/q3_water.jpg

think q3dm10 is the only place it's used in stock q3?

It does look reasonable, but might only work because there's like 3 layers of mostly transparent water textures blended with the light. 
 
I reckon vertex-lit water would be reasonable, with a single vertex colour for the entire water plane. Of course the mapper would need to be careful about the placement of lights relative to water so that we don't get weirdness like water surfaces half-in and half-out of a really bright area. But it would solve what I guess is the primary problem here, which is a fullbright water surface in an otherwise uniformly dark area.

Much of that also goes away with translucent water, where the water surface blends with the underlying geometry. You almost certainly don't want to add lightmaps there - light is supposed to shine through water, after all.

Another problem with lightmapped water is that the lightmap can obscure the turbulent warp effect. Under certain conditions it just looks like a regular solid surface (until you walk into it).

Shadows being cast on water surfaces also looks wrong.

To be honest, and having implemented this in the past (but with realtime light rather than lightmaps), fullbright water is really just the lesser evil. Lightmapped water falls apart real quick once you move away from just wanting it and graduate to actually thinking about how it would look. 
 
Shadows being cast on water surfaces also looks wrong

http://i.imgur.com/5GU8rQi.jpg
http://i.imgur.com/f10kgnE.jpg 
 
Looks wrong somehow. 
 
Vertex-lit water like mh suggests could actually be good, just avoiding super-bright water when you're putting it in dark areas likely would be enough.

Tricky part might bebackwards compatiblity and lava which should be fullbright no matter what. But it sounds like a reasonable approach to try 
 
http://i.imgur.com/5GU8rQi.jpg
http://i.imgur.com/f10kgnE.jpg


The first one looks OK because you can still see the water effect through the shadow.

The second one looks like concrete.

Both are completely irrelevant because we're talking about Quake water here.

Tricky part might be ... lava which should be fullbright no matter what

QBSP identifies lava by the presence of the word "lava" in the texture name, so the light tool and the engine could do the same and just skip lighting/draw without lightmaps. A modified QBSP could of course identify lava by something else.

I'm of the opinion that teleports should also be fullbright, and slime should at least have some light of it's own too. QBSP also identifies "slime" like it does "lava", but doesn't identify teleports. 
Oh, Duh, Of Course :D 
You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 
Oh, Duh, Of Course :D 
You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 
Oh, Duh, Of Course :D 
You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 
 
If crisp shadows look bad on water, maybe lower-res lightmaps on water are an option?

I think the main goal is to just get darker water in dimly lit areas of the map - not to make super realistic looking water. 
Other Options 
-setting a low r_wateralpha
-using dark water textures
-use a darker .tga for the water texture, to avoid quake palette limitations 
 
If crisp shadows look bad on water, maybe lower-res lightmaps on water are an option?

I think the main goal is to just get darker water in dimly lit areas of the map - not to make super realistic looking water.


this is the kind of thing that would really need to be tweakable. there are many different effects someone might want to try for. Say your water is muddy, then a harder shadow makes sense. But it might be clean lake water, so a much softer (or no) shadow may be called for. thing is, none of that can be inferred from the texture name (*water) unless you get into fancy stuff like (*waterHazy vs *waterHard) or some such but it would be better to just have a .txt file with some values in it that is read by the compiler in that case. 
 
Both are completely irrelevant because we're talking about Quake water here.

I wouldn't say they're completely irrelevant. After all, they're photos of what water looks like in the real world and given that Quake is designed to render the real world with as much accuracy as possible (to the extent possible in 1996 and to whatever extent we judge now to be in keeping with its original fidelity/style), getting water that's as accurate as possible within those constraints should be worth attempting.

Obviously no one's suggesting we start pursuing a proper simulation of how light interacts with water, including refraction, reflection and so on, but a simple approximation of real water might be to say that clear and/or shallow water ignores shadows and instead lets them cast on whatever's below it, whereas murky and/or deep water allows shadows to be cast on its surface.

Ideally that might be done like the new texture lighting is done, with each texture being assigned a certain level of transparency. If it's flagged as, say, anything below 0.7, it doesn't allow shadowing on its surface, if it's above 0.7 it does. So you might might specify *water0 (used in the stream at the start of e1m1) as 0.5 transparency because you intend to use it for shallow, clear water, whereas you might want *04water1 from the start of e1m2 to be used for filthy, murky water and thus you assign it a transparency of 1.

Obviously you'd want any map that uses this to disregard whatever value the player has set for any r_*alpha settings.

Not sure how technically feasible all that would be, but it would make water look better, while staying true to Quake's modest looks and allow mappers to configure it in a fairly intuitive way. 
 
kinn's examples aren't shadows on water, they're shadows on the dense silt suspended in the water. water is transparent:
https://mw2.google.com/mw-panoramio/photos/medium/18556818.jpg
and lightmaps on clear or partly transparent water are what look strange, because they're not coupled with a volumetric fog component to explain the shadow to the eye.
https://developer.valvesoftware.com/w/images/8/88/L4d2_flowmap_user.jpg 
 
Its only the specular term of the water surface that is visible - its reflections (also, those little white specs you get on the tips of waves that are annoying to model correctly, resulting in most games having far too shallow waves).
Obviously there needs to be some sort of fog effect when the water contains impurities that reflect light, and this can have shadows cast upon it. good luck getting that realistic though.
Following on from that thought, any water fogging needs to know the surface plane of the water - and on maps like dm3, there is no singular plane, and that just makes any sane waterfogging logic go crazy.
If the water surface is reflecting light then this of course means that there should be a darkening of the surfaces below the water line. Also, any water impurities should cause the lights to have a higher attenuation for the parts of the ray that travel through the fog, relative to the amount that gets reflected up and away from the water volume before it can reach the surfaces below.
Also, lights shallow angles will reflect some light from the surface of the water rather than through the water (fresnel effect), increasing with how close to the water plane the light is - and of course, if you have waves then the closeness varies...
This is all very interesting if you're writing some glsl (yay for cubemap refraction and screen-space difraction), but if you're writing a static tool then you're basically doomed. DOOMED I SAY! Okay, melodrama over, but imho the best you can do is just use a single light value for the entire water surface (which of course might need to consider the intensity of the water texture too, which iirc is typically a little darker due to not expecting any lighting ever).

It might be interesting to generate really low res lightmaps for water, and by really low res, I mean one lightmap sample for every 1024qu or something. However, with that sort of scale, I expect you'll have a whole load of issues with vertexes inside walls and other sorts of issues. calculate at 1/16 and average it something like -extra4 already does? 
 
FFS, it's Quake ... what could possibly look worse than the fullbright water surfaces we have now? Just try something. Anything. :) 
 
Hmmm - well, it's possible to set things up so that water recieves light but doesn't occlude it - which actually looks mostly OK!

http://i.imgur.com/lDKcJs7.jpg 
 
Warren speaks the truth. Let's not get sperged down by details of physically realistic water.

I reckon:

ability to specify lightmap resolution on liquids - as discussed, lower resolutions than usual will probably look better.

0-1 float value to define liquid lightmap "influence" - 0 = fullbright surface as before, 1 = full lightmap, as if it's a solid opaque surface.

For lava, I'm sure you'd want 0 always, but for slime and water, I reckon there's a happy medium somwhere. 
Oh, Duh, Of Course :D 
 
How About Letting Lightmap Intensity Determine Water Alpha 
And then normalize the color maybe?
Just thinking out loud here...

float Alpha = magnitude(lightmap.rgb)
float3 LightColor = normalize(lightmap.rgb)
float3 Color = texture.rgb * LightColor
output float4(Color, Alpha)

Haven't written any shaders in years, can't remember how it's actually done.

Maybe skip the color and just use intensity
Maybe this would look completely weird... 
I Thought... 
the reason why we dont have lightmapping on water was because the water texture warps around and moves, and the lightmap would move and distort with it? 
@Fifth 
Not necessarily. It's possible to warp the water texture but not warp the lightmap. 
Thats Cool 
I do hope this is something that gets implemented then, fullbright water is crap. 
That Left 4 Dead Texture 
Is gorgeous, lets just do that ;)

Theres no clean water in quake anyway! Shub-n-word-erath and his buddies have been jizzing in it for aeons, we all know that. Does no one even read the back story? 
Ok I Made A Doodie 
https://www.shadertoy.com/view/MtB3DK
Click and drag around to mess with the alpha values! I'm sorry I suck at this! 
Well... 
I'm not quite sure I see the appeal of what's going on in that czg...thing - but let's stick with the czg theme for a bit and just remind ourselves about this sort of thing:

http://i.imgur.com/htecdQb.jpg

We've been using those crummy "waterfall" textures for years, and they get lightmapped, and I don't think anyone's complained (about the lightmaps on them). I think they look alright don't they? I still don't get what's so terrible about just trying that on the proper liquids. 
 
Well... that's something we can test right now with the tools given to us. Here's a crummy waterfall made of func_illusionarys with "alpha" "0.65"

http://scampie.net/etc/transwater_1.jpg
http://scampie.net/etc/transwater_2.jpg

It looks okish when viewed from above, but once you get to about chest deep in the water, you realize it's just a plane of animated texture and it starts to look fake. It's not the worst thing in the world, but certainly not convincing.

here's the .bsp and .map and all that. requires an engine that supports "alpha" key on brush models (fitzquake engines)... if you want to compile the .map so you can fool with the alpha values and such, you'll want ericw's tyrlite becuase it's mostly lit with sunlight and sunlight2
http://scampie.net/etc/transwatertest.zip 
 
"It's not the worst thing in the world, but certainly not convincing. "

This implies that it was convincing before. 
 
Well, what I meant is it looks odder where you have a lightmap on the transparent water because you lose a sense of it having any volume. The bright spots on the surface of the water call attention to the fact that there should be lighting on some volume inside the water as well, so it ends up just looking like a flat plane suspended in the air. In a modern engine, people would be putting volumetric effects and fog in the water to hide exactly this.

http://scampie.net/etc/transwater_3.jpg
Uniform brightness of the water surface, despite being too bright here, seems to sell volume better. Without the added transparency of the shadowed areas revealing that the light isn't hitting any particles in the water, your mind fills in that the water must be dense. I think if this were simply vertex lit to end up being closer to average brightness of the area it would look fine. 
I Like It. 
I for one love it. And just leave it up to the math authors to support it or not. This on muddy swamp water would look great. This could work nicely when used on fake ground fog as well. 
Blowing Dust Off From My Mad Mapping Skillz In Jackhammer 
Just started with corridor for the level introduction. I'm not even sure if that matches the theme in anyway, also I wasn't using any level editor for like 7 years, so it is just a quick sketch to remember basic things:

http://imgur.com/a/rGJIz 
Quick 
Quick fix for geometry, small changes for light and texturing:

http://imgur.com/8GSFG88 
 
I think you're in the wrong thread. :) 
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.