Nice to see you here again! Beautiful indeed. I feel like the third one could be some subconscious nightmare level in Earthbound or something.

Kinda looks it, to be fair

Sounds good

Sorry, but it's all rigid ceramic or something. However I have more papery jellyfish-shaped lanterns in mind for the café with decorations (kind of like Christmas tree bulbs) on strings representing tentacles, that would move in the wind a bit like wind chimes. Turns out similar things already exist! https://www.istockphoto.com/photo/paper-lantern-jellyfish-shaped-hanged-in-porto-street-among-hous-gm868546844-145174927

Have a street lamp!



Besides all the water running through town and driving things, it's also a geologically active area with all manners of steam and gas escaping the earth, getting put to use for heating and lighting through pipes under the ground.

Love the walking trees! Enjoying seeing more stuff moving in general, even if the environments are as pretty as ever.

The white blobs in the last picture read as creatures or people in a foetal position to me, is that intentional?

Another good video! The "wihu" thing made me wonder if you've given any thought as to how you'd deal with localisation if you're basing riddles on English words. Would you just change the spells?

Ahh, technical stuff! Could probably get used to it, but would it be horrible to just not disappear at all behind right-facing walls?

Thank you! I just enjoy pretending to be a gamedev of the nineties or something

So after some technical issues with the shadows I got worn out and took a break again, and then finally came back the other day and figured out a solution that at least works so that I can move on to something else for now, so we'll see what's next! I was just about ready to get back to writing for a change, but getting unstuck on this may have given me my coding motivation back.

Stuff's looking nice, descriptive commits or not

I do feel like disappearing behind right-facing walls could be a bit confusing, even if it's consistent with appearing in front of them on the other side, perspective and all. Have you given that any thought? o:

Nice to see you posting again! Looking good.

[EDIT:]

Thanks for giving it a go! Sounds like I will have to provide some code after all.

Finding the points in world space of the subfrustum for a cascade (FOV is in radians, a Scalf is just a float):

Code:

auto const
planes([this, &pass](std::size_t const i) -> mth::Scalf
{
return
(
pass.camera->projection().near +
(pass.camera->projection().far - pass.camera->projection().near) *
cutoffShadowmaps(i)
);
});

mth::Scalf const
width {static_cast<mth::Scalf>(pass.camera->viewport().x)},
height{static_cast<mth::Scalf>(pass.camera->viewport().y)},
FOV   {pass.camera->projection().FOV * 0.5f},
tanHor{mth::tan(FOV)},
tanVer{mth::tan(FOV * (height / width))},
xNear {planes(indexCascade + 0) * tanHor},
xFar  {planes(indexCascade + 1) * tanHor},
yNear {planes(indexCascade + 0) * tanVer},
yFar  {planes(indexCascade + 1) * tanVer};

data.frustum[0] = { xNear,  yNear, planes(indexCascade + 0), 1.0f};
data.frustum[1] = {-xNear,  yNear, planes(indexCascade + 0), 1.0f};
data.frustum[2] = {-xNear, -yNear, planes(indexCascade + 0), 1.0f};
data.frustum[3] = { xNear, -yNear, planes(indexCascade + 0), 1.0f};
data.frustum[4] = { xFar,   yFar,  planes(indexCascade + 1), 1.0f};
data.frustum[5] = {-xFar,   yFar,  planes(indexCascade + 1), 1.0f};
data.frustum[6] = {-xFar,  -yFar,  planes(indexCascade + 1), 1.0f};
data.frustum[7] = { xFar,  -yFar,  planes(indexCascade + 1), 1.0f};

mth::Mat4f const
transformCam{pass.transformCamera->matrixGlobal()};

for (std::size_t i{0}; i < data.frustum.size(); ++ i)
data.frustum[i] = transformCam * data.frustum[i];

Using them to calculate the projection matrix for a light's camera (the view matrix is calculated same as for any camera based on its transform which is set at the world origin with the rotation of the light at the end of this code):

Code:

constexpr auto
calcBoundsFrustum([](std::array<mth::Vec4f, 8> const &frustum) -> mth::Bounds3f
{
mth::Vec3f const
xyz{frustum[0]};

mth::Bounds3f
bounds{xyz, xyz};

for (std::size_t i{1}; i < frustum.size(); ++ i)
{
bounds.min.x = mth::min(bounds.min.x, frustum[i].x);
bounds.max.x = mth::max(bounds.max.x, frustum[i].x);
bounds.min.y = mth::min(bounds.min.y, frustum[i].y);
bounds.max.y = mth::max(bounds.max.y, frustum[i].y);
bounds.min.z = mth::min(bounds.min.z, frustum[i].z);
bounds.max.z = mth::max(bounds.max.z, frustum[i].z);
}

return bounds;
});

