#would changing the scale factor of it
1 messages · Page 1 of 1 (latest)
Shadow resolution, distance and cascades operate in world unit scale, so generally bigger geometry should get better shadows
I'd check what your quality leve's shadow settings are
Your shadowmap resolution looks to be 512
Default high quality asset seems to consider "medium" to be 1024
Cascades look fine, although the smaller your max distance is, the more resolution the shadows get
125 is the closest i can get it to render shadows base on where my camera is to the object im trying to cast them on
The scene does place limits on that variable
In that sense
Just so you know "shadow atlas" is the map where all the shadow caster shadowmaps will be compiled to
Did you yet try rotating the light source?
Yea, didnt effect anything
The pixels of the cast shadowmap are in relation to light rotation, as if it were a camera
it fixes the jags on some places, then gives jags some other places
(rotating light sources on the Z)
Ye, it's a situational tradeoff thing
But in some very specific cases can make a huge difference
Going back to this: is this a problem?
Should these things be changed
Yea, try setting the high resolution tier to 2K for example
Those are the default setting presets you might expect the user to choose from options, or which you might want to enforce per platform
Each settings asset defines resolution tiers for shadowmaps
Such as my URP-HighQuality here
Each light component can choose from those tiers, or define its own
I'd try to bump up that light source's resolution a bunch to see if that fixes it
Either with custom or by defining a higher high quality tier
well, good enough, its smooth enough at a distance
Which the documentation advises about as
A high Bias value makes the shadow appear “disconnected” from the GameObject
hm odd.
it says URP_High here.
but if i change the render scale of my URP_GODLIKE asset, it changes the render scale
So what gives
They still look kinda blockier than what I'm used to seeing
Could be wide spot light weirdness, or something else
How do i know what is actually being used in the editor?
i would think its godlike... but that light says otherwise
I believe the quality setting the editor uses is the one you selected last in that list, not the one marked green for default
You tend to always get problems if you stray from default bias settings, which I believe are 1 for both bias and normal bias
I think ths is good enough in all honesty, it looks smooth at this distance
Looks just about totally fine to me
You might still get light leaking through corners of meshes
Which is the exact same issue we discussed back in june if you recall
Yea i remember, why does lighting in unity have so many caviats
when i used Unreal, it was just dead simple and just worked normally out of the box
It's all raster renderers
They either suffer from it or are trying to work around it
Unreal has a lot of clever systems and workarounds for these kind of details, but I guess that's what makes it harder to strip down and generally heavier to work with
Thank you once again for the assistance my friend
How would you fix this one?


If they're only at select places, then extra shadow caster geometry should work
But if there's a lot all over, especially when using low-poly meshes, it may be better to instead use a shader that allows smooth-shaded geometry to be rendered with flat normals
what is "extra shadow caster geometry"?
So it appears as solid and continuous to the shadow caster, but as flat-shaded to the viewer
Just boxes or geometry of any shape stuffed in to prevent the leaking, preferably with smooth normals and shared vertices
Aaa i see! Fake it till you make it
Is there a standard shader that allows that?
but indeed, i always used shadow casters for this kind of problem
Nope
@sonic sinew https://hextantstudios.com/unity-flat-low-poly-shader/ here's one type of instructions for it
thx
https://cdn.discordapp.com/attachments/988460523328774214/988464293668323438/FlatShading.unitypackage
I think this is the version of it that we used before
AleksiH did some magic to add a fix for floating point errors
