upper limit for lightprecision

[bonifarz]

First of all, sorry for not following the simple rule: First discuss, then commit

Roughly a week ago, there was some chat on IRC about using larger values for the world var lightprecision. In short, this results in uglier lightmaps, that are faster to bake and take less space in the mpz file. As far as I have seen, there is no technical limitation for using values larger than 256. So I ramped up the maximum value to 1024 on the master branch, such that people who don't want to compile can do some testing. This might be useful for larger concept/custom maps, or to speed up some previews, also when using F6 (calclight -1).

My question for now: Is the limit of 256 arbitrary (in the sense of "coarser simply looks too ugly"), or was there a particular reason for picking that value? And accordingly: Can we keep this (or another) larger limit?

[Dziq]

This is all my fault, I'm started that conversation and bonifarz make it possible, I totally ignored making a thread for discussing this now I feel stupid..

I dont know why 256 is a max limit, now a 1024 is helpfull as hell, on some slower pc's it's like salvation, especially when we do not have realtime lighting update and when we need to see only simple light preview, even if its ugly.

Please do not revert it back to 256 :\ .. nobody should use that in final map revision, its logical.
value of 2048 if possible should be even better but really 1024 its something that I miss until now, thank you boni for that - its a great feature

[shirepirate]

it may load much faster on a slow pc, but there are also many players with more modern systems that would prefer a nicer lightmap. the shadow quality really goes to shit pretty quickly above 256, as illustrated below:


/lightprecision 32 http://i.imgur.com/ix2Lt3V.jpg
/lightprecision 256 http://i.imgur.com/U7lXkn5.jpg
/lightprecision 1024 http://i.imgur.com/P0yrAPe.jpg


/lightprecision 32 http://i.imgur.com/GKbBsvs.jpg
/lightprecision 256 http://i.imgur.com/TUhJKGG.jpg
/lightprecision 1024 http://i.imgur.com/qM0PsUs.jpg


/lightprecision 32 http://i.imgur.com/7X01O9L.jpg
/lightprecision 256 http://i.imgur.com/sKRmCvj.jpg
/lightprecision 1024 http://i.imgur.com/070oL31.jpg

looking at institute in particular, we see that when raising it as high as 1024 the quality becomes so bad there is almost no reason to even have a lightmap anymore. it's good practice instead to keep lightprecision as low as it can be without a significant change in the size of the map file. if it weren't for file size constraints we'd probably enforce /lightprecision 8 on every map.

so, i suppose the max size was set at 256 as a general guideline that it's not a good idea to go above it when trying to balance a quality lightmap with cpu constraints and file sizes. i don't see how it could hurt to set it higher when editing, but for a final copy that you share around you should probably lower light precision (and what use is it to calclight with such a low quality lightmap when editing anyway? it's not as if you will be able to see much from it).

[SniperGoth]

That should prove useful when editing online. I vote for this change to stay.

[qreeves]

I don't see a problem with leaving the higher limit in place, it's just it is a "world variable" which is saved with the map, and isn't something you'd really want to change (in case you forget to set it back, or forget the original value). I suggest we create an issue for a "quicklight" command which has it's own "lightprecision" variable that defaults to a much higher value.

[bonifarz]

Thanks for the feedback.

Dziq, it's not "your fault", I was wondering about this for quite a while and just forgot to get back to this.

Shirepirate, I see your point. Though, for many vars the upper limit does not serve as a guideline, but leaves the user free to try different things. Of course, there's a big difference between finalizing a map, and playing around with some tests in editing mode.

A new command for quicklightmap could be pretty cool. I guess we could use that to replace the F6 editbind, and put the value for its lightprecision in the editing options menu.

Concerning multiplayer editing and (slow) light calculations: Maybe we could use something similar to editlock to restrict the use of commands like remip and calclight. Though, I'm not even sure if that causes any waiting time for connected clients in master.

[qreeves]

"remip" is sent across the server, but "calclight" is only performed locally.

[restcoser]

remips... should have some rate limit...just some player hitting the wrong button a few times, and it gets quite annoying (and some players spam it on purpose to annoy others)
and its really not needed that often... maybe like... max 1 remip per 3 seconds

[qreeves]

[bonifarz]

Thanks for the update, Quin.

So, calclight and patchlight now have a second argument. If this optional bool is 1, lightprecisionquick (2048) is used. And there's aliases quicklight and quickpatchlight for exactly this, nice. I don't know if any default binds make sense for this, but I'll add some buttons to the editing menus for sure.

[freezurbern]