Studio / ROBLOX

Roblox Studio 的第一个日光场景：灯光、空气与路线可读性

规划一个小型练习场景，区分全局环境与局部灯光，每次只改变一项条件来比较路线是否清楚。建议数值是之后实际检查的起点，并非测量结果。

三个点：灯光、障碍与终点 — 原创教学示意图，并非 Studio 截图 — 物体布局，不是光照模拟

更新日期: 2026-10-07

1. 先给灯光一个明确任务 #

第一个目标是让路线容易理解：玩家能看见障碍边缘，知道怎样绕过去，也能认出终点。先用没有复杂装饰的白天场景。写下三个问题：从哪里开始移动，什么东西挡住直行路线，哪个物体表示结束？灯光应当帮助玩家从正常相机距离回答这些问题，而不是只在编辑器放大的漂亮画面中有效。先确定要观察的动作，再选择光线的风格。

这是一份独立练习原型的计划，建议设置仍需要之后观察，不要直接照搬到大型关卡。如果终点只靠颜色区分，增加形状，例如顶部较宽的高柱子。如果障碍与地面融为一体，先区分轮廓和材质。几何结构已经说明路线时，灯光才容易评价；不要要求玩家猜出看不见的通道，也不要让装饰效果代替方向提示。

2. 在简单地面上准备三个点 #

在独立练习 place 中准备平坦地面和三个固定物体，命名为 Source、Obstacle、Finish。建议沿一个轴布置：Source 位于 (-8, 6, 0)，Obstacle 位于 (0, 3, 0)，Finish 位于 (10, 1, 0)，单位是 studs。障碍可以从尺寸 (2, 6, 6) 开始，并在两侧留下绕行空间。这些数值用于比较，不是正式游戏必须遵守的关卡尺寸。

选择 Source 一侧的观察位置并记下来，比较不同版本时不要随意移动相机。还要从侧面查看绕行路线：即使灯光正确，正面视角也可能被障碍完全遮住终点。使用简单不透明材质和不同形状，保留自己的参考视角。第一张示意图表达布局与计划绕行路线，不计算照度，也不是已经在 Studio 中测试过的真实场景截图。

3. 使用当前 Lighting 设置 #

在 Explorer 中选择 Lighting，然后在 Properties 查看属性。当前风格使用 LightingStyle，选项为 Realistic 和 Soft。这个练习的起始版本建议选择 Realistic；如果作品更适合 Soft，就记录选择并以它重新建立基准。不要寻找必须通过 Technology 才能实现的配方：这个属性已经弃用，旧的 Unified 路线也不是当前推荐入口。

另行记录 PrioritizeLightingQuality。它表达渲染质量降低时近处光影质量与可视距离的优先关系，并不保证游戏更快。第一次比较先保持原值。旧教程提到 Future 或 ShadowMap 时，需要先理解再对应到当前属性，不要机械复制。这里需要的是明确的视觉意图和可比较条件，不是寻找秘密引擎组合或同时修改几十个开关。

4. 设置时间并保持太阳条件一致 #

在 Lighting 中以 ClockTime = 13 作为建议的白天起点，检查关联的 TimeOfDay 是否对应 13:00:00。它们是同一场景时间的两种表达，不是电脑真实时钟。时间不会自动流逝；昼夜循环属于另一项机制，这个练习不包含它。确认显示值后，再观察障碍表面和地面。

记录 GeographicLatitude，不要同时修改它和时间，因为它也影响太阳位置。先看障碍哪一侧受光，暗区位于哪里。之后可以单独比较 ClockTime = 16，其他条件保持一致。评价边缘是否容易辨认，而不是宣称某个时刻适用于所有游戏。实验结束后恢复原时间，让后续步骤仍针对同一场景，否则无法准确解释画面变化来自哪项设置。

5. 记录全局基准 #

第一张表给出建议的起始设置，不是测试数据。Lighting.Brightness 对应全局太阳和月亮；局部灯光里同名属性只对应那盏灯。ExposureCompensation = 0 提供一个容易复查的起点。也记录已有视觉效果，第一次评估路线时不要再加入模糊或辉光，避免一个清晰问题被多个效果掩盖。

Ambient 用于被遮挡而无法直接接触天空的区域；开启全局阴影时，OutdoorAmbient 对应开放区域。建议的两种灰色让后者比前者更亮。这里的 RGB 指颜色字段中的数值，不是代码里小数形式的 Color3。若画面变成一片浅白，先恢复基准并比较材质。不要同时提高亮度、曝光和环境光来解决细节丢失，否则很难找到真正原因。

对象／属性	建议起点	记录目的
Lighting.LightingStyle	Realistic	基准视觉风格
Lighting.ClockTime / TimeOfDay	13 / 13:00:00	同一场景时间
Lighting.Brightness	2	可比较的全局亮度
Lighting.ExposureCompensation	0	参考曝光
Lighting.Ambient	RGB (70, 70, 70)	被遮挡区域的环境光
Lighting.OutdoorAmbient	RGB (125, 125, 125)	开放区域的环境光
Lighting.GlobalShadows	true	全局阴影条件
PointLight	Brightness 1.5; Range 12; Enabled true; Shadows true	一个局部光源
Atmosphere（如果存在）	Density 0; Haze 0; Glare 0	清晰空气参考

6. 只添加一个 PointLight #

在 Source 的预定发光点准备 Attachment，并在其中插入 PointLight，整个层级放在 Workspace 内。在 Explorer 中选择灯光本身。建议起点是 Enabled = true、Brightness = 1.5、Range = 12、白色 Color、Shadows = true。PointLight 围绕一个点向周围发光，适合作为不需要定向光束的简单练习灯。

