I’m new here and still confused with lightmap and shadow. Sorry if the questions are too basic, I’m just confused.
I just read some documents about shader and understand that unlit shader has best performance because it has nothing to do with light and shadows. And mobile shader has unlit shader and it’s support lightmaps. here is my question:
what is lightmap? what is the difference between shaders and lightmap?
is baking shadows and baking light different?
how baking shadow/light can give better performance to the game?
why we can’t bake the shadows of moving object?
Say I have game object shaped letter (L) and the left side of game Object “(| )” cast shadows to lower side of it"( _)".
5.what happen when I bake shadow/light to that object?
can I move the object with static shape of shadow(the shape is same as when it’s baked)?
7.if can, what shader can I use in mobile shaders?
shader = set of rules (code) for displaying colors in appropriate places of the game (each visible object has a shader
1,5 ) lightmap - a resource / an asset (a large picture), which is used in some shader, allowing to ‘fake’ light. Imagine you are sitting in a room with the light turned on. Well, you can take a ‘picture’ of that room and remove any photons from being in the scene. Instead, you can use this ‘picture’ to describe how the light falls on surfaces. As long as objects don’t move, this lightmap will work as intended. As soon as something moves, lightmap picture won’t fit the current scene and will look weird
Baking shadows and baking light is the same thing. Baking a lightmap is a better terminology.
You can also pre-compute a real-time light datastructure (GI). Instead of ‘wrapping’ the scene as the lightmap picture would, this 3-dimensional light system stores intensities and colors of light in various scene locations. This allows 3d objects to move (to be dynamic), but it looks worse than lightmap and requires a lot more resources during the gameplay, to “cater” or service the structure.
If we don’t use lightmap or the pre-computed system, we will use usual lights which are very resource consuming and have to be calculated every frame for many many pixels on the screen. Because of that, the quality is inferior to the pre-computed solutions discussed above.
as discussed in 1), it’s a picture which wraps the objects in the scene; as somethign moves, it will no longer be fitting the description of light in the lightmap texture.
It will behave as you expect it to be, the | will cast a shadow on _ (self-shadowing will be present)
Yes, if the shadow is very very crude (like a circular gradient) under the character. It could literally be a square with a semi-transparent picture (also called a texture) applied to that square. But it looks terrible and was used in like 2006 games. Even mobile games use dynamically computed shadows.
Mobile shader is a set of algorithms which:
doesn’t use realtime lights (or uses a few)
doesn’t use too many pictures to wrap around objects to which such a shader is applied
doesn’t perform any expensive operations (like reflecting the incoming light or warping picture by bending the light.
Keep in mind that I used a very basic terminology here.
Shaders are more complex than that, - they work on 3d-coordinates which describe each object in your game. Further, it works on fragments, which are mapped to the pixels on your screen. Hence, any 3dimensional entity which ends up on your screen will generate fragments. A Vertex-version of a Shader is first ran for each 3d-coordinate, and then the Fragment Shader is ran for each fragment (there are a lot more fragments than there are coordinates, hence it is more expensive).