Godot 4.3
I have a question about OmniLights3D. Is it possible to have real-time cast shadows disabled but still prevent light from passing through walls?
I am trying to minimize shadow rendering to make my game run on lower end hardware.
AFAIK not really, reduce the light’s range and/or disable it when it’s not visible. Other than that you’ll have to use lightmaps.
1 Like
When I was making mods for the original Deus Ex, (that game is 25 years old already) light passing through walls was never a problem, despite not having the technology at the time for cast shadows. It just wonder how they did it.
Usually the answer is lightmaps (automatically generated by the level editor tool).
1 Like
That’s right, the walls were created using the level editor tool and they were different than other meshes that we imported from external 3D modeling software.
shadows in godot are put into an atlas, it doesn’t matter how many lights you have on a scene.
you can reduce the memory used by shadows, which could also improve performance and fit into lower end machines.
you can make shadows not update which would increase performance, you would loose shadows on players.
1 - not all lights need shadows, you can make lights smaller to the point where they cover a surface but don’t need to cast shadows.
2 - you can make lights the size of a room to light only that room, reduce attenuation to cover the edges of the light sphere.
3 - you can use shadows only on parts that involve the player. an example of this would be a street light, where the player would cast shadows on the ground.
4 - you can design the levels around these limitations. you can make the level open and at daytime so that only one light is needed (the sun).
you can make thick walls so you can make lights bigger while preventing light leaking.
you can make levels with odd shapes so that there are no parallel walls or rooms.
5 - you can use textures with different tones to simulate shadow. Alien Vs Predator 1 did this, in some parts animated textures where used that switched between lit and dark, and these where alternated to create an effect of dynamic lights. Doom also did this, it had parts in shadow and parts that were lit.
the 1999 one?
those games used tricks and level design to prevent issues, while others like CS and Quake used baked light. I can’t tell about Deus Ex. was it unreal? if that’s the case it might’ve used baked shadows.
another possibility is that it culled lights that where behind walls.
1 Like
Thanks for the suggestions.
Yes the 1999 Deus Ex. It used a very old version of the Unreal engine.
Light occluders would be nice to have in Godot.
it was unreal 1, the 90s wasn’t that long ago…
the internet is too polluted to find any useful technical information these days, I looked around but was not able to find out what rendering method were used by unreal 1.
looking at some pictures:
deus ex is using blob shadows, these are achieved through a decal under the characters or things that must move, and can be replicated in godot.
objects in the scene do not cast shadows, which rules out baked lightmaps, which were used by Id tech 3 engine games like quake 3 and half of the games from 1999-2004. and half-life which was based on id tech 2, used by quake 2. and quake 2 and quake 1.
there are shadows on the edges of geometry, which could be achieved through a shader. in godot you can just use SSAO for the same effect (and better).
there’s an extensive use of “ambient light”. this is a result of the T&L lighting system and tricky to reproduce but not impossible.
I’m getting something… I think this might be lambert shading, which can be selected in StandardMaterial, or can be very easily replicated in shader.
you matrix multiply VIEW with face NORMAL and color multiply it by the texture. it’s a good idea to ignore ambient light or disable it.
in these levels they had two types of lights: point lights and area lights.
point lights are used with objects that must cast light (and shadow), like a lightbulb.
area lights are used to add ambient light or draw shadows, they are placed around the map and usually colored, they are meant to light the dark parts of the map when there is no light source and for decoration.
you could try to put the lights on different layers so that a light affects a room but not the room adjacent to it. But this idea needs some testing.
1 Like
Screenshot from DX1 I just made:
There are some shadows though which vanish as soon as you use your flashlight, so my guess is they still use some kind of lightmaps. I don’t know how dense the geometry is, otherwise I’d just guess they use some vertex lighting tricks. And yeah, crazy, I can’t find anything technical about Unreal 1’s lighting, but that’s probably because search engines are shitty nowadays.
1 Like
I know exactly where that screenshot was taken. 
that takes be back.
1 Like
in order to use lightmaps (in 1990-2000 engines) there needs to be a step to bake the lights. in hammer editor this would take hours. the result would also be much better looking, as it is basically raytracing.
if these shadows are shown in editor as you build it, it is some form of real-time lighting.
the only form of real-time lighting at the time (2000) was projected shadows (shadow volume), a mesh would be drawn in the shape of the shadow. this was used by the game blade edge of darkness and later doom 3, and in neverwinter nights.
this would be replaced by pre-rendered shadows, used in UDK, and then buffer shadows (call of juarez), but these were too heavy for the time so they were limited to the sun.
My guess is, this is just a dark spot, there are ambient lights used to light the surface and form a shape roughly resembling a shadow. level design used to be much more of an artistic job back then. these days the shadows are generated by the engine so the level designer is not involved in the final look of the level like they used to.
unreal made use of geometric blocks similar to quake, but these don’t seem to be combined in the way quake engine games did, so it’s just a bunch of loose blocks. I could be wrong.
if this is unreal 1, there is also a limit to the polycount. unreal 2 increased this limit by 10-20 times, but UE1 had low polycount.
back to that shadow, you can try putting a mask on the light to simulate shadows. for example, if you have a light behind a fence, you can use a mask in the shape of the fence and project it on a wall on the other side. this was a very common technique. it also works for other shapes.
1 Like
you are right, those are shadows.
I finally found some actual info, but it’s very little. apparently, UE1 had BSPs and you had to build the level, so that would explain how lights don’t go through walls, and there might also be light baking at play, just very low quality.
the lighting techniques were still used though, since they were cheaper. there are articles about faking lighting with pre-edited textures and ambient lights.
1 Like
BSP. That sound familiar. The levels were blocked-out in the editor using primative shapes that were either additive or subtractive.
Was this BSP system similar to Godot’s CSG?
BSP stands for Binary Space Partitioning. it takes a space in integers where you create 3D shapes, usually these have to snap to the same vertices, so you are limited to boxes and wedges, and in more modern versions they added NURBS.
these levels are then baked, dividing the space into halves and creating areas. this is used for lighting and also pathfinding.
in quake engines the geometry was also cut and optimized into triangles, but I don’t know about unreal.
after the BSP is done, raytracing can be performed very efficiently for baking shadows.
more complex models where however not baked and either added after calculations, or taken into account very lightly. that’s why half-life used so many prefabs made out of engine geometry, and why more detailed models where unshaded in other games.
godot’s CSG does perform geometry optimization, but it’s still a bunch of nodes and much much heavier. they are also not limited to an integer space but use the float space.
CSGs existed in 3D software and basicaly combine a bunch of meshes into a single one and that’s it. godot can also create a collision mesh from this, but it will never be as efficient as a proper BSP.
you could use CSGs and export them to a mesh, and then edit the mesh in blender or other 3D software, and reimport as meshinstance3D with a collider. this is a valid workflow. but the general idea is that CSGs are for prototyping and should never be in a finalized game.
1 Like
BSP geometry did have a “solidity” to it that is hard to replicate in modern games. The meshes that replaced them can support much more detail and are not limited to an integer vertex grid, but they seem to lack physical weight.
Light passing through meshes reinforces this perception because the lights themselves don’t believe the meshes to be “real”.
You might be interested in FuncGodot. It lets you use geometry built in, for example, TrenchBroom (a level editor for Quake-engine based games) in Godot.
1 Like