lights turn on and off depending on camera

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By tproper

I’m working on a project that includes torches. I’ve made them out of a small particle system and an OmniLight (one per torch). I put a few in my scene. I can look directly at the OmniLight and I see it’s effect on the terrain around it, but when I look down some, away from the light on the top of the torch, the light ceases to show on the ground like a switch was just flipped and it went off.

There’s no code behind the torches. They’re a simple scene saved to be instanced in my main scene.

Any idea why they would behave like this?

:bust_in_silhouette: Reply From: MysteryGM

It is the Godot light manager turning them off.

Old OpenGL could only do 4, modern OpenGL can do 8.
The interesting part is that every object has it’s own support for 8 lights. Meaning the more objects is in a scene the less noticeable the problem is.

Every object will calculate it’s lights based on the ones nearest to it and the camera.

For the floor a grid like structure can be used to allow more lights:
enter image description here

Also large lights add to each other, obscuring the problem.

Thanks for the quick answer.

You say :

For the floor a grid like structure can be used to allow more lights:

How do you mean? I have a terrain I made in Blender. It’s rather big and the scene is really dark. I was hoping to be able to light the scene mainly by torches that the player places. How would I go about making the floor a grid to allow the player to place more lights without seeing this limitation of lights? Chopping the terrain mesh into segments doesn’t sound like what you’re saying would work…

tproper | 2018-09-26 12:33

Actually, I think that’s what he’s pretty much saying. By chopping the terrain geometry into more smaller pieces, Your terrain can pretty much support more lights.

Eg:

  • 1 whole terrain chunk can support up to 8 light sources.
  • But if you chop it up into a 3x3 grid, 9 terrain chunks, each of which can support 8 light sources, then as a whole it can now support nine times the amount light sources (72)!

Breaking the terrain up into chunks also has another benefit.
It can reduce the amount of vertices that need to be processed, since Godot automatically culls away individual objects in the CPU.

SIsilicon | 2018-09-26 14:06

Also, there is an add-on in the asset store that is meant for managing terrain. Maybe you should use that in your project instead.

SIsilicon | 2018-09-26 14:09

Thanks guys! I was hesitant with that idea but it’s easy enough. I’ll look into that add-on as well.

tproper | 2018-09-26 14:22

So I’ve been working on splitting up the terrain. As I was working on it I thought of something and tried it. I tried adding 8 lights onto the Root node of the scene, then when my number of lights reached 8, I created a new spacial node which then I used to add more lights to. Shouldn’t that work? It’s a different object which I thought would give me 8 more lights. Why doesn’t that work?

I suppose I’m not completely understanding the difference between adding lights to the terrain chucks vs adding lights to new nodes I create.

tproper | 2018-09-27 15:27

Each MeshInstance, or anything else with a renderable mesh, can only be effected by 8 light sources. Where the lights are placed in the scene tree doesn’t matter. Here’s how you should see it. In the shader that your terrain’s material uses it has a uniform array. This array contains light data and in this case has a fixed length of 8. What Godot does is figure out what light sources in the scene should fill up this array. So no matter where you put the lights in the scene tree, each mesh will always only be able to handle up to 8 lights.

Remember when I explained how splitting the terrain into chunks allows more lights? Well that’s because each mesh(the chunks) can still handle up to 8 lights. So technically I didn’t change how many lights the terrain can support. " I’m terrible at explaining things. T_T "

What I suggest you do instead is whenever you place a torch, check if the current terrain chunk has more than eight torches. If so, break that chunk up into 4 smaller chunks.

It would be best to manage these chunks as quad trees.

SIsilicon | 2018-09-27 16:53

I was able to do what you were saying: adding the torches to separate meshes, yet still the lights are limited. Here is a screenshot of the game and the scene where you can see the torches are in the correct spots (I think).

enter image description here

enter image description here

The two torches closes to the camera aren’t lighting anything… Not sure what I’m doing wrong.

tproper | 2018-09-27 22:58

Could upload the project so that I can see this in more detail?

SIsilicon | 2018-09-27 23:22

Heres a link to a stripped version. Maybe you could look at the TreeGenerator.gd as well to see why trees are being placed in the terrain.

B to build, 2 for torch
L to turn lights on

Keep in mind this is my first Godot project so it’s a mess.

~34mb file Tower Game

You may notice the terrain cuts are odd. I couldn’t figure out a clean way to do it. Any suggestions of creating large terrains with sections like we’ve been talking about, I’m open to ideas.

tproper | 2018-09-28 00:09

34 MB wow.

Well I’ll have to look at that on Saturday 'cause right now, I’m using data connection. I’ll have to wait until I’m in WiFi. K?

