compiling little question

[At0miC]

I'm compiling rightnow, with final light and got this for a while:

Code: Select all

====== Calc Light & Diffuse Grids ======
  0% complete.  0 hours  0 minutes  0 seconds remaining.

Is this part always taking so long?

[Bjarne BZR]

Ehhh.... what is SO LONG? 5 minutes? 5 hours? 5 days?

It depends on your comlile settings, but generally: that part of the compile takes a relatively short time... say 5 minutes for a map that compiles in 2 hours.

[At0miC]

hmmmmz, it's now at 30%
( ====== Calc Light & Diffuse Grids ====== )
and it tooked 13 ours, my light setting is at final, and I have nothing special at the vis or bsp.

[Bjarne BZR]

That IS a long time... is the map loaded with lightsources, complex brushwork and glowing surfaces by any chance?

[At0miC]

1468 brushes, 9 lightsources and what did u excactly mean with glowing surfaces?

[Bjarne BZR]

1468 brushes, 9 lightsources

Does not sound like a lot... strange...

what did u excactly mean with glowing surfaces?

I mean surfaces textured with textures like "light/jh_rustwin1lit", that are light emitting textures.

[At0miC]

I got 32 light emitting surfaces if that is what u mean?

btw, I got an Athlon 2200 Mhz with 512 mb ram

[tltrude]

Yes, there are about 32 faces that have light emitting textures (red and green lights). But the problem is that the lighting grid is near the 2.09Mb limit. The map has a lot of moving patch mess script_objects.

[At0miC]

Okay, so was it normal that that part of compiling (30%) taked 13 ours with -final?

[jv_map]

Okay, so was it normal that that part of compiling (30%) taked 13 ours with -final?

Yes on -final calc light & diffuse grids can take extremely long

[bdbodger]

Yes with light emitting surfaces it can get really slow I think they slow it down more that any other thing . I did a map with just a couple of them and it really slowed down the compile.

[Balr14]

A light emitting surface has one light point per block (as specified in your compile), with the original size of the texture being used as basis for calculating how much area a block covers. In simple terms, if you have a texture with an original size of 512 x 512 and you downsize it to fit a surface of 256 x 256, and blocksize is 256, then you have 4 light points in your 256 x 256 surface. Conversely, making a texture larger than original doesn't have the opposite effect (unless it's a small texture). Rad will never calculate a surface to be lit larger than the block size specified.

Light emitting surfaces used over a broad area present another problem to light calculation, in that the possibility of occluded light is considerably greater. As you probably know, there has never been a really good method of casting shadows when a number of occluded light sources are involved. The methods that are used to create static light/shadow are slow and cumbersome and it's basically not possible in real-time. Carmack cheated with the Doom3 engine by making everything dark. Pretty fascinating stuff, hey? Or, maybe I'm just a geek.

[tltrude]

I don't think it is the small light emitting faces or patch mesh causing the light grid data to be so high. The map has several scrolling texture, and when I add just one more it fails to compile light with an "exceeded lightmapgrid data error". It does not matter if the new texture is added to a patch or a flat brush--its just one to many scrolling textures.

[Bjarne BZR]

Or, maybe I'm just a geek.

Yes, you are a geek... but in a good way.

[Balr14]

I don't think it is the small light emitting faces or patch mesh causing the light grid data to be so high. The map has several scrolling texture, and when I add just one more it fails to compile light with an "exceeded lightmapgrid data error". It does not matter if the new texture is added to a patch or a flat brush--its just one to many scrolling textures.

Raise the block size to 512 (I think default is 256).