When you want to animate with a sprite sheet in Unity, you need to treat the sheet as containing multiple individual sprites, not a single image. Setting the texture’s Sprite Mode to Multiple tells Unity to split the sheet into separate Sprites so you can use each frame as a step in an animation. Without this, Unity sees only one sprite and there’s no way to define successive frames to play in a timeline. That’s why the statement is true: you must set the sprite to Multiple to enable slicing and create a frame sequence for animation. It isn’t about a particular pipeline or the 2D Animation package—the basic workflow requires Multiple so the Sprite Editor can generate the individual frames, which you then order into an Animation Clip.

Achieving consistent lighting across devices comes from using linear color space, keeping exposure stable, baking lighting when possible, and testing on target hardware to calibrate the results. Using linear color space ensures lighting calculations reflect real-world physics, so brightness and color ramp how light adds up stay predictable across different GPUs and displays. Gamma color space, by contrast, introduces non-linearities that can cause different devices to render scenes with varying brightness and contrast, leading to inconsistency. Keeping exposure consistent is also crucial. If exposure varies between devices or runs, the same scene can look brighter or darker, making lighting appear different even if the actual light setup is identical. Locking exposure or controlling it with a fixed, calibrated setting helps maintain uniform brightness. Baked lighting precomputes light interactions into lightmaps, which are static and not dependent on per-frame real-time calculations. This greatly reduces variability across GPUs and enables a stable, repeatable look on all target devices. Real-time lighting can introduce discrepancies due to performance differences, shadow resolution, or dynamic tone mapping. Finally, testing on target devices lets you account for device-specific factors like display gamma, tone mapping, and HDR capabilities, so you can fine-tune the setup to look correct where it matters most. The other options fail because they either introduce or rely on conditions that cause divergence in lighting between devices (gamma space, inconsistent exposure, or reliance solely on post-processing), or neglect the stability that baked lighting provides.

Lighting mode determines how a light’s contribution is calculated: in real time every frame, baked into lightmaps, or a mix of both. The property that controls this behavior is the light’s Mode setting on the Light component. Setting it to Real-time makes the light update continuously; setting it to Baked precomputes the lighting and stores it in lightmaps for static geometry; setting it to Mixed combines both approaches to optimize performance. The other properties describe physical aspects of the light (Spot Angle for the cone width, Range for how far it reaches, Color for its tint) and do not specify how the light is processed over time. So the Mode is the correct choice.

Lightmap Resolution determines texel density of baked lightmaps, meaning how finely lighting information is sampled on surfaces. In Unity, static geometry stores lighting in lightmap textures baked beforehand. Increasing the resolution gives more texels per surface area, so shadows and subtle lighting details become crisper and more accurate, which improves scene quality. But higher fidelity costs more memory to store the larger lightmap textures and longer bake times because the lightmapper has more texels to compute. Dynamic lighting during runtime isn’t affected by lightmap resolution, and it doesn’t change scene scale. To optimize, balance resolution with viewing distance and object importance, and consider compression or separate lightmaps to manage memory and bake time.