SIsilicon | 2018-09-28 00:13

Just realized I had my entire git repo in that. Here’s a 7mb version. Project

tproper | 2018-09-28 00:19

Still have to wait. Don’t worry I’ll eventually open it.

SIsilicon | 2018-09-28 00:36

No worries. I have lots of other things to work on. Just the lighting and terrain felt like the basic start of it… so I was feeling a bit discouraged. Cool. Thanks so much for all your help!

tproper | 2018-09-28 00:41

In the mean time you can work on your game mechanics. That’s very important.

SIsilicon | 2018-09-28 11:23

I changed the terrain in the project. The old one had some issues. Still having problems with lighting even though I’ve limited the number to 6 lights per mesh. Updated a new version of the project (6mbs) here.

(the static bodies for all the terrain chunks aren’t done yet so stick close to the spawn area)

tproper | 2018-10-01 14:45

Well I see that you attempted to break it up into chunks, but you are not doing it dynamically. And since you already went so far in the coffee with this, it’ll take me a while to change that. Also, with the torches covering such a large range, there isn’t much you can do about the lighting limitation.

SIsilicon | 2018-10-01 18:15

Is there another way to break that terrain into chunks? And the torches don’t need to have such a large range. I only have them so high because I was thinking the larger they were then the less you would be able to tell the lighting issue. They can be smaller, I’d actually prefer them smaller…I have the terrain as a non broken file as well but I didn’t know of any other way to split it up other than just having multiple obj files. And no coffee was involved, just figured I’d play around with it and maybe learn something - even if it is the Wrong way to do it.

I was thinking of limiting the player and not allowing them to put the torches too close together but I don’t know if that would help…

tproper | 2018-10-01 18:23

Coffee → code. Stupid autocorrect. >:(

Anyway, what I’m trying to do in code right now is to build a mesh splitter. Whenever the terrain chunk gets a new torch, it splits. And those new chunks will each be given those torches in a smart way. And yeah the smaller torch range the better. I’m also messing around with storing the terrain height in a texture.

SIsilicon | 2018-10-01 18:31

Wow. Thanks for continuing to help. Just one thing, could you make sure to comment what you are doing (I’m sure you are but think of me as very beginner needing over explanation).

Mesh splitter sounds cool. Didn’t know you could do that. You must have been using Godot for a while or are just really knowledgeable!

I’m a programmer professionally but have rarely tried game developing so it’s all pretty new to me.

tproper | 2018-10-01 18:39

Ok, I’ll think about you when commenting them.

SIsilicon | 2018-10-01 18:56

Hey, Sisllicon. How’s the mesh splitter and lighting coming? Working so far?

tproper | 2018-10-04 12:37

Well, ish? I’m actually kind doing other things as well. Sorry. :-/
Are you still working on the game?

SIsilicon | 2018-10-04 21:30

Yup. Working on a rough AI now.

Could you maybe give what you’ve got so far so I can get an idea of what you’re doing and how you’re doing it? Then maybe you wouldn’t have to do so much work. Don’t want to keep you from other things. Just the lighting plays a big part in the type of game I’m wanting, so I need to know if it’s possible or if I’m going to have to rethink some things.

tproper | 2018-10-04 21:52

So where do I go to make a pull request to your project? So that I can share the method I used.

SIsilicon | 2018-10-05 14:12

I have a personal private bitbucket account but I’ve never shared anything for pulls and do not know how all that works…could you zip it up and send it to

tissproper at gmail dot com

If not then I’ll have learn a little more about repos. I usually just use them for source control and reverting when I need to.

tproper | 2018-10-05 18:07

Ok. It should be in your inbox now.

Note that the maximum number of lights per chunk/quad is 3 for easy debugging. Set it to 8 for your game. Also you can jump super high so that you can see the ground from bird’s eye view and place torches from there. Hope I did good with the comments.

SIsilicon | 2018-10-06 21:14

Ok! I’ll look at it soon!

tproper | 2018-10-06 21:47

How’s it going?

SIsilicon | 2018-10-07 16:07

Good. I’ve looked at what you’ve done. It may take a bit for me to fully understand. It seems to be working the way I’d like. I’ll need to look more into it.

I’m currently working with navmeshes and seeing if it’s possible to rebake a navmesh at runtime to update when you add torches and stuff so AI will avoid new obstacles. I’m beginning to think that updating at runtime is not possible, though…

tproper | 2018-10-07 17:01

Yeah I saw your question about that. Too bad I don’t have an answer.

SIsilicon | 2018-10-07 21:24