Jump to content
The Dark Mod Forums

Oscar's little big problems.


Oszkár Winkler
 Share

Recommended Posts

can many lights still degrade system performance even if their corresponding leafs are closed? I can only assume that this would mean that lights will still cast shadows even in closed areas to avoid leaking light into areas where they should not throughout the entire map. or something like that.

 

I might try to implement something like these lightswitch triggers in my map if its a pretty big deal.

 

lights in "closed" areas are off.

Link to comment
Share on other sites

I had a building in a map that had 30 visible visportals in it and everytime you went through a visportal the game would pause for 2 seconds, I've redesigned the building so only 5 visportals are in view at anyplace in the building. so 30 visportals in the players view is too many visportals. While it didn't cause the game to crash the pause made it feel like the game had crashed.

Link to comment
Share on other sites

hmmmm... are you entirely sure about that? if a spotlight behind me (not in view) in a closed leaf shines on a wall in front of me in my current leaf. can i see the light on the wall?

 

 

I've had a light in one leaf leaking into the leaf I was in. When I shut a door that closed the visportal between the leafs, the light stopped leaking, which means the effect of its light wasn't being rendered. Open door, light on. Close door, light off.

 

This only pertains to rendering. AI passing that light in the "closed" leaf still see it as "on".

 

Your example of a spotlight behind you is a different situation. The volume behind you that's not being rendered isn't "closed". It's just not being rendered. The effect of a light behind you is still rendered onto the surfaces in view in front of you.

Link to comment
Share on other sites

I had a building in a map that had 30 visible visportals in it and everytime you went through a visportal the game would pause for 2 seconds, I've redesigned the building so only 5 visportals are in view at anyplace in the building. so 30 visportals in the players view is too many visportals. While it didn't cause the game to crash the pause made it feel like the game had crashed.

 

By "visible" do you mean open AND closed, or just open?

 

Going through a visportal shouldn't have an effect. The pause might happen when a visportal opens, though, because more is suddenly being rendered. Any textures in the newly-opened area that haven't been loaded are loaded in that instant, which can contribute to the pause.

Link to comment
Share on other sites

I've had a light in one leaf leaking into the leaf I was in. When I shut a door that closed the visportal between the leafs, the light stopped leaking, which means the effect of its light wasn't being rendered. Open door, light on. Close door, light off.

 

This only pertains to rendering. AI passing that light in the "closed" leaf still see it as "on".

 

Your example of a spotlight behind you is a different situation. The volume behind you that's not being rendered isn't "closed". It's just not being rendered. The effect of a light behind you is still rendered onto the surfaces in view in front of you.

 

You sure the door wasn't just then casting it's shadow?

 

Lights always light up the polys they hit. You can see this by having brushes in another area combined with a func_static in the area you are in. Even though the area those brushes are in is closed off properly, they still remain lit.

If closing the area turned off the lights then the polys would no longer remain lit.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

You sure the door wasn't just then casting it's shadow?

 

Yes, I'm sure. The light was leaking through the wall.

 

Lights always light up the polys they hit. You can see this by having brushes in another area combined with a func_static in the area you are in. Even though the area those brushes are in is closed off properly, they still remain lit.

If closing the area turned off the lights then the polys would no longer remain lit.

 

 

If brushes in another area are combined with a f_s in the area I'm in, then I assume you mean it's all one f_s. Since I can see the bit that's in my area, the entire thing is being rendered, which means the bit that's in the leaf with the light is being lit, which means the bit that's with me is being lit.

 

If we go back to the original question, "can many lights still degrade system performance even if their corresponding leafs are closed?" the answer is "no". I see no reason why the answer would be "yes".

 

 

Link to comment
Share on other sites

Okay, I'm going to reverse myself slightly on this.

 

If a surface in an open leaf is being lit by a light that's in a closed leaf, then the surface could be lit or not lit, depending on other conditions. In my example, the surface stopped being lit by the leaked light when the leaf closed. But here's an example of the opposite behavior:

 

 

-----------------A-------------------
|                                    |
|           	vpA                  |
|                                    |
|         	|-----|      vpB     |
|         	|     |              |
|        P      |     |            L |
|         	|     |              |

 

