Why do models receive shadows better than brushes.

[Rav3n]

I've noticed that models receive finer shadows than brushes, anyone knows what's causing this?
Also why exactly is there a difference in shadow quality between shadows cast on X,Y and shadows cast on Z axis.

[Noruen]

1) Because in Q3 there is lightmap texture limited to 128x128 px, so on large surfaces there is necessarily lower quality lightmap and on models, there is large amount of small surfaces and also details - so lightmap can seem to be more precious. See "2)" and also you can adjust quality by setting "lightmapscale" of brush in func_group to lower number (0.5), but it will decrease performance and increase compile time.

2) This is caused by _(light)gridsize which is 128 128 256 (x y z) default in compiler - which means that Z scale has two-times worst quality (or is stretched).You can prevent this by set _gridsize in worldspawn entity to lower, or same numbers (as 64 64 64), but it will again take much more time to compile lightmap.

[Rav3n]

1) Because in Q3 there is lightmap texture limited to 128x128 px, so on large surfaces there is necessarily lower quality lightmap and on models, there is large amount of small surfaces and also details - so lightmap can seem to be more precious. See "2)" and also you can adjust quality by setting "lightmapscale" of brush in func_group to lower number (0.5), but it will decrease performance and increase compile time.

2) This is caused by _(light)gridsize which is 128 128 256 (x y z) default in compiler - which means that Z scale has two-times worst quality (or is stretched).You can prevent this by set _gridsize in worldspawn entity to lower, or same numbers (as 64 64 64), but it will again take much more time to compile lightmap.

Yeah i completely forgot about the grid in worldspawn. Thanks for the reminder.

[lightmill]

isnt gridsize for lightgrid that affects the lighting of entities, like players, items etc and not the world lightmaps

[obsidian]

Holy misinformation Batman!

Q3 has 3 different lighting systems that work in conjunction with each other on different types of objects, lightmaps, vertex lighting and lightgrid. Each are entirely different lighting systems and one does not directly affect the other, though Q3Map2 tries to make them each fairly uniform with one another to provide the illusion of universal illumination.

Lightmaps are what most mappers are familiar with, they are 128x128 pixel bitmap images generated by Q3Map2 that are stored internally in the .bsp file. They are "projected" (more accurately UV mapped) onto brush and patch surfaces. Lightmap resolution is pretty common on all surfaces (brushes, patches and models with lightmap enabled spawnflags) with the exception of *very* large polygons which a single 128x128 luxel lightmap page can't cover at normal resolution. You can scale lightmaps, but it comes with all sorts of caveats that I only recommend for more advanced users. Lightmaps typically only affect brushes and patchmeshes (with Q3Map2).

Vertex lighting is also compiled by Q3Map2 for brushes, patches and all static models. In addition to XYZ coordinates, a vertex also can contain other data like colour values (RGB and alpha). Vertexes with different values have create gradients between their points on the surfaces of the polygons. Vertex lighting "resolution" is strictly dependent on the relative distances between vertexes, the closer a bunch of vertexes are together the better perceived resolution of the vertex lighting. This is why small decorative models will typically look much better with vertex lighting than brushes do, because models typically have a much higher polygon density than brushes. This is also why I keep saying that most models will look better vertex lit than lightmapped, because with their high polygon density, they will actually have higher quality lighting than relatively huge luxels being projected on its surface. The reverse is true for brushes and patches, with typically have much lower polygon densities.

The lightgrid is a 3D grid (maybe better to think of them as a 3D volume of cells) that spans the dimensions of the map like a giant cuboid, subdivided into 128x128x256 blocks by default. It is used exclusively for dynamically lighting entities like players, weapons, items, and other dynamic entities that move around in the game world. Static objects like brushes, patches, mapmodels are not affected by the lightgrid. Each "cell" is assigned a RGB colour value by Q3Map2 based on the average intensity and colour of lighting. As objects move into a new volume of the lightgrid, the object takes on those RGB values. You can see this at work by looking at your player's weapon in hand as you move throughout a map, the weapon model seems to be lit differently as you move between volumes of the lightgrid.

Again, these are three completely different lighting systems working together to provide the illusion of actual light sources and photons bouncing around when in reality it does nothing of the sort.

As for the OP questions:
1) Lightmaps will generally be pretty uniform in resolution on all surfaces unless you manually changed things. Vertex lighting can look better on models than lightmapped brushes depending on polygon density.
2) You'll have to provide an example of where you see this. As you can see, lighting is all very complicated and in general, there shouldn't be any difference in shadow quality of either lightmaps or vertex lighting with regards to axes.

[Rav3n]

The light is coming directly from behind. As you can see on the floor the shadow doesn't have straight edges, while on the vertical wall it's perfect.
This is very noticeable on thinner brushes that stand close to walls, on the floor the shadows would be almost completely destroyed while on the wall it would look fine. It creates a contrast and makes no sense so in the end i blur the shadows just to even them out.

[obsidian]

Umm... That has to do with the angle in which the shadows are cast from the light source and aliasing of luxels. The shadows on the floor are slightly diagonal while the lighting on the wall is perfectly perpendicular. The reverse would be true if you changed the angle of lighting. This has nothing to do with lightmap axis.


Also, get your own image host - plenty of free ones. IIRC, DooMer said that we don't have a lot of hosting space on the Q3W server. Attachments are typically for tutorials or other files that need some sort of longevity here.

[Rav3n]

That's just the thing, shadows on the floor should not be diagonal at all.
They're being cast under a 0 degrees angle. That is if that angle is even possible to achieve. Or some minimum angle is always applied.
The light is a _sun 1 spot light that is placed behind the brushes. If i was to draw a line from the light entity through the info_null all the way to that vertical wall, the angle between the 2 lines would be 90 degrees.
Or does the position of the brush itself has impact on the angle under which the shadow is cast.

[obsidian]

Regardless, it's still an aliasing issue, not a difference in lightmap resolution between wall and floor. If you don't believe me, export the lightmap out yourself and have a look in Photoshop. There are plenty of ways to fix aliasing issues as documented both in the Shader Manual and on a very in-depth tutorial that I wrote here on Q3W where I systematically compiled a map a million times to illustrate incremental changes to shaders and Q3Map2.