先从同一位置比较开启与关闭。白天贡献可能不明显，仅凭这一点不能判断灯光损坏。Range 是以 studs 表示的距离，提高 Brightness 不会扩大范围。在建议布局中，Finish 与 Source 的距离超过初始半径，不应期待这一盏灯照亮整条路线。需要更远范围时单独改 Range，记录实际观察，不要同时移动光源位置。

7. 分别比较定向灯光 #

另一版本先关闭 PointLight，再把 SpotLight 直接放在 Source 的 BasePart 内。它以锥形方向发光，可以从 Angle = 60、Range = 12 开始。这里 Face 选择 Source 的表面，核对该面与部件朝向。若另行放入 Attachment，Face 选择它的轴，因此还要核对 Attachment 的朝向。不要在还没确认方向时先调高亮度：一个朝向旁边的强光仍然可能无法帮助玩家看见路线。

SurfaceLight 可以在平面面板上单独比较：放在面板 BasePart 内，选择适当的 Face。在这种布置中，它从表面而不是单点发光。API 也允许 Attachment 父对象，此时行为接近 SpotLight，但本练习保持面板方案。每次只启用一个来源。三个灯一起亮时，就很难说明哪个显露了障碍边缘，哪个只增加了亮斑，也无法可靠比较各自作用。

8. 区分 Neon 与实际光源 #

Neon 材质能够让终点标记看起来发亮，但它本身不会像 PointLight 一样照亮附近地面。单独比较普通 Finish 材质与 Neon，保持灯光不变，同时观察标记和旁边的表面。物体发亮的外观与真实局部照明承担不同任务；后者需要相应灯光对象，而不是只更换材质。

显眼标记不能替代危险边缘检查。即使装饰辉光在另一个设备上较弱，玩家仍应认出障碍和绕行路径。如果希望发光招牌同时照亮周围，就分别规划招牌材质与灯光。记录两种用途：认出终点、看清一段地面。之后调整艺术风格时，就能保留方向信息，而不会把漂亮的画面当成路线已通过检查的证据。

9. 路线清楚之后再加入 Atmosphere #

如果 Lighting 中已有 Atmosphere，可以从 Density = 0、Haze = 0、Glare = 0 建立建议的清晰参考。先记录并保持其他属性。之后单独尝试 Density = 0.2，观察 Finish 是否仍可区分，远处区域是否与背景混在一起。它们定义未来比较条件，不保证一定清楚；每个场景仍需要自己的实际观察。

Density 影响物体被空气遮蔽的程度，Haze 控制大气薄雾，两者不替代灯光 Range。Lighting 中存在 Atmosphere 时，普通 Fog 属性会隐藏；这里没有 Density 到 FogEnd 的通用换算。不要根据零散配方来回混用。初版无需复杂的 Glare 和 Decay 调整。如果空气效果遮住必经通道，先减弱影响或调整地标结构，而不是不断加更亮的灯试图解决所有问题。

三个不同的可见性层次 — 原创教学示意图，并非 Studio 截图 — 每次只比较一项变化

10. 从玩家位置判断可见性 #

回到 Source 一侧记录的视角，再沿计划绕行并看向 Finish。分开记录三类现象：几何物体遮住标记，边缘太暗，远处形状消失在空气效果中。它们需要不同的下一步比较。被墙挡住的标记往往需要改高度或位置，而不是增加墙后面的灯光。先确认现象，再决定改变哪一项。

以后安排较低渲染质量和真实手机检查，不要只把必要提示藏在精细阴影中，因为不同设备显示细节可能不同。问题应是玩家能否理解方向，而不是所有像素是否一致。如果编辑器与游戏会话不同，记录当前属性并检查项目逻辑是否修改它们。一个原型视角不能证明所有 Roblox 场景或设备的表现，视觉目的也应与性能结论分开。

11. 比较时不要编造结果 #

第二张表把实际结果留空。每行开始前恢复基准，仅修改列出的属性或方案。简短记录可以包含日期、相机位置、观察和下一步。不要只写“灯光修好了”；可以在真正检查之后写“入口能看清左侧边缘，绕过后能认出标记”。这样下一位开发者知道究竟验证了哪一段路线。

如果改善只出现在新视角，另行记录相机移动，不要归因于同时改过的属性。让另一个人检查时，可以要求他在没有口头提示的情况下找到终点，再记录犹豫位置。未来设备测试不能被示意图或编辑器参考图代替。未完成的行继续留空，结论只适用于已经观察过的条件，不能延伸为整个游戏的保证。

版本	相对于基准只改一项	检查问题
A	没有变化：基准条件	边缘可见，绕行清楚吗？
B	PointLight.Enabled = false	哪块区域依赖这盏灯？
C	PointLight.Range = 20	亮度不变时哪里发生变化？
D	一种替代灯光	SpotLight／SurfaceLight 指向哪里？
E	Atmosphere.Density = 0.2	同一视角仍能区分 Finish 吗？
F	另一设备或质量	记录的条件下路线仍清楚吗？

12. 保存场景并交接清楚记录 #

另行保存练习 place，记录版本条件：三个对象的位置、时间、风格、启用的灯光和 Atmosphere 参数。下次打开后，先核对状态，包括 TimeOfDay，再继续比较。保存项目、发布体验、检查游戏客户端是不同阶段。这个练习不要求为了第一次日光设置立即发布，也不把保存等同于游戏检查。

交给其他开发者时，附上路线目标、基准、单项变化和已有实际观察，说明哪些检查尚未执行。根据问题选择下一项任务：路线可读性、关卡试玩或设备比较。不要宣称建议数值是所有场景的标准，也不要未经评价就把示意方案搬进正式游戏。第一步有价值的成果是可重复的计划，以及之后能逐项检查的清楚路线。

原始资料