#435 posted by - on 2015/05/22 10:27:00
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
#436 posted by - on 2015/05/22 10:27:59
above shots are 4x resolution lightmaps, with -soft and -extra4.
Ok
#437 posted by - on 2015/05/22 10:36:11
1 comparison, to show the sorts of details in play here... compare to shot3
textured | lightmap
Er
#438 posted by - on 2015/05/22 10:37:13
You Mean 4xAM
#440 posted by JneeraZ on 2015/05/22 12:03:20
For screenshots showing off lighting, those are some of the blackest images I've ever seen.
#441 posted by JneeraZ on 2015/05/22 12:04:49
That said, once I level them in Photoshop, VERY nice.
DM2 Link?
#442 posted by AndehX on 2015/05/22 13:33:33
Scampie can you reupload your DM2 again? that link is dead.
#443 posted by - on 2015/05/22 18:34:16
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
#444 posted by Kinn on 2015/05/22 18:38:44
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 :}
#445 posted by AndehX on 2015/05/22 20:04:12
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 :/
#446 posted by - on 2015/05/22 20:21:04
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
#447 posted by ericw on 2015/05/22 20:50:39
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.
#448 posted by mh on 2015/05/22 20:51:41
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.
#449 posted by Lunaran on 2015/05/22 22:13:58
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
#450 posted by - on 2015/05/22 23:02:01
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.
#451 posted by Kinn on 2015/05/22 23:53:05
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?
#452 posted by - on 2015/05/23 00:24:40
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.
#453 posted by mh on 2015/05/23 00:44:11
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.
#454 posted by Kinn on 2015/05/23 00:49:55
#455 posted by mfx on 2015/05/23 01:02:39
Looks wrong somehow.
#456 posted by - on 2015/05/23 01:13:30
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
#457 posted by mh on 2015/05/23 01:45:21
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
#458 posted by - on 2015/05/23 02:15:28
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
#459 posted by - on 2015/05/23 02:15:28
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?
|