What I mean by this is to make a directional light shine equally in all directions from a local source point found in local game space instead of this infinitely far away cone of light.
An example would be to be able to make a BP with a sphere and slap a directional light in there which then shines in all directions and isn’t dependent on angular rotation to be able to shine on the game world, with the source of this light being reachable in local game space, fully (or as much as possible) replacing the standard directional light.
I’ve tried just using the point light and increasing its range of light and power output but the shadows look strange and its just not enough illumination, if i make a mini sun and put a point light Im forced to place it really close to get it to illuminate the surrounding. Even with it really close to a planet or landscape the game behaves weirdly when global illumination is made this way and many features dependent on a directional light don’t function.
the question here is what are the visuals you trying to achieve? like a planetary system looked at from the surface of earth or inside a space ship? you could noodle an unlit material that takes a vector input for the “centered” sun position and you compute whatever lighting you need yourself.
Just to make sure I’m understanding correctly, you mean to achieve what I want through the material shader system bypassing unreal traditional lighting pipeline entirely?
Would the image I included explain what my visual goal is? For added context this is for a game.
Do you mean to do something behind the scenes in the source or just the normal material BP nodes?
When you say compute the lighting I need myself what do you mean? Would you mean something like getting distance based falloff to work from the material if that is a feature I want?
And for the vector, since my goal is omnidirectional equal lighting would a position vector be the solution, meaning the farther away the less light. Would there be issues with shadows and other glitches?
It’s not possible with a directional light because that’s not how it works.
You could effectively write your own shader but you have no good way of handling cast shadows.
Probably the easiest option would be to have different lighting for space and planetary views, so that when you’re on the planet you switch to a directional light to get proper cast shadowing, when you’re in space you use your own lighting done inside your materials.
I did think the shadows would get destroyed through using a shader.
What about altering source code, the most I’ve done is just look at the set up for point light and directional light, but I’m a complete beginner is this area of unreal engine.
I’ve already organized to learn c++ and engine coding, if you think its even 0.0000001% possible, I’ll use this idea as practice to apply learnt theory.
With the design of the game I’m making players are able to alter the colour of the sun during runtime which alters the rest of the game world, having multiple lights is doable, just gotta make sure they all update to the change of colour but I’d prefer a central omnidirectional light source
On second thought and with a bit more info, I think I’ll leave this problem for a future me with future knowledge and experience and focus on other parts of dev.
The directional light is hardwired to not be changeable by the looks of it, and a point light source code upgraded would be infinitely more expensive and shadows would look like trash.
Your solution is the best solution before an alternative is found.
For future reference when you do decide to circle back to this:
The main issue is with how shadowmapping works, essentially the engine renders a set of depth maps from the position/angle/fov of the light (or just angle in the case of the directional light) and the depth map is then used when evaluating the pixel shader to determine whether the pixel is in shadow or not.
The issue with this is that on spherical light sources like point lights you have a finite texture resolution for your shadow depth map which you need to cover the entire radius of the point light, when you’re close to the light you don’t need as much angular resolution so this problem isn’t very noticeable, but as you get further and further from the lightsource, each texel of the depth map has to cover more and more area and the lack of resolution becomes very apparent and difficult to deal with.
Directional lights have a similar problem with distant shadows, but the way this is solved is by anchoring the capture position to the camera and the shadow depth is captured using ortho projection as the light is assumed to be so far away that the rays will be parallel. This means you don’t notice the loss in resolution in the distance and the capture point of the directional light doesn’t matter, only the angle and height.
It might be possible to do some graphics sorcery to get shadowmaps to allocate resolution more efficiently but this is beyond me (in some ways this is kinda how virtual shadow maps work). I would suggest looking into other options that don’t use shadowmapping, such as hardware raytracing, raytracing distance fields, or screenspace shadows. Unreal already has all of these built in (though they will need to be modified to do what you need) that you can reference.
well… you can crank alot more out of the engine, if you know how.
i used the 0, 0, 0 for the shader math. avoids all the direction math trouble in the shader. sun position approximately synced with the directional light angle, for demo purpose. cascaded shadow map is at 0. i coulda added some cascade shadow for the manny in the scene, tho.
i cranked the distance field shadow distances up to create the eclipse beyond shadow map distance. mars is using the “manual point light” calculation. i could put it anywhere and it would always be lit from the center. material is unlit for that very reason. it receives no engine light, but what i calculated manually. and it casts shadows.
so if this was a planetary thing you would always have to calculate the directional light angle to be able to hop planets. you compute the vector towards the center and invert it to get the directional light vector. for the space view you use the manual point light shader.
I got too hasty in letting go of this idea with hearing from so many sources say how impossible it was to do this (even had peeps in discord channels saying this is a pain to achieve) and I felt like moving on from this was a good idea, but I dislike letting go.
Let me not tap out just yet then.
Simply, most of what you’ve told me is super foreign so I’ll start by learning about most of the things you mentioned and how the engine handles them.
I appreciate the information you’ve shared as it gives me a direction to go look and study my options which I didn’t have before which also makes it easier to apply any theory I may learn from the courses and info I intend on absorbing.
Between a point light and directional light would you say the point light would be more flexible to alter and achieve what I wish to achieve?
Could in theory the texture resolution be increased on a point light regardless of expense and use the method of anchoring the capture position to the camera and use ortho projection capture? Since the point and direct light have distance resolution loss in common.
I’ve already done something similar to aligning a sphere as a sun to the directional light’s direction, I’ll apply your material solution and see how it looks, thank you.
This is in essence an illusion of omnidirectional light right? I ask this because if the player were to be placed on mars for example the lighting would not function as it does on the silver platform/terrain you’ve demonstrated, correct?
Would maybe a solution like collision triggers setting the directional light of the sun to update to the direction of the planet triggered on player collision work?
I have gravity fields implemented that use a collision sphere to update player gravity to a select planet which I could use to update the sun maybe. But lighting follows the player when in the middle of space after exiting a collision sphere. Cause if the sun always follows the player it could look weird when on a planet and day and night cycles would be strange too.
yes and no. it computes the sun light that you would see from the space perspective. it’s not an illusion tho. it’s an “accurate” direction, cause it’s based on the fact that the sun is in the center.
and… i’ve been a lil intrigued and noodled the triggered stuff. the light direction, material and gravity switch. the gravity has no tick update to reorient itself and the camera is pretty f-ed, but the switch completely works. the shadows are on the planet where you are and the other has the space version of the material.
in a slow approach or distancing scenario, you probably should use some more shader tricks to transition the material switch. i mean… the sun light angle should be accurate either way. but the shadows will pop in or out if you choose the wrong distance for the switch.
also… you can add more graphics to the space materials, but you have to code all the shading yourself. this is the fun part tho, imho. if you like shader development.