mth::Transformf t{};
t.rotation = tr->global().rotation; // tr is the light's transform

mth::Mat4f const
transformLight{mth::inverse(t.matrix())};

std::array<mth::Vec4f, 8> const
frustum
{
transformLight * data.frustum[0],
transformLight * data.frustum[1],
transformLight * data.frustum[2],
transformLight * data.frustum[3],
transformLight * data.frustum[4],
transformLight * data.frustum[5],
transformLight * data.frustum[6],
transformLight * data.frustum[7]
};

mth::Bounds3f const
bounds{calcBoundsFrustum(frustum)};

data.camera.matrixProjection
(
mth::projection::orthographic
(
bounds.min.x,
bounds.max.x,
bounds.min.y,
bounds.max.y,
bounds.min.z,
bounds.max.z
)
);

data.transform.local(std::move(t));

Simplified version of shader (deferred, fragment position reconstructed from depth buffer) starts with this:

Code:

vec4 uvShadowDir = _projShadows[indexShadowmap] * _viewShadows[indexShadowmap] * vec4(position.xyz, 1.0);

For a regular sampler2D I did this:

Code:

float z = uvShadowDir.z * 0.5 + 0.5;
float zShadowRaw = texture(_depthShadows[indexShadowmap], uvShadowDir.xy * 0.5 + 0.5).r;
float shadow = (zShadowDir < z) ? _darknessShadows : 1.0;

Which had the same issue. However I'm currently trying out sampler2DShadow so now it looks like this:

Code:

float shadow = _darknessShadows * texture((indexShadowmap == 0) ? _depthShadows0 : _depthShadows1, (uvShadowDir.xyz * 0.5 + 0.5));

