Max_patches

I know this is more a WC/VIS/RAD question than an NS one, but it is an NS map, and, well, gosh-darn it, there's some very nice clever friendly people here.

I'm getting the MAX_PATCHES problem - more than 65535 patches. Now, I've looked around, and the solution seems to be increaseing the scale on some textures, especially ones that aren't seen. One person recommends scaling up any textures touching the void by 100, which saved him about 100 megs of VIS data.

Question 1 - does that actually make any difference? Surely the VIS process throws away any textures facing into/touching the void?

Secondly, I can use the -sparse option, which gets around this problem - but does that simply mean my map is likely to arse up within HL itself?

The trick is to block visibility without LOOKING like you're blocking visibility... you know, map casual.

Comments

And you're also correct about VIS throwing away any textures touching the void. Well, actually the textures are still there, but VIS doesn't create any lightmaps for those textures, which is what patches are, lightmaps. So even if you do scale up textures touching the void it won't help.

You could try using -chop with a value greater than 64, but the higher you go the worse your lightmaps will look in-game.

Use -sparseIt will increase your compile time a fair bit, but you won't have any patches problems, and -sparse does not alter lighting quality in any way (for better or worse). As far as I know, all the official NS maps had to use -sparse to avoid patches problems.

Confucious says, "It is most difficult to find a black cat in a dark room, especially if there is no cat."--Level Designer for hire--

Yeah, if you're not too worried about how things look on these not-final compiles, go ahead and do -chop 128 to cut down on compile times, at least thats what I do. And if you're just going to let it compile overnight or if you don't mind waiting a bit longer to see how the lighting will actually work, add -sparse and leave chop alone.

In the end I had to compile ns_hera with -chop 128. The lighting doesn't really suffer all that much, and if it does give horrendous results, you can always use -sparse instead. This will take MUCH longer though, and is only recommended for final compiles. You can also use -chop 96, which hardly affects the lighting at all.

Alternatively, you can put the NULL texture on faces the player won't see, but are still in the level after BSP. This will stop RAD from building lightmaps on those faces, but it won't really help in any other way. (It's a myth that putting the NULL/SKY texture on unseen faces will raise the r_speeds.)

During the BSP process, all faces touching the void or another brush are culled from the .bsp - this is why you can't decompile maps into brushes very easily - no data is kept for the culled faces. (So BSP doesn't just not build a lightmap for the culled faces - it deletes them altogether.)

"I am the woodsie lord, the Trickster of legend. If you be thirsty, flesh thing, drink of me. If you be hungry, then feed, for I am the honey-maker and the jacksberry." ~ The Trickster, Thief: The Dark Project (1998)

On some systems with less RAM (such as my old compiling machine) -sparse can actually decrease compile time. It will help if hlrad seems to hit a wall somewhere in the MakeScales and progress starts becoming really slow.

-sparse just uses a different algorithm to calculate the lighting. The vismatrix is represented differently --instead of using a fixed-size matrix that stores every entry, they use a "sparse matrix" which only stores the necessary entries. The size is much more variable that way, so you can go above the max_patches limit.

It seems you're going over the texture memory set (8Mb). Now this won't show you a recognizable error, because you're including them into the bsp and instead will show you an (none-informational) read error instead. Try and compile without including them to see where it goes.

It seems you're going over the texture memory set (8Mb). Now this won't show you a recognizable error, because you're including them into the bsp and instead will show you an (none-informational) read error instead. Try and compile without including them to see where it goes.

Actually, the default texture usage limit is 4M, not 8. HL was released in the times of yore when most people had GPUs in the 4M range, and "gamer" cards of the time required you to sell a kidney (3dfx).

IIRC, HL has a limit on the number of unique textures allowed in a single map. You can theoretically allocate as much texture memory as your GPU has. Since most modern cards have well over 256M, you aren't going to hit that limit before you hit the unique textures limit. I've used up to 64M in textures before in a map and there was no noticeable performance impact.

QUOTE (unknown)

Admiral, why dont we just breach the hull after overriding the automatic hatchlocks closing procedure?

Last time we did this an onos just put its fat **** inside the hole and lerks just farted a new athmosphere.It looked so gross that we decided to never ever do this again.