The surface "A" is being lit by the light "L". From the Player's (P) perspective, visportal "vpA" is open and visportal "vpB" is closed.

 

The player will still see the light from L on A.

 

So from the perspective of the original question, if you put a thousand lights at L, and they all light A, then--yes--performance can be impacted by lights that are in a closed leaf.

Link to comment
Share on other sites

that last is the main point, thanks for the good test. Is this always true? Might it depend slightly on build methods (such as the ground being one large brush or broken up, etc)?

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

I still have a sneaking suspicion that these lights in closed leafs are casting shadows. otherwise, in grayman's diagram, what is stopping the light from leaking through the walls jutting out from the bottom of the diagram, and onto the player? do the shadows only cast from the worldspawn on the borders of the open leaf, or does it still cast on everything in the closed leaf.

 

edit: what if there is a stolen painting obscured in shadow in the closed leaf that an AI could spot if no shadows are cast? I'm thinking even if technically not rendered, the shadows still need be cast so that the AI in closed leafs still have a grasp on their surroundings (bloodstains, dead bodies, stolen loot, doors that should be closed are open, etc etc, all these things could be obscured in shadow)

 

re-edit: on the flipside, if shutting off lights in closed leafs to save on performance, does this not mean that a thief could wreak total havoc in a leaf, leaving behind bodies and blood everywhere, and no AI will notice after the player has left the leaf?? when is it truly appropriate to shut off lights behind the player to save on performance?

Edited by ungoliant
Link to comment
Share on other sites

I would presume that you count the size of a light volume the same as a Func_Static entity and thus if the volume crosses a visportal it still gets rendered no matter where the "center" is located. Is that not pertinent to this discussion?

 

Or to clarify further, shadows are never cast outside the volume bounding box of a light, the illusion that they do is due to the falloff image providing a false radius.

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I would presume that you count the size of a light volume the same as a Func_Static entity and thus if the volume crosses a visportal it still gets rendered no matter where the "center" is located. Is that not pertinent to this discussion?

 

what about where a light volume crosses over a non-visportal leaf boundary and extends into an adjacent leaf? the light does not shine in these areas. Is this because the light volume gets 'lopped off' by the engine at this border, or because shadows are being cast?

Link to comment
Share on other sites

I would presume that it's impossible to cut-off the light that way just as a FS that crosses a VP will never get cut. It must be a shadow within the light's bounding box which must extend beyond the VP in your scenario. I wonder if you are experiencing a problem with the VP material itself... things like twosided VP materials have been known to cast shadows...

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I wonder if you are experiencing a problem with the VP material itself... things like twosided VP materials have been known to cast shadows...

 

:blink: I have not had this problem. did you misread:

a light volume crosses over a non-visportal leaf boundary

Edited by ungoliant
Link to comment
Share on other sites

when is it truly appropriate to shut off lights behind the player to save on performance?

 

I don't know how the shadows are handled, nor how AI in closed leafs react differently in situations where shadows are meaningful and the player isn't around.

 

I will mention, however, that if you plan to have scripts turn off lights when the player leaves an area, this will affect the relight dynamics. "ShouldBeOn" lights don't care how they were turned off, and AI might relight doused lights, undoing what your script is trying to accomplish. This could also lead to heightened alert levels, which would be unfair to the player because they did nothing explicit to contribute to the AI's change in alertness.

 

A way to get around this would be to distinguish between player- and non-player light dousing, which would require coordination between the TDM on/off scripts and your script.

Link to comment
Share on other sites

Ah!!!

 

I get it, you wanna know if the shadow volumes are calculated past the visportal closure.

 

Boy it would be inefficient to do that but some of that must be going on for accuracy purposes.

 

I would imagine that only vectors facing out of the portal would get traced... it would be a colossal waste if not true...

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

:blink: I have not had this problem. did you misread:

 

 

OK in that scenario, you are either looking at the angle of the leaf boundary to the light source (which for non-smoothed geometry like brushes can be a harsh cut-off)...

 

Or the falloff image(s) for the light have an abrupt cut-off. Since the z-projection axis always fills the volume with the same texture just at different brightness levels according to it's own projection texture, any geometry that hits the edge of the light bounding box can exhibit artifacts related to how that geometry is projected on that axis. This also means you must be very careful about rotating lights where the bounding box limit will intersect geometry in view... (Another reason why cubemap or 3D texture based lights would be cool additions when Doom 3 goes GPL).

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

