Dsiable SkyAtmosphere in cave??

Development World Creation
,
1

I created a cave in my scene, surfrounded on all sides with boxes to keep any light out. it should be completely dark (except for the little light that enters via the entrance) but there is this weird effect:

image
image1920×1665 40.3 KB

The scene - when perspective set to unlit:
image
image1920×1486 248 KB

If I disable skyAtmosphere, the scene in the cave is indeed pitch black.

I can continue editing in unlit mode (obviously). Viewing in lit mode is fine - provided SkyAtmosphere is disabled:

image
image1920×1158 76 KB

but that ruins the outside world…

In play, however Sky Atmosphere ruins the view:


even when I have it disabled in Outliner while in the editor, or in “play in editor”

How can I keep SkyAtmosphere on for the outside world, but prevent it’s activity inside the cave?

2

Normally you add a trigger at the entrance that disables or changes things, including directional light and skylight.

Then if players are able to skip the entrance you are sool.

Potentially, set the floor of the cave to a specific physmat, and toggle things off if not already off when the physmat hits.

Another option is to check for a point being within or outside of a volume.

Really depends on how complicated you want to be about it.

3

I found a method that suits my needs, so at some poit in entering the cave, I have a moment where I should be able to disable SkyAtmosphere - in practice: set attribute ‘visible’ to false when entering the cave, and to true on exit. But I could not find a way to include that in blueprint.

4

I succeeded with a very simple blueprint, using a collision box, enveloping the whole cave; on begin overlap, I turn Skyatmosphere to ‘hidden in game’, on end overlap turn this off again. One thing noticed: After setting “hidden in game” to “off”, getting the value a second time will NOT reflect this setting! So you need a local variable, default “TRUE” (SkyAtmosphere is ON")

image
image1920×963 149 KB

Likely not the best solution but it works for me

5

Its very error prone if the player starts off within the volume or if it manages to end the overlap and have it start again.

Mostly because you need to ensure that you are turning it back on when they exit.

Id suggest just doing level transitions for the cleanest possible solution.

If that isn’t avaliable, dot product can probably help.

Use it to determing if the okayer is entering or exiting by setting up 2 triggers.

First trigger starts the process off by recording the heading.
Second trigger will either confirm the heading or never get accessed.

Dot product because you can make the triggers smart enough to be interchangable.

This way you can also allow the player to enter, turn around and change his mind to leave.

Srill, your best case scenario is that you put a door on the cave entrance and force the player to click to achieve the transition - think Skyrim?
Is it annoying? Yes, but it does work better…

6

It’s just a start :grinning: and I know there will be far better ways to do it but I’m a beginner in this field, just learning by YouTube videos and trial and error. It works for me - by double doors on both entry and exit, one outside the volume and one inside, with the volume boundary between them. I have no intention to start entrance or end within the volume yet. Currently, it works for me; it’s turning SkyAtmosphere off when I enter the volume, and back on when I leave it. No matter where I enter the volume.
But you are right, starting off inside the volume should switch it off and it doesn’t; instead, it will assume the player being outside instead of inside, so it works exactly opposite. So if I can find out whether the actor is located inside or outside the volume, I could take action. An example of how to use dot product would be welcome too.

7

It doesnt matter what you intend. Its a player you have to deal with.

Will i be able to see inside the dark cave if i log out and log back in while inside the cave entrance? Yes. So ill do that and screw your making the cave dark.

Assume you have 2 triggers.
A and B.

A is at the mouth of the cave.
B is a little deeper in.

The player traverses both A And B - it entered the cave. Toggle skylight off.

The olayer traverses A. Doesn’t touch B. Touches A again. No need to do anything.

To make it cleaner and so that A can be B and B can be A you can just use the dot product to get a heading.

Place an arrow (not visible in game) within A.
The player touches A, take his acotr forward vector.
Dot product to arrow forward vector.
Is the result 0? Same direction.

Ofc you can’t use =0.
You have to use something like <= .5 and >= -.5
As thats the nature of dot product.

This enables you to determine if your first hit is “coming” or “going”.

Then you can re-use A as the second checker earlier called B.
Just add code in there to see if the player had already crossed what we called A.
If true and the direction is still correct, then affect the lighting.
If not, do nothing to the light and untoggle the check that says you passed through A.

You need to refine that some more for actual play, but it eliminates most possible hack while keeping your components to a bare minimum and its fairly easy to use to toggle other things - entering hose doors where you only have room for one check, for instance.

While you are at it, look up what interfaces are, and use those.
Implement one on the character to respond to whatever the entrance BP will tell it to respond to however the character sees fit.
Or the skylight, or whatever other things needs to be made to respond individually.

(Normally a light control BP that references other level objects as variables you can pick with the eye dropper within PIE and set to default is used to control all of this. And you sjojld really look into creating that so you dont need to “look around” for things within your project(s))

8

Thanks for the explanation, I’ll work that out - it’s indeed more generic.
The disadvantage of using no doors is that SkyAtmosphere lights up the inside of the cave, so if I look into it from a distance, it’s not pitch black as I would expect, and when looking outward from the cave, the inactivity of SkyAtmosphere is clearly visible in the outside world. The same applies using one door: opening the door shows a light cave in stead of a pitch-black hole, or a distorted outside world, and the change of SkyAtmosphere will be immediately visible - therefore I used the second door to hide the change from view.

What I don’t understand is how the solution with dot product will solve the issue of lighting on logout while inside the cave, and return there after restart. It’s the same problem I have when an actor is spawned inside the volume: You don’t know whether the actor is within, or outside because there is no movement into or out of the volume. Unless you can determine it somehow - or save the sate on logout and restore it on return.

But that’s another question.

9

For that, once its toggled you make the variable part of the save game and restore from it. Doesn’t need to re’check or have anything to do with the dot product.

You have problems with the volume because you can accidentally cause that variable to load correctly, and change. Altering what you really intended it doing.

Say you pass A, the heading (actor forward vector) is stored. You log out. That variable is saved and reloaded.
You now hit the block (a or B they can be the same object) again. You can re-check what action to take by comparing the old forward vector to the new one in order to determine if the player is indeed going in or coming out.

On saving - the blueprint interfaces are going to make it simple to adjust/re-acquire and reset the daved value before a loadong screen is removed.

On it looking bad - use a timeline to progressively alter the sky athmospere.

Unfortunately even with lume the engine isnt going to do proper spacial occlusion.
There are some steps you can take to make the rendering a little better at it using distance fields - but a dark windowless room is always affected by the skysphere values if any (bounce and such).

There are different GI options out there - none of them game ready or cheap - that make the rendering more realistic in those situations.

For your avarage game (which is AAA since assassins greed does the same) this darkness adjustmebt factor is completely ignored.
For good games, which foucs on nuances, the engine’s built in rendering is pretty much a deal breaker anyway. So its either replaced or, the engine is not used.

When inside a dark windowless room and opening a door, all you should see is brightness.
Its easy to fake it.

For full GI solutions unreal uses Eye Occlusion which you can actually disable to introduce similar and better effects. Enabling you to keep the rooms darker (since the engine wont attempt to alter brightness).

Combination of that and looking into specific ad-hoc solutions will get you close to something that doesn’t feel entierly wrong.