(those samplers won't work in an array for me so I have a hardcoded ternary for now)

- Is your shadow depth cut off? I often have the problem that even though any doc claims that Floating Point RenderTargets can carry any value, all my shader output is clamped to 0..1. That's why I normalize my shadow depth. Maybe you're in OGL and your shadow depth is -1..+1 and is clamped to 0..+1?

Yeah, I'm in OpenGL and using a depth buffer for this so not a "custom" float buffer. Should be 0-1.

- Maybe your cascade selection in the main pass takes the wrong turn? The first image shows a shadow from a build to the left, starting at the left, then a gap, then re-starting at the yellow ground. If your SM texture coords would be set to clamp, such a building would continue along the ground.

Buffer is set to clamp, but I also have this:

Code:

if (abs(uvShadowDir.x) > 1.0 || abs(uvShadowDir.y) > 1.0 || abs(uvShadowDir.z) > 1.0)
shadow = 1.0;

Because without it I get weird results sometimes (but this probably gets automatically resolved once this whole thing gets figured out?), like this intrusive shadow from nothing on the left:



If I colour it yellow if that if is true:



One thing I have noticed is that in many SM implementations the splits seem to follow the direction of the light instead of the direction of the main camera like I do (and the tutorial and most others AFAICT), is that something I should be doing? Or should this way work too?

EDIT:

Used the if to filter cascades instead of the distance along the main camera frustum, which does at least ensure that it switches cascades when another doesn't cover any more area, but it seems clear that the matrices must still be wrong? Again red is near cascade, green is far cascade, and darkened areas are not covered by any cascade.



The debug lines are again the boxes around the frusta aligned with the light, but this time of the camera I'm actually rendering from.

( shadows flickering in and out is a GIF issue, as long as the area is red or green there are shadows where they should be )

EDIT 2:

So embarrassingly I got some of the matrices I was juggling mixed up and I was passing the wrong one in in some places. Turned out the bounding boxes were never fully aligned with the light. But there were still issues even after I fixed that, depending on the angle and such.

Before and after:


Doesn't make sense to me based on what I thought I knew, but the projection matrix likes it a lot more if the view matrix is positioned in the middle of where I want to focus and the projection matrix bounds are neatly distributed evenly around that point. But even that was not a perfect guard against angular issues.

In the end I decided to just drop what I'd read and do something that makes sense in my own head (with inspiration from this video), so at least I'll have something that works for now, which is this:

For each subfrustum I figure out which is greatest of the far plane width, its height, or the distance between the two planes, and I use that as the size of the bounding box in every direction to get a perfect cube around the middle of the subfrustum. I then multiply those extents by √2 to cover its maximum AABB at a 45° angle. That way I'm sure it always covers the whole subfrustum regardless of the angle of the light or the camera; it's probably a bit wasteful but the shadow maps always have the same texel size which according to the video helps reduce against "shimmering" anyway so it seems okay.

So I still don't feel like I've learnt how to do this the "proper" or "standard" way or whatever but at least I came up with one of my own that works so that's good enough for now:



Nonetheless, I'd still love help to do it "right" if anybody knows more about it all…

[EDIT:]

Hey! Implemented shadow maps a while ago, been working fine, and tried to turn them into cascaded ones based mainly on this tutorial:

https://ogldev.org/www/tutorial49/tutorial49.html

I haven't just followed it, I'm sure I fully understand it too, but I can't for the life of me seem to get it exactly right. My maths should be the same as here, just adapted to fit the camera setup and so on already in place in my engine, but depending on the camera angle the shadow maps cut off:



For comparison, here's an angle that's not as bad:



There are two cascades; red is the nearer one and green is the farther one. I've kept the shadow acne in to make it easier to see the bugged cutoff points clearly.

Since I'm quite sure that my maths is the same as in the tutorial (and GLM deals with the specifics of calculating the ortho matrices based on left, right, top, bottom, near and far inputs) I'm not sure it's necessary to share my exact code…

I guess I'm wondering if the tutorial is correct in the first place, and if so if this kind of behaviour is expected using its method? Seems to me the resultant matrices should fully cover each subfrustum and not leave cutoffs in frame, right? I've enabled GL_DEPTH_CLAMP for the shadow map cameras.

To be clear I'm not talking about shadows getting cut off because their casters are not in the shadow map camera's frustum, but given that the acne also gets cut off the orthographic matrices (based on the light space bounding boxes of the main camera's frusta) for the cameras seem to be wrong in the first place…

If not, is it obvious what I might've done wrong? Will share code if it does end up being necessary. Thanks!

EDIT:

Might be clearer to see where I'm at with a GIF. Only one cascade here, I tied it to a separate camera object in the scene instead of the camera used to render the scene, so you can see what's happening from the outside:



The box around the frustum aligned with the light seems correct, always containing it? Here I've multiplied the points of the box with the inverse light view matrix to get it back to world space. The values I'm using for the shadow map matrix are the values before that, as in the tutorial.

I wonder if it could be as simple as having doors you can enter be open, and doors you can't enter (but enemies can come out of, with a brief open and close animation) be closed.

Ohh, when you first talked about a camera I thought you were gonna work on the game camera This is a cool and unexpected mechanic, all the rest of the graphics gave me the impression of this being in some non-technological setting.

Runs fine in my GIF's because I record at a very low resolution, but it doesn't scale well at all

Turns out I'm a big dumdum!! I'd never get anything done if I didn't do things quick and dirty first to get it working at all, but sometimes I move on and forget to go back and actually fix things like that. Was doing a really expensive shader calculation for every pixel on every object that I only needed to do once per object but which is slightly more work to do properly so for testing purposes I'd done it this way. Still a lot more things that need to be optimised to get it to run well but now it's just many small things adding up, no one big thing like this. Even the tree rendering is fine now.

Yaaaassss

Think I'll stick to C++ for things like that Happy enough with the octree tho!

Cool! Is this what they call "frustum culling"?

Yeah! c:

Worth it, I think! The blur looks really good, really helps sell the microscope effect.

Yeah, I reached the point now where I have to bother. Runs fine in my GIF's because I record at a very low resolution, but it doesn't scale well at all, especially with shadows, at least on my GPU. It's not just my game, it's commercial games too where I generally have to run on very low settings, so I figure if I can make it run well on here it'll run fine on a lot of machines hopefully (and it should be possible as my Unity jam games run well thanks to whatever that engine's doing under the hood which is probably stuff like this). I have a bunch of RAM and a decent CPU but my GPU is a big bottleneck

The octant lookup (octree) will be useful for optimising other stuff too, like the photography mechanic which also checks what's in the camera frustum, or checking for things close enough to interact with without looping through all of them and so on.