there's an easy way to test if light goes through a closed visportal, all you do is create two rooms linked by a doorway, the func_static door only has a frame and is empty in the middle, stick a visportal in the doorway, and the visportal is fooled into closing by closing the door, then if you have a light that goes through the doorway when open, does it still go though the door when closed.

 

the 30 visible visportals in the building were all open, they were all in the players line of sight, not blocked off by worldbrush.

 

 

the water control building in lord duffords has a screen door, originally there was a visportal in the door hole the the screen door went in, closing the door, closed the visportal creating a view into the void through the screen door, the lights from the room still projected through the holes in the screen door to light up the wall opposite the door. somewhere else in the map there's a torch on the wall outside a room and some texture based windows, there's void between the two window textures and the outside is separated from the inside by a closed visportal the light outside shines through the windows and projects window shaped light across the floor even though they're not connected. I think all the visportal does when its closed is to cull what the video card gets.

Edited by stumpy
Link to comment
Share on other sites

I was wondering. Is texture coloring possible? Like adding a reddish, bluish Hue filter, so a brownish brick texture would look bluish instead? The old build engine could do it. (Duke Nukem 3D)

Winkler Studio: youtube.com/user/woszkar

Link to comment
Share on other sites

I was wondering. Is texture coloring possible? Like adding a reddish, bluish Hue filter, so a brownish brick texture would look bluish instead? The old build engine could do it. (Duke Nukem 3D)

 

I don't know about texture coloring, you might have to edit the textures and supply the altered ones with you mission to do that.

 

Or you could just use different colored ambient and normal lights. That will naturally change the texture appearance.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

You can include red, green, and blue in the material shader definition but the downside is it can only reduce so the brightness goes down. Effectively without red, green, blue the texture is 1,1,1 full bright. A brown brick image is predominantly red with less green and even less (if any) blue. Theoretically if you add red, green, and blue to the material you might think you could decrease the red and increase the blue to get torquoise or cyan. In practice the range is 0 to 1 so you can't increase above 1. So all you can do is decrease the red and you might get to cyan (assuming there is sufficient blue in the original) but it would be somewhat dark.

 

I suppose it might be possible to produce a very bright grey white image of say brick and then use red, green blue to get different hues. The downside here is that the each colour would be somewhat monotone I think.

Link to comment
Share on other sites

You can always add material stages with internal images like "_white" and "blend blend" or "blend add" them but that component wont be light reactive so it might have a bit of a glow...

 

 

... oh wait, I think you can also nest image maps for a map function...

 

yep

 

http://www.modwiki.net/wiki/Add_%28Image_program_function%29

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


  • Recent Status Updates

    • jaxa

      RTX 3090 Super, RTX 3070 Ti 16 GB, RTX 2060 12 GB
      https://wccftech.com/nvidia-launching-rtx-3090-super-rtx-3070-ti-16gb-and-rtx-2060-12gb-by-january-2022/
      · 0 replies
    • duzenko

      CPU benchmark time - compiling DarkRadiant (2nd run)
      i5 8600K 6C/6T@4.4GHz DDR4 2x2133MHz 9MB cache
      Parallel builds: 1. 3:57 Parallel builds: 6 (default). 2:28 r5 1600AF 6C/12T@3.3GHz DDR4 1x2666MHz 16 MB cache, temp folder on HDD
      Parallel builds: 1. 5:05 Parallel builds: 4. 2:47 Parallel builds: 6. 2:55 Parallel builds: 12 (default). 2:57
      · 6 replies
    • nbohr1more

      Status updates are back so it is also a good time to return to contests!
      https://forums.thedarkmod.com/index.php?/topic/21095-christmas-connections-contest-2021
       
      · 0 replies
    • freyk

      Having seen the new scifi stuff from bladeghost/scythwraith, want to continue the cyberpunk project. Only one problem, can't map.
      · 1 reply
    • jaxa

      Behold, the brand new RTX 2060!
      NVIDIA ponders GeForce RTX 2060 re-release with 12 GB VRAM to paper over RTX 30 scarcity
      · 1 reply
×
×
  • Create New...