1. On August 16th at 9pm CST, the site will be put in to read only mode for maintenance. Maintenance should not take longer than an hour.

Dark spots in my map

Discussion in 'Mapping Questions & Discussion' started by Seitan, Sep 3, 2017.

  1. Seitan

    Seitan L3: Member

    Messages:
    136
    Positive Ratings:
    16
    Help
    [​IMG]
    [​IMG]
    This one doesn't happen in the BLU side of the map ^ ^ ^
    [​IMG]
    [​IMG]

    This is how they look in the editor:
    [​IMG]
    [​IMG] [​IMG]
    [​IMG]
    [​IMG]
     
  2. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
  3. Pocket

    aa Pocket func_croc

    Messages:
    4,489
    Positive Ratings:
    2,219
    You also probably shouldn't be spreading out your lights so far in an attempt to light stuff directly. Let the extra bounces of -final do the work for you.
     
  4. Seitan

    Seitan L3: Member

    Messages:
    136
    Positive Ratings:
    16
    So this may be automatically fixed in the final compile?
     
  5. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    No it's not. the -final compile only uses the "-final" command which is equal to "-extraSky 16". It just fires more rays from the sky, making the light_enviroment lighting more accurate.

    What the three other commands from the article do is:
    1: Instead of having a single point for each model to calculate it's shadowing, the entire model is used and it will be lit like it makes sense.
    2: Instead of the unacurate colision model, the actual model will be used to calculates shadows with.
    3: If a model has a transparent texture it will now properly let light through at points where it is transparent.
    Oh, and there is the custom .rad file thing, but that's only useful when you really want to use its features, so you probably don't need to worry about it for now.

    Dunno why Valve didn't add those extremly important commands to one of the advanced compile options, but you wouldn't want to only have these compile options with the -final compile because -file will extend your compile time massivly while the other lighting options only make your compile by 15-30% longer.
    Also setting up your own compile options makes you able to quickly switch between compile options. What I do is having a vvis compile for normal and one for fast, and then make vrad compiles for:
    -fast -hdr
    -hdr -staticproppolys -textureshadows
    -staticproplighting -lights customlights.rad
    -both -staticproppolys -textureshadows -staticproplighting -lights customlights.rad
    -both -staticproppolys -textureshadows -staticproplighting -lights customlights.rad -extrasky 16

    upper one is a basic test with bad lighting, second one is better lighting but HDR only because my game is in HDR, third one is also for testing however compile for both HDR & LDR so it can be tested on a server where some players may have LDR and finally the 4th option is the final compile.

    Now I guess you could probably just the command to the -final compile and never bother with it again until you want to compile for final, however if the final compile still has some weird shadowing in a place you would just end up with long compile times just to change some shadows, so try setting up your own custom cpmpile with more options to be more efficient
     
    • Thanks Thanks x 1
  6. MOCOLONI

    MOCOLONI L5: Dapper Member

    Messages:
    243
    Positive Ratings:
    60
    This may not be the proper way of fixing it, but it's how I fixed these errors in my maps:

    1. The shadow on the first screenshot is usually caused when the lamp's prop has its shadows enabled, which should be disabled if it draws these shadows.

    2. For the 'darker props' case, it's because their origin isn't reached by the light that is supposed to illuminate them, so I would spawn an info_lighting entity next to the prop that is illuminated properly, and set the darker prop's lighting origin to use the one by the info_lighting entity. It works fine for me, and is also the way Dustbowl got some of its rocks darkened/illuminated in the official VMF.
     
    • Agree Agree x 1
  7. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    No offense, but please stop recommending this method over the compile options. It will still look worse than when using the proper lighting compile settings. All props will have a much more natural and accurate lighting to it and all shadows will be acurate too. Most notable improvements can be seen at the pinetree props.
     
    • Agree Agree x 2
    Last edited: Sep 4, 2017
  8. Seba

    aa Seba DR. BIG FUCKER, PHD

    Messages:
    2,363
    Positive Ratings:
    2,365
    Using an info_lighting and keeping pervertex lighting off can sometimes look better than with pervertex on, -staticproplighting isn't a one-size-fits-all solution
     
    • Agree Agree x 1
  9. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    True, but it's a better solution the vast majority of the time as all props will have better fiting lighting. Most of my maps never needed a info_lighting at all.
    That's why I said you shouldn't recommend using an info_lighting over the compile settings, or epecially in this specifc case.
     
  10. Pocket

    aa Pocket func_croc

    Messages:
    4,489
    Positive Ratings:
    2,219
    I thought -final caused lights to bounce more. I know there's some option that does, because recompiling 2fort with the base options leaves you with darker than normal spawn room ceilings.
     
  11. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    You must be thinking of -bounce https://developer.valvesoftware.com/wiki/VRAD

    The wiki says, the default is 100. Is there a recommended value for a final compille or does it not really matter?
     
    Last edited: Sep 5, 2017