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.
This is godly and very much what I want even its not messing with the directional light thingy.
Would it be ok for me to ask and would you be open to share how you achieved this, even including little obvious details would be appreciated as I only have a little over 1 year under my dev wings.
I could probably figure it out though as you’ve already shown me the material setup but still I would very much appreciate the guidance.
And just by the way I didn’t mean any disrespect with saying illusion it was just because I’ve seen elsewhere a technique like this that’s “illusiony” in its implementation and I just didn’t completely understand your solution, apologies if it came off that way.
when you leave (end overlap) a planet (trigger sphere around it) you change the material to the space variant with the point light shader and disable gravity.
when you enter a planet (begin overlap) you change the material to the world (with directional light) compute the gravitiy vector and enable gravity.
the computation of the directional light vector could essentially be put into the player tick function or you compute it on entry (begin overlap) and point it at the planet. this is a piece of code you could recycle as a function. just give it the location input. if the sun was somewhere else you just do the math with this location. in this case you’d have to feed the sun location into the space material tho and compute a subtraction instead of the 1-x i did for simplicty.
Hello I’m back to work on my project again, sorry for disappearing, so I did as you said, I got the material to work with a Sun placed outside of 0,0,0 and I got the directional light to update but for some reason in the overlap BP at the cast to static mesh actor node to change the material of the mars planet which I just called Sphere22 for testing purposes it fails to cast, would you have any idea why?
did you actually tag the static mesh? it’s not searching for the plain name of it. it’s a specific tag. that’s in the details section of the actor. alternatively you could add a static mesh component to the blueprint and load it directly. i’ve just done a quick level blueprint to test the whole mechanic. a dedicated “planet” blueprint and some logic would be appropriate. up to you to develop that. do your gamedev thing and integrate it into your logic. i did just prototype it.
and well… shadows are limited by the cascaded shadow map resolution. the further you are away from the camera the smaller the shadow resolution. that is to be expected. you gotta get the camera closer for better shadow quality or mess with the distribution bias or perhaps the csm resolution. raytraced shadows do work aswell, but you’d loose the distance field shadows and cannot set any distance to get the eclipse effect. if you don’t need that, it’s an alternative you have.
