lightmap questions

(ACROBAT) #1

I noticed when I use “_blocksize 0”, the -light phase is dramatically sped up.

For clarification purposes. My understanding has been that the -light phase references the .prt file made during the -vis phase and calculate a mini-lightmap for each leaf node. It then integrates all the lightmaps into one giant lightmap. Is this a bad way to think about it?

This makes intuitive sense since the -light phase can sometimes be sped up by 10X or more from using _blocksize 0. The blocksize can create a surplus of leaf nodes in your map rather than just square rooms, which would be otherwise the case. If the -light phase has less leaf nodes in total number and also less complex leaf nodes to calculate lightmaps for, then it might explain the dramatic speed increase in the compile.

Also does anyone have any info on each stage of the -light compile that I could read about?

ps- it doesn’t use the ACTUAL prt file but a prt file integrated into the bsp right after -vis.

(stephanbay) #2

omg i think Reyal_P is gonna shoot someone this time :stuck_out_tongue: . _blocksize has nothing to do with -light phase :stuck_out_tongue: :stuck_out_tongue: . are you talking about light gridsize?

(ACROBAT) #3

No, that’s not what I mean…

I’m talking about “_blocksize 0” indirectly affecting the -light phase (as I said in post one)

The effect is only noticeable on large map compiles. We had about a 20 minute compile, and then we went to blocksize 0, and not only did it -vis speed up, but it also dramatically sped up the light phase. Our compile went from 20 min to about 60 seconds.

The .PRT table\file contains all the leaf node divisions and associated PVS sets of each leaf node that was created after the -vis compile. If the light phase uses the .PRT table for its raw data to compile mini-light maps for each leaf node, this effect makes sense. After each leaf node’s lightmap is complete, my thought was it was integrating all the minilightmaps together into one giant lightmap.

This makes sense in a way since if you have two rooms far apart with a teleport, then you would expect it to compile a lightmap separately for each area. Just expand that idea so it does it for each actual leaf node.

Fewer leaf nodes= less time in the -light phase, and blocksize creates a heck of a lot of portal lines aka many more leaf nodes. Before I saw the dramatic speed up myself, I would have assumed the -light compile would be about the same either way because it’s computing a lightmap for the same volume. However, I with blocksize 1024 implemented, for instance, there are many more portal lines and the AREA of portal lines planes is much greater in addition to there simply being more leaf nodes.

(SCDS_reyalP) #4

q3map2 does use PVS for light culling. Perhaps in cases where you have a lot of blocks that don’t help this, it may slow things down.

(ACROBAT) #5

q3map2 does use PVS for light culling. Perhaps in cases where you have a lot of blocks that don’t help this, it may slow things down.

I said I thought it used the .PRT table’s defined leaf nodes to make the light map not the PVS sets of each leaf node in that table but the leaf nodes themselves. What do PVS’s have to do with -light compile?

What do you mean by “culling?” Am I missing something?

(mena666) #6

The reality is the opposite of what ACROBAT is saying.
AFAIK, without -vis, -light takes far much longer.
Leaked map should prove it.

(ACROBAT) #7

The reality is the opposite of what ACROBAT is saying.
AFAIK, without -vis, -light takes far much longer.
Leaked map should prove it.

I did not say that anything about skipping the -vis phase. I said that a decreased number of leaf nodes with the same amount of volume along with less complex PVS sets sped up our compile by about 10X. the decreased number of leaf nodes was due to using blocksize 0.

Also skipping -vis and just doing something like a meta compile doesn’t mean your map will suddenly leak.

(SCDS_reyalP) #8

Eliminate the light as a possible light source for a given area. If one leaf node cannot see another, then lights inside it cannot light stuff in the other either. (neglecting radiosity, but that works by generating new lights)

Light doesn’t use the .prt file, as the vis phase deletes it unless you use -saveprt

(ACROBAT) #9

Ya in the first post I said-

ps- it doesn’t use the ACTUAL prt file but a prt file integrated into the bsp right after -vis.

I just assumed it was using an integrated version of the prt file vs the actual prt it leaves for you to look at.

I do a 5-20X decrease in compile time with blocksize 0 though. Very dramatic