Func_static and common/lightgrid

[neoplan]

Hi,
there are 2 questions that I cannot figure out myself and maybe somebody can help me.


a) What is func_static? How can i use it and what are the pro\cons about it.

b) I was browsing the common directory and saw a texture called lightgrid. What is that texture for?


Greetings, Neoplan

[obsidian]

func_static: Conditional walls and models. So you can have a wall or other object only appear in certain game types, like a doorway that you want open for FFA, but replaced with a solid wall for CTF.

Lightgrid is used when you want to restrict the size of the lightgrid to certain boundaries for performance optimization. Take a space map for example, you may not need lightgrid calculations done in the void where you have no light sources anyway so you would circle a single lightgrid brush around the region that you do want lightgrid to be calculated.

[neoplan]

Thanks for that!

Where can I get more Information about the lighting process in q3 engine? I want to know about the principles behind it because I am still not sure if I understand it fully.

[^misantropia^]

Fairly broad question. It's lightmap based. Is there anything specific you want to know about it?

[obsidian]

That's actually just part of the answer, it's predominantly lightmap based, but it also uses vertex lighting as a fallback feature and for models as well as the lightgrid for dynamic models.

[^misantropia^]

I'll grant you the point about vertex lighting but dlights are creative-hacking-with-lightmaps incarnate. Albeit the lightmap used is an internal, pure white one, so as a mapper, you don't have much control over it.

[obsidian]

I wasn't talking about the rocket glow dlights. I'm talking about the lightgrid used to modulate vertex colours on models like player models (which I concur is still vertex lighting).

[neoplan]

Thanks for your help ^misantropia^ and obsidian!

I am close to finish a big map with appr. 17 000 brushes. It is a Defrag Freestyle map and the map itself is divided into several separate rooms that are linked via teleporters. I created the parts of the map in several map files to keep performance in radiant and save compile time for testing purpose. My plan was/is to put everything together when the parts are all ready and then make final compile.

I was testing how it would look like after putting everything together and then the problems raised. First problem was, that compiler complained that i have too many faces in my map but i could get rid of it with a command in bsp stage. Another thing that is getting on my nerves is, that compile time is very long (like several hours) and the bsp loading time (because of the bsp file size) too. So now I am looking forward to finish the map and am looking for possible performance improvements. R_speeds should be ok as I was already looking at them while i was creating the separate rooms.

There are couple of questions:
1) How can I speed up the compile time a bit? (i read about changing the lightgrid size and that is the reason why I was asking for further infos to light process because my knowledge about light process is quite superficial)
2) How to reduce the bsp size?
3) How are external lightmaps built in the bsp file and could they reduce compile time, file size?
4) What is the best way to place the separate parts of the map? Here is a Screenshot:
(the long sections in the screenshot are Strafe jump training rooms)

The map itself is not that special in design but i tried to atleast make the Freestyle room - the most important part of the map, where the freestyle tricks are performed - unique and put some innovative stuff for trickers (innovative due to other defrag freestyle maps).

[obsidian]

1) Lightgrid calculation time is relatively short compared to everything else. If you're looking to save some compile time, look elsewhere first.

2) BSP sizes are mainly determined by lightmaps and vertex data, etc. Make sure you texture all unseen faces with caulk to prevent them from generating lightmaps. You can try reducing lightmap resolution on certain surfaces if need be.

3) External lightmaps are the same size as internal lightmaps, so you won't see a difference in performance either way. They have to be created/read one way or another.

4) Don't think it makes a difference.

Other stuff:
Make sure you convert all non-vis blocking brushes to detail.

Check your Q3Map2 log files to determine exactly which process is taking so long to compile. Without knowing what the actual problem is, you're just grabbing at straws.

[g0th-]

Let me just pinch in here with a question of my own. Is it possible to get lightmaps on models somehow? I know you can get it for terrain with the "planar mapping cmd" attached in the shader. I also saw you mention dynamic models, how does that work and is it something that could be used to make the lightning look better on models?

[obsidian]

Lightmapped models can be enabled with q3map_forceMeta in the shader or the forcemeta spawnflags setting on the model (spawnflags 4). Note that on certain models (smaller models or ones with a high number of smaller polygons) will actually look better with vertex lighting than lightmaps. Large surface triangles like terrain may look better lightmapped at the usual performance costs.

When I say dynamic models, I mean models such as player and weapon models. The lightgrid is a 3D grid of colour values that spans your entire map bounds. As the player moves between the volumes of each grid space, the player/weapon model's vertex colours are scaled by the colour values of the volume. This is how Q3 simulates the appearance of a player model or your weapon model on your HUD going in and out of shadows.

[g0th-]

Thanks a lot for the info obsidian