Search the Community
Showing results for tags 'lights'.
While doing some render system refactoring I noticed that projected lights were not rendering correctly in lighting preview mode, and thought it was something I had broken until I regressed to earlier revisions and discovered that it has actually been broken for some time (in fact I tried checking out revisions from 3 years ago and the problem still reproduced). Projected lights are something of a "bug trap" because I think most mappers don't use them or the DR lighting preview very much and therefore they don't get a lot of testing. The behaviour I see is that while the rendered light projection obeys the shape of the frustum (i.e. the light_up and light_right vectors), it seems to ignore the direction of the light_target vector and always points the light straight downwards. The length of the target vector has an effect (on the size and brightness of the light outline on the floor), but the direction is ignored. Note that the problem only applies to the rendered light itself. The frustum outline appears to be correct (as it is handled with different code). I believe the problem is with how the light texture transformation is calculated in Light::updateProjection(), although I can't be sure. I will make an effort to debug this although projective texture transformations are near the limit of my mathematical abilities (I can understand the general concept and probably figure out the process step-by-step by taking it slowly), but might have to ask @greebo for assistance if the maths becomes too hard. Another approach is to try and revert the relevant code back to when (I think) it was working correctly after I initially got projected lights working, although that might have been 10 years ago or more so a straight git bisect isn't practical.
While working on fog issues, I noted that the spectrum keyword (which allows you to pair lights to materials based on spectrum number value) does not have an entity arg. I was considering adding one to make the spectrum feature a little more useful but it struck me that the main use case for spectrum outside of "hidden writing" is trying to keep lights from illuminating unintended surfaces. In that context, we would not want to manually specify the matching spectrum number for everything we want to be lit but rather we would want to have a flag that says "light everything except this". I am proposing that I can create a "noSpectrum" keyword that can achieve this opposite \ negative functionality. It's an easy enough change. Is it worth the addition? Would any mappers use it?