|
Post by missingpeaces on Jul 29, 2015 17:49:16 GMT -5
I'm just getting started with mapping and I'm having trouble with my shadows appearing very harsh and jagged in game. Example: What can/should I do to create more natural-looking shadows? I'm using QuArK (6.6 Beta 6) as an editor, with QBSP3 1.09, QVIS3 1.03 and ArghRad 2.00, without compile options (because I don't know them, really). qbsp3 quake2\ctf\maps\mpctf01.map qvis3 quake2\ctf\maps\mpctf01.bsp arghrad quake2\ctf\maps\mpctf01.bsp Thanks for any help. I'm glad to be here.
|
|
|
Post by knightmare on Aug 1, 2015 0:57:14 GMT -5
That's just how lightmaps are handled in Quake2- they're 1/16 the resolution of the original textures. Shrinking the texture on a surface will get you more detailed lightmaps, but also more surface splits and it may cause errors (MAX_MAP_LIGHTING) in the light phase of the compile.
|
|
Null
Gladiator
Posts: 555
|
Post by Null on Aug 1, 2015 10:20:07 GMT -5
|
|
jaydolan
Quake 2 Mapping Club
Posts: 161
|
Post by jaydolan on Aug 3, 2015 7:31:58 GMT -5
To give shadows more resolution and make them less jagged I think you'd use smaller chop values (like 16): chop chopcurve chopsky choplight chopwarp bounce (probably higher bounce value as well) To make shadows less harsh I'd play around with the max/min light settings: minlighta maxlighta ambienta radmin sample values (mostly random / not optimized): arghrad -threads 4 -chop 16 -chopsky 32 -chopcurve 64 mapname.bsp arghrad -v -extra -bounce 256 -chop 32 -chopsky 32 -radmin 100 -minlighta 12 -maxlighta 190 mapname.bsp arghrad -v -extra -bounce 64 -choplight 16 -chop 16 -chopsky 256 -radmin 10 -minlighta 12 -maxlighta 190 mapname.bsp `-chop 16` is a terrible idea. It'll cause your faces to be subdivided at regular 16 unit intervals, and it has next to no effect on lighting. Have you ever looked at what this does to your r_speeds / gl_showtris? The first thing I usually recommend to people in trying to improve their map's performance is to use `-chop 1024`. All `chop 16` will do is literally raise your r_speeds by an order of magnitude (default is 256, 16x16 = 256). Do not use this method. `-extra` actually will improve lightmap jaggies because it forces the light sampling algorithm to use "extra" sample points -- coordinates adjacent to the default sample coordinates -- for gathering light. It's your basic Gaussian blur algorithm, where several points in a cluster are measured, and then their average value is used as the result. Works fairly well, but inflates your compile time significantly. This is why most mappers save this option for their final bake. `-bounce` defines how many times a light source will reflect off of CONTENTS_SOLID before completely dissipating. This is known as the "indirect lighting" pass, or the "radiosity pass", and is where the `-rad` compile stage derives its name. This was new to Quake2; Quake1 did only direct lighting. Higher bounce values (default 4) can give your map a more cohesive ambiance, and will soften some shadows up, but is probably not the answer to the OP's issue. I think Knightmare and Jitspoe both have some improved tools that may help alleviate what you're seeing in your map. The problem is two fold: 1) Quake2 does in fact use a very low resolution for lightmaps and 2) at this low resolution, false collisions (very common near surface edges) cause shadows to seep through corners. The solution is to nudge the sample positions during the lighting calculation towards the surface center, and along the surface normal. This prevents false collisions during the light gathering pass, and you see fewer of these artifacts. Hope this helps!
|
|
Null
Gladiator
Posts: 555
|
Post by Null on Aug 3, 2015 11:19:08 GMT -5
|
|
jaydolan
Quake 2 Mapping Club
Posts: 161
|
Post by jaydolan on Aug 5, 2015 6:58:07 GMT -5
Interesting! It seems like Arghrad has its own -chop (and -chop*) parameters. In that case, your suggestions are correct, Null. My bad.
That's kind of a curious choice on Argh's part, since the standard issue tools from id Software have a -chop option on the BSP stage, which will do exactly what I described above. But if you _only_ provide -chop to Arghrad and NOT qbsp3, then you won't hurt your r_speeds at all. Thanks for providing that link.
With that said, based on my own experience in implementing some of these features in q2wmap / quemap, the areas where you'll likely see the most improvement are on Phong-shaded surfaces and light-emitting surfaces. So I would recommend starting with just -chopcurve and -choplight as a general rule of thumb. My lighting compiler automatically increases patch precision on Phong objects and light emitters.
|
|