Cool, cool, cool.

So can you just give a quick explanation of how the system for lights works right now?

I have a tiny thing set up to show.

So I'm first going to show the problems with lights.

I'm totally not using our first of April settings.

So here we have a beautiful statue and these are like

50

lights overlapping.

So if we show our performance,

it's uh it's kind of that we're running at less than 30 fps even though not much is going on here

that was great

yeah i know i love the floating floating peeps so the first thing we did an engine upgrade to 25 i think which gave us a nice future which is the rendering threat the rhi threat which gives us tons of performance back already the rhi

stands for Rendering Hardware Interface, which is Epic's solution for different rendering APIs.

And with the engine upgrade, we are allowed to use a separate thread for this.

So partially the work is offloaded to a separate thread instead of only on one thread.

So this is acceptable now.

So now we can go to stage two of the explanation.

So the second thing we did with light is normally you would use inverse square falloff.

which makes the light look pretty realistic.

But the problem is they lose a lot of intensity.

So instead of that, we are using no falloff.

So the light is the same strength as the beginning as the end, which allows us to have the right distance for the light.

So they are way less performance impactful and they need to overlap way less to get intensity that you would desire.

Right.

So they're not like realistic in the sense that most other lighting in the game is, but they kind of need to make sense for the users.

Yes.

And here we see the example how it works with a ceiling light.

So we slap a cookie cutter on it, called a light function, and then we cut out a square.

So it's technically this light, but we just cut out the other parts.

Right.

And then the biggest issue with the light is shadows.

So let's go to the

Shadow part.

So we have three options.

No shadow casting, which looks disappointing.

There's absolutely no shadows from anything.

The second option is cascaded shadow mapping.

This is the classic way of doing it.

We have been doing that ever since, I don't know, 2005 probably.

It's expensive because just imagine the light being a camera.

It looks what is visible.

and then makes a depth map and project the shadows on the world that way.

So the more objects the light is hitting, the more expensive the shadows will get, which is absolutely not ideal in an infinite builder game.

And then we have the last option, which is distance field-based shadows.

It has some downsides.

Our conveyor belts are not shadowed, unlike in this case there.

There are shadows from the conveyor belts.

That's why we use the mix solution for the directional light.

And as you can see, some shadow artifacts will pop up.

And that's because distance fields are technically a 3D texture of the mesh itself.

So if I quickly eject, this is the distance fields for those objects.

They look a bit funky, but

It's easier for the GPU to calculate it because it's just direct information there.

It doesn't really need to do much culling because it's GPU-to-GPU data

that

is like 25% to 50% faster, especially with the rendering, the R HI thread that made it even more fast.

So yeah, that's why we're using that.

So you mentioned that conveyor belts aren't using distance field.