Jump to content
The Dark Mod Forums

Search the Community

Showing results for tags 'lights'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 3 results

  1. When volumetric lights were officially supported, I was blasted away on how good the Screenshots looked. So I tried to implement some in the update of my FM. But actually I always ended up with removing them because it looked rather strange with many small dark dots appearing in the areas of the light or when NPCs walk through them. As I read that many FM authors already implemented them into their missions, I wonder what setup did you use? Which colours and density worked for you? My plan was to use a volumetric light for the fireplaces in this mission. But no matter how ai played around with density and colour, I always endet up having those small black and grey tiny dots around. Also the rest of the room looks out of place if the torches on the wall DON'T use VL but the fireplace does. I can't find another way but to listen to your experience with VL. Thank you!
  2. 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.
  3. 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?
×
×
  • Create New...