Quake3World.com Forums
     Level Editing & Modeling
        Why do models receive shadows better than brushes.
Post new topicReply to topic
Login | Profile | | FAQ | Search | IRC




Print view Previous topic | Next topic 
Topic Starter Topic: Why do models receive shadows better than brushes.
Rav3n
Grunt
Grunt

Joined: 12 Mar 2011
Posts: 51
PostPosted: 02-04-2012 03:21 AM           Profile Send private message  E-mail  Edit post Reply with quote


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.
Top
                 
Noruen
Insane Quaker
Insane Quaker

Joined: 28 Jan 2010
Posts: 302
PostPosted: 02-04-2012 04:31 AM           Profile Send private message  E-mail  Edit post Reply with quote


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.
Top
                 
Rav3n
Grunt
Grunt

Joined: 12 Mar 2011
Posts: 51
PostPosted: 02-04-2012 04:56 AM           Profile Send private message  E-mail  Edit post Reply with quote


Noruen wrote:
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.
Top
                 
lightmill
Trainee
Trainee

Joined: 27 Nov 2011
Posts: 42
PostPosted: 02-04-2012 05:20 AM           Profile Send private message  E-mail  Edit post Reply with quote


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



_________________
twit
blog
¯\_(ツ)_/¯ ----------------------------------------------------------------
Top
                 
obsidian
I'm the dude!
I'm the dude!

Joined: 04 Feb 2002
Posts: 10423
PostPosted: 02-04-2012 08:34 AM           Profile Send private message  E-mail  Edit post Reply with quote


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.



_________________
GtkRadiant | Q3Map2 | Shader Manual
Top
                 
Rav3n
Grunt
Grunt

Joined: 12 Mar 2011
Posts: 51
PostPosted: 02-04-2012 09:02 AM           Profile Send private message  E-mail  Edit post Reply with quote


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.




Attachments:
shot0116.jpg
shot0116.jpg [ 191.85 KB | Viewed 38 times ]
Top
                 
obsidian
I'm the dude!
I'm the dude!

Joined: 04 Feb 2002
Posts: 10423
PostPosted: 02-04-2012 09:17 AM           Profile Send private message  E-mail  Edit post Reply with quote


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.



_________________
GtkRadiant | Q3Map2 | Shader Manual
Top
                 
Rav3n
Grunt
Grunt

Joined: 12 Mar 2011
Posts: 51
PostPosted: 02-04-2012 09:27 AM           Profile Send private message  E-mail  Edit post Reply with quote


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.
Top
                 
obsidian
I'm the dude!
I'm the dude!

Joined: 04 Feb 2002
Posts: 10423
PostPosted: 02-04-2012 01:13 PM           Profile Send private message  E-mail  Edit post Reply with quote


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.



_________________
GtkRadiant | Q3Map2 | Shader Manual
Top
                 
Quake3World.com | Forum Index | Level Editing & Modeling


Post new topic Reply to topic


cron
Quake3World.com
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group