.Map :: MoHAA Mapping

I'm compiling rightnow, with final light and got this for a while:
Is this part always taking so long?

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.

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.

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

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

At0miC wrote:1468 brushes, 9 lightsources

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

At0miC wrote:what did u excactly mean with glowing surfaces?

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

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

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

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.

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

At0miC wrote: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

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.

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.

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.

Balr14 wrote:Or, maybe I'm just a geek.

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

tltrude wrote: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).