品牌网站建设可信大蝌蚪,如何设计一个网页界面,erp系统介绍,网站建设的目标与思路仓库:https://gitee.com/mrxiao_com/2d_game_2
黑板#xff1a;制作一些光场(Light Field)
当前的目标是为游戏添加光照系统#xff0c;并已完成了法线映射#xff08;normal maps#xff09;的管道#xff0c;但还没有创建可以供这些正常映射采样的光场。为了继续推进制作一些光场(Light Field)
当前的目标是为游戏添加光照系统并已完成了法线映射normal maps的管道但还没有创建可以供这些正常映射采样的光场。为了继续推进需要生成三个光场上、中、下三个不同的环境贴图EnvMaps以便能够从中获取周围环境的光照数据。
具体来说 光场的构建 顶部和底部光场这些光场相对容易构建可以使用地面和天空的位图来代表。地面图将用作底部光场天空图作为顶部光场主要工作是确保渲染器能够保存并从未被遮挡的基础层中提取数据。中间光场这个光场稍微复杂一些需要考虑光的遮挡效应。如果有光源经过应该能够表现出光线穿过物体表面的效果类似地如果有物体阻挡光线采样到的光线就应该变暗。这个光场的实现会涉及一些更复杂的技术和算法尤其是在计算遮挡和反射等方面。 目前的步骤 生成顶部和底部的测试环境光贴图以确保系统的基本光照采样工作正常。虽然还没有实现复杂的遮挡和反射效果但这些测试贴图将帮助验证正常映射的实现。在顶部和底部光场上使用简单的测试模式以检查是否能够正确采样并应用正常映射。
总的来说当前工作重点是创建并调试这些基础的光场贴图以便后续进一步完善光照和正常映射的系统确保渲染效果能够达到预期。
创建测试环境贴图
在开发过程中首先需要为环境贴图即光照场分配空间。这些环境贴图包括顶部、中部和底部贴图尽管目前尚不清楚这些贴图的具体分辨率和内容例如顶部贴图可能代表天空但实际上可以是任何其他内容。因此将这些环境贴图作为动态数据进行处理它们会与地面缓冲区ground buffers一同管理因为它们的性质是短暂的随着渲染器的发展空间分配会逐步调整。
在实现过程中需要为这些环境贴图分配内存并且考虑到光照的处理这些贴图的分辨率可以选择一个较低的采样率而不是与其他内容保持相同的高分辨率。因此应该先定义这些环境贴图的宽度和高度以便为后续的工作打下基础。
接下来初始化时将这些环境贴图的变量例如顶部、中部和底部贴图以及它们的宽高添加到相应的数据结构中确保它们在渲染过程中能够正确使用。
初始化环境贴图
首先设置了一个名为 TranState 的初始化状态用来初始化环境贴图。接下来环境贴图的宽度和高度被设置为 512x256虽然这些值是随机选择的但它们决定了环境贴图的分辨率。
为了简化初始化过程使用了一个循环来逐个初始化每个环境贴图。具体来说在循环中首先获取环境贴图数组中的每个环境贴图并为其初始化不同的 LODLevel of Detail。这些 LOD 是相同贴图的不同清晰度版本逐级模糊分辨率逐渐降低。
通过设置循环首先处理顶层环境贴图索引 0接着是中层和底层环境贴图索引 1 和 2。另外还考虑到了坐标系的方向决定使用 “Z轴向上” 的方式这样可以保持与其他坐标系统一致增加一致性和易于理解。
最后在每一轮循环中初始化的环境贴图会根据对应的分辨率大小逐渐变得更模糊这样可以生成一系列不同清晰度的环境贴图版本以供后续使用。 设置LOD细节层次选择器
接下来在初始化过程中加入了另一个循环用来处理每个 LOD细节级别索引。这个内层循环会根据环境贴图的数量此时设为 4迭代通过每一层 LOD。
在每一轮循环中根据当前 LOD 索引来创建相应的环境贴图。通过调用已定义的 MakeEmptyBitmap 函数这个函数负责为每个 LOD 分配内存空间并且将分配的内存推入暂存区TransientArena。这样环境贴图的数据就能够存储在指定的内存区域。
为了支持不同细节级别的效果首先创建最高分辨率的贴图然后每次迭代时宽度和高度都会按比例缩小。具体来说每次迭代时宽度和高度会减半从而生成一个逐渐模糊、分辨率递减的级别例如初始分辨率、四分之一大小、再四分之一大小依此类推。这种方式会产生一系列从高到低的 LOD 地图确保每个级别的环境贴图都有合适的分辨率。
通过这种方式可以实现分层次的细节级别LOD管理确保在渲染时根据需要使用不同清晰度的贴图以提高性能并保证渲染效果。
将贴图传递给CoordinateSystem
在此阶段需要确保能够正确地传递之前创建的环境贴图环境地图。之前这些环境贴图并没有被传递过来而现在需要开始传递它们。这是一个直接的过程只需要将环境贴图按照顺序传递即可。
首先传递第一个环境贴图如顶部贴图然后是第二个贴图中间贴图最后是第三个贴图底部贴图。在代码中环境贴图的顺序需要符合预设的顺序即先是顶部贴图然后是中间贴图再到底部贴图。
在传递这些贴图时确保与渲染组中的坐标系统一致因此需要仔细检查环境贴图在传递时的顺序以确保与渲染设置相匹配。通过这种方式环境贴图可以正确地被使用在渲染过程中。
编译并清理
有一些变量被错误地声明为指针这应该是一个错误需要去掉指针声明并进行修正。这样修改之后应该能够顺利编译并确保代码正常工作。 这些修改有助于代码结构的清晰确保不同功能和模块能够适当地组织避免潜在的问题并且使代码更加易于维护。
运行但没有发生什么特别的事
目前地图中的内容只是垃圾数据实际上它们目前只有零值因为它们位于临时缓冲区transient arena中而该缓冲区在初始化时已经被清空。因此当前不应有任何光照贡献这正是预期的结果。
接下来目标是开始向这些地图中填充实际内容从而能够开始从中进行采样。首先计划将开始填充这些地图确保能够正确地从中获取数据并进行进一步的处理。
绘制环境贴图
首先需要在渲染过程中绘制这些环境图以确保它们确实包含预期的内容而不是盲目地进行采样。为了验证这一点首先在渲染调用之前添加一些代码以绘制至少是环境图的顶级图层。这样可以确保已经正确填充了环境图并能够正确地查看它们的内容。
由于粗糙度roughness用于决定选择哪个LOD细节层次因此需要确认实际填入图层的粗糙度值。在当前实现中粗糙度值是用来决定选择哪一层LOD的。例如当粗糙度为零时默认选择的是顶层LOD。
为了绘制图像可以通过遍历环境图的每个地图来绘制不同LOD的图层。需要确保每个LOD图层在屏幕上正确显示图像的位置也需要通过重新定义X轴和Y轴的比例来确定。为了避免图像重叠可以根据实际LOD的宽高来调整显示大小确保它们能够正确地显示在屏幕上。
最后绘制的图层可能会出现颜色或透明度问题需要调整颜色值确保它们显示为全亮度避免任何颜色的影响。通过调整绘制位置可以确保每个图层正确显示并且在屏幕上能够看到完整的环境图。如果图层的透明度不正确可能会导致图像无法正确显示。
总之这个过程的目的是确保环境图正确地填充并渲染以便可以进一步调试和验证它们的使用。 准备环境贴图
首先在每一帧渲染开始时清除并重新绘制环境图填充一些可以测试法线贴图的内容。为了简化测试可以使用渲染组中的 DrawRectangle 调用通过指定位图并填充不同颜色来验证法线贴图效果。
具体来说首先清除环境图的顶层LOD并填充该图层。可以将底部填充为红色顶部填充为蓝色这样通过法线贴图的光照计算时至少可以在物体的顶部和底部看到红色和蓝色的色调。
接下来清除环境图的顶层LOD传入相关参数如 TranState、EnvMapWidth、EnvMapHeight进行清除确保渲染的图层没有残留内容。可以选择清除为纯红色、纯绿色和纯蓝色代表不同的层次。清除绿色层可能是多余的当前代码可能未使用该层这一点需要检查并修正。
最后转换色彩格式时可能需要将颜色从 uint32 转换为 real32以确保渲染时颜色正确显示。此时的清除操作完成准备好进行后续的渲染和测试。 在游戏中查看
已经可以看到正在从环境贴图中采样了但是出现了一个 bug看起来是混合的方向被反转了。具体来说可以看到蓝色区域有较为平滑的过渡效果虽然可能还不是完全正确但至少有一定的羽化效果看起来没有太硬的分界线。然而红色区域却出现了明显的硬边界这正是需要修正的问题不符合预期效果。
注意到一些BUG
发现了两个问题第一个是混合的方向被反转导致蓝色区域羽化效果正常而红色区域出现了硬边界。第二个问题是地面和天空贴图被翻转了地面贴图应该在下方但却出现在上方天空贴图则相反。这个问题也需要解决。
这种问题的发现是通过调试代码时采用的结构化艺术方法。通过用简单的、易于区分的颜色如红色和蓝色来填充贴图能够更清晰地看到哪里出错而不像直接用真实数据那样难以分辨问题。结构化艺术帮助识别并修复渲染中的细微错误。计划接下来可能用白色调试纹理替换当前的纹理专注于查看球体法线贴图的效果而不受其他纹理的干扰。 查看如何修复底部贴图的采样
发现了一个问题底部贴图被错误地指定为上部贴图导致渲染结果不正确。检查了法线图的方向发现法线的Y值在负方向时被错误地判断为底部贴图。此问题可能是由于法线贴图的坐标系问题引起的当前的贴图坐标系是从顶部到底部而理想情况下应该使用从底部到顶部的坐标系。
考虑到大多数图形API如OpenGL通常使用底部到顶部的坐标系因此决定将贴图的坐标系调整为从底部到顶部。这种调整需要尽快完成因为在渲染过程中坐标系问题可能会影响后续的计算和调试因此需要尽早解决。
优先整理坐标系统
目前坐标系问题尚未解决但决定暂时跳过这一部分先继续进行渲染工作直到更进一步处理坐标系问题。虽然当前坐标系存在问题但实际采样的部分并没有错误因此可以继续进行。计划在优化和进一步处理渲染时首先对屏幕坐标系、世界坐标系和纹理坐标系进行统一确保它们在整个系统中保持一致性。这一调整将在进一步推进之前进行以避免后续出现更复杂的问题。
添加一些注释 修复底部贴图的采样
在检查底部纹理地图时发现出现了方向问题。原本的映射范围应该是从负一到负零点五但当前实现中出现了反向映射的问题。为了解决这个问题需要调整坐标映射的方向确保在零的位置应该是1而不是0。通过对公式进行简化和调整可以正确地得到所需的结果。最终通过调整公式确保了映射的数值正确地从负一到负零点五之间变化并成功修复了方向问题达到了预期的渐变效果。
为环境贴图实现棋盘格图案
现在的目标是更准确地计算采样位置因为当前的采样方法并不精确。为了测试这个问题建议使用棋盘格纹理进行调试这样可以通过清晰的图案帮助识别问题。计划使用16像素的棋盘格模式通过在每个LOD层上绘制这个棋盘格来检查纹理的采样。
为了实现这一点需要在代码中定义棋盘格的宽度和高度并通过遍历每个LOD的x和y坐标依次绘制每个格子。每个格子的最大和最小坐标由宽度和高度决定。为了简化颜色的设置将绘制矩形的函数修改为接受颜色值颜色值包括红、绿、蓝和透明度。这样可以直接传递颜色并且避免繁琐的操作。
此外还需要确保颜色值正确传递给每个矩形绘制函数并更新了存储颜色信息的结构使得颜色数据传递更加简洁和一致。最终代码将更高效且易于维护因为减少了冗余的计算和数据传递。 实现ToV4
通常定义数学库是为了快速地从一个向量类型转换到另一个类型。比如对于一个 v4 向量定义一个 twoBefore 函数可以接受一个 v3即 XYZ和一个 W 分量。这个函数非常基础它的作用是将 v3 的 XYZ 分量和 W 分量直接传递给结果。这样就能得到一个新的 v4 向量结果的 XYZ 保持不变而 W 则是传入的 W 值。通过这种方式可以快速在不同维度的向量之间进行转换。
对于其他维度的向量比如 v3也可以使用类似的方法进行定义和转换。基本上每个维度的向量都会有类似的函数来进行构造和转换这样的实现非常简洁且高效。 继续棋盘格例程
在绘制棋盘格的过程中首先需要为每个纹理地图设置颜色。为了做到这一点通过 LOD 获取当前的颜色并将其分配给地图颜色。然后为了绘制棋盘格定义了一个 MapColor通过这个颜色来决定当前区域的颜色。在遍历棋盘格时通过判断当前所在的棋盘格位置来决定是否将颜色设置为黑色。
棋盘格的最小点MinP和最大点MaxP可以通过 X 和 Y 坐标来确定因为在绘制时宽度和高度已经确定。为了正确地交替棋盘格的颜色设置了一个 CheckerOn 变量用来判断当前方块的颜色是地图颜色还是黑色并通过切换 CheckerOn 的状态来实现这一效果。为了在每一行交替改变颜色定义了一个 RowCheckerOn 变量它决定了每一行的起始颜色。
同时需要设置棋盘格的宽度和高度这里暂时设定为 16x16不过也考虑到高度可能小于宽度决定暂时调整为 8。这个设置还没有完全确定最终效果会根据实际需求进行调整。 按altenter全屏好像不能固定全屏 在游戏中查看棋盘格
棋盘格已经绘制完成看起来很棒。可以看到双线性滤波正在生效尤其是当样本之间的纹理采样时产生了中间值也就是在两个采样点之间的过渡效果。现在棋盘格已经被处理完了。
有趣的是观察到现在整个图像没有任何光照这很奇怪特别是因为推测这意味着纹理采样的位置可能只选择了一些黑色的像素。这个现象可能是因为没有正确处理纹理坐标的计算导致采样结果不正确。因此应该开始着手解决纹理坐标问题确保能够正确地从纹理图中获取像素值。
引入TestDiffuse和TestNormal
首先决定不再使用树的正常贴图而是创建一个测试用的位图和正常贴图。创建了 TestDiffuse 和 TestNormal其中 TestDiffuse 是一个颜色位图TestNormal 是一个球形正常贴图。为了生成正常贴图选择了一个球形正常贴图并设定了零粗糙度。接下来创建了一个 256x256 的空位图 TestDiffuse作为测试使用。
接着使用 DrawRectangle 方法绘制矩形填充该位图并将颜色设置为中性灰色这样就可以观察正常贴图的效果了。
在代码中TreeNormal 不是 GameState 的成员因此需要调整代码中的变量名称改为 TestDiffuse 和 TestNormal。此外由于改变了位图的大小动态重载并不支持这一变化因此需要处理这个问题。 其他修改是添加注释
在游戏中查看并改变背景颜色
在开发过程中原本使用的灰色与背景色相同导致无法清晰地判断图形是否正确绘制。经过反思这个灰色选择显然是一个疏忽。为了能更好地确认是否有绘制效果决定调整颜色以便能够更容易地看到图形。现在当图形正确绘制之后可以观察到其是否反映了预期的光照贡献尤其是在处理实际的反射和光照传递时。虽然时间紧迫接下来的工作可能无法完成但这一调整为后续的调试和开发提供了更清晰的视图。 查看我们在SampleEnvironmentMap中的工作
在开发过程中当前的实现并没有处理如何正确地查找采样位置因此没有得到预期的光照贡献。当前系统只是简单地选择了地图的上角而没有实际执行从地图中查找和计算具体值的工作。为了解决这个问题需要进行必要的操作从地图中获取实际的值并准确地进行计算确保能够正确反映光照的贡献。这项工作将在后续完成。
使用法线查找环境贴图
可以想象在地图中选择位置时使用法线来确定位置。具体来说可以从宽度开始然后根据宽度选择法线的 x 坐标。虽然这种方法并不完美但它能提供一个简单的思路至少可以从中选择出一些元素。这种方法并不是目标方案但它提供了一个直观的、易于理解的步骤便于从中观察和调试。
在游戏中查看
当前反射效果还没有完全实现实际上它只是在作为一种延迟纹理查找来使用。但至少可以确认尝试的方向是有效的。对于双线性采样的效果经过重新思考可能是合理的因此目前这种方法应该是可行的。虽然目前的效果已经不错但暂时不打算深入研究如何正确进行采样因为现在并没有足够的时间来做这些细节工作。因此可能需要暂时停止当前的进展。
接下来计划在稍后继续处理实际的数学运算部分尤其是采样部分可以留到第二天再继续。同时还需要考虑如何处理绿色范围的相关问题虽然目前还不清楚具体怎么做但这部分工作肯定会需要大量的规划和思考因此要提前计划好如何将这部分内容融入到整体中。
在MoveEntity函数中你有两个未使用的变量NewPlayerP和OldPlayerP。你会删除它们吗
有两个变量 new player 和 old player 从未被使用是否需要删除它们呢有些疑问是否将来可能会用到这两个变量特别是它们是否会在之后的工作中派上用场。不过考虑到它们并未发挥作用这部分代码可能需要进行大幅删除。如果确实需要删除它们完全可以这样做。
这个方案能让你看到水面反射星空吗
这个方案是否能让一池水反射星空关键在于如何处理这些地图的分辨率。显然技术本身是能实现这一效果的但在采样过程中需要考虑许多因素。如果仔细考虑一下可能会发现保持效果良好的过程中会有一些挑战。例如问题在于采样时会遇到的一些困难这可能会影响最终的视觉效果。
黑板水面反射星空
当进行反射采样时尤其是水面反射星空时问题在于反射的方向和法线。每次反射都会在不同的方向上产生不同的反弹这些反弹会去采样纹理图而这种采样通常是稀疏的。因此无法保证不会出现明显的伪影。比如一个反弹可能会采样到一个位置而下一个反弹则可能跳跃到非常远的地方这就无法获得期望的各向异性过滤效果这对于水面反射的星空来说会导致不良效果。
在这种情况下为了避免过于复杂的采样问题可能会选择使用较低分辨率的纹理图这样就不会用来进行高质量的反射而更多是用于处理光照或光泽效果而不是高质量的反射。
解决这种问题的常见做法是在3D中通过从反射表面视角渲染场景模拟类似的过程但是否有其他复杂的技巧来避免这种糟糕的采样结果并不明确。可能会使用各向异性过滤来改善纹理采样但它可能不足以完全解决问题。反射在3D中的问题可能也会面临类似的困境有时可能无法完全避免导致反射效果中出现闪烁的伪影。因此这种问题需要注意。
如果你想看到光照根据法线贴图的球形形状而扭曲这是否只是修复从环境贴图采样时的数学部分还是还有更多内容
如果希望看到光照根据法线贴图的球形形状发生畸变那么这实际上只是修正采样部分数学计算的问题。明天进行修正时应该能够实现这种弯曲效果直到那时当前并没有进行这一计算。因此当前的效果并不表现为反射原因是没有在计算反射这一点应该不会让人感到意外。
拥有三个环境贴图顶部、中部、底部相较于使用一个整体的环境贴图有什么好处
使用顶部、中部和底部等多个环境贴图的好处在于它们可以帮助处理空间的不同层次尤其是与高度相关的内容。如果只使用一个环境贴图可能很难将高度信息融入其中难以做到空间上的细节区分。因此使用多个贴图可以更好地表示不同的空间位置和高度。如果能够找到一种方法将所有信息都从一个贴图中提取出来可能会更简单但目前并没有想到这样的方案。
黑板预览环境贴图的工作方式
目前的思路是使用多个贴图来处理不同的环境元素。首先已经制作好了地面纹理会将其放入场景中进行绘制。接着为场景中的实体添加阴影可以将阴影和地面纹理分成两个不同的位图来处理。然后使用一个中间贴图包含光照信息并将其中的光照信息添加到地面贴图中这样就得到了一个包含光照和阴影的地面贴图。接着保留一个仅包含光照的中间贴图和一个仅包含天空的顶部贴图。
通过这种方法地面贴图会包含地面纹理、光照和阴影中间贴图仅包含光照信息而顶部贴图则包含天空元素。在进行采样时期望能够通过这种方式获取到需要的3D信息。通过这种多贴图方式可以实现对不同环境层次如地面、光照、天空等的处理而单一的环境贴图似乎很难做到这一点。
我不太明白底部贴图的意义。地面是否会对地面上方的物体贡献光照
底部贴图会将光照反射到地面上的物体上这是因为现实中也是如此地面反射的光线对位于地面上的物体外观有重要影响。目标是尝试将这种效果实现到游戏中。首先计划是添加所有三种贴图观察它们的效果如果发现其中某一个贴图的效果不明显可以去掉从而节省计算资源。因此目标是先尝试使用三种贴图如果效果不理想可以删除不必要的部分。如果最终只需要中间的贴图也可以只保留它如果其他贴图带来良好的效果则继续保留。
对于每种环境贴图需要为每个物体设置对应的环境贴图。
你会需要为每个“Z层”准备一组环境贴图吗
在 Z 轴层级的处理上计划是让这些层次以某种方式级联。首先从最低的地面层开始渲染这将生成底部的环境贴图。接着我们需要处理天空贴图它本质上是上方地面层的反转。接下来通过使用地面贴图的 Alpha 通道来确定位置再将其与上层中间层的光照合成得到上方光源照射到下层的区域。
在层次叠加的过程中可以通过这种方式模拟光照的变化使得从上方照射下来的光照能够通过不同层次的合成展示出来。这是一种逐层渲染的方法从底部开始渲染然后逐步处理更高的层级。
此外还可以考虑对过亮的部分进行处理具体的做法可能会包括调整亮度以避免场景中过亮的部分影响整体效果。
有没有计划对灯光进行过曝处理甚至是HDR
对于高动态范围HDR效果并不确定是否会实现。考虑到软件环境中可能无法有效地实现 HDR因为使用浮点数如 float16可能难以处理。在考虑过亮效果时可以通过使用中间缓冲区来模拟类似 bloom 的效果但不太可能在软件管线中实现真正的 HDR。
可能的解决方案包括尝试使用一个额外的模糊缓冲区来增加一些 bloom 效果但在当前的设置下实际上并不认为能够实现 HDR尤其是在软件管道中。
你能将所有灯光信息包含在一个5字节的位图中吗0-255的吸收/反射比例RGB的Alpha和散射我想试试但因为你警告过不要使用非32位对齐的结构我感到有些犹豫。
可以将所有光照信息包含在一个五字节位图中其中包含 RGB 吸收率、反射率、缩放因子、透明度和散射效果。在尝试这种方法时可能会有一些犹豫特别是考虑到非 32 位对齐的结构。然而实际上非 32 位对齐并不是一个严重的问题因为这些数据本质上是作为像素值输入的因此可能能够成功使用五字节格式。如果遇到问题也可以通过将多个数据打包在一起减少对齐问题的影响。
然而关键问题在于如何处理法线信息。在这种方案中法线的存储似乎是一个需要解决的难题。
甚至只使用0-2的光照范围也能得到很好的效果
可以通过将光照范围从零到 255 映射到更高的亮度范围来获得更好的效果。例如可以考虑将其映射到双倍亮度等。这需要进一步思考和确认尚不确定是否完全可行。
关于是否计划进行相机层级的光照处理目前还不确定。
你是否计划做“相机级别”的光照效果比如“眩晕手雷”之类的
例如晕眩手雷这样的效果可以通过将屏幕覆盖上某些效果或增加亮度来实现这对系统来说非常容易做到。虽然不确定在当前的游戏中是否需要这些效果但确实可以实现而且并不复杂。如果可以不使用 alpha 通道效果实现会更简单。
如果不需要Alpha你能否使用RGBE其中E是所有通道的指数
使用RGB加上指数E来处理每个通道的HDR会使管道处理变得复杂尤其是在加载和重新打包E值时这是一个麻烦的过程。虽然实现HDR是可能的但不一定是可行的考虑到当前有很多需要关注的问题可能不值得尝试做HDR。尽管如此一旦渲染器的架构确定后进行修改并非不可能因此可以先实现非HDR版本之后再考虑是否升级为HDR版本关键是确保不会做出让未来更改变得困难的决策。
饱和度覆盖起来会很难吗
饱和度的叠加其实并不难。一个简单的做法是通过拉取平均值来实现。例如可以通过这种简单的方法来处理饱和度叠加。
引入render_entry_saturation
饱和度的叠加可以通过一个简单的后处理过程来实现。例如可以添加一个渲染条目来调整饱和度值。通过这种方式可以在最终的图像上应用饱和度调整。具体做法是在进行渲染时添加一个饱和度参数并在最终渲染输出时循环遍历每个像素并改变它们的饱和度。
为了实现这一点可以在代码中将目标缓冲区传入并根据给定的饱和度值进行处理。这样就可以在渲染过程中调整图像的饱和度通过修改像素的饱和度值来达到预期效果。 黑板饱和度
可以通过将颜色从灰色的距离作为一个概念来理解饱和度调整。基本思路是将RGB值归一化到0到1之间然后计算它们的平均值例如RGB除以3。接着通过计算每个颜色与平均值的差异即“delta”根据饱和度值乘以这些差异将颜色拉远或拉近灰色。这种方法相对简单不需要进行复杂的颜色空间转换如HSV也能达到调整饱和度的效果。
计算平均值和增量
为了实现饱和度调整可以通过简单的平均值方法来避免复杂的HSV转换。首先计算RGB值的平均值例如R G B / 3得到一个灰度值。为了提高灰度估算的准确度可以考虑根据人的视觉感知例如绿色比红色和蓝色更敏感进行调整但基本思路是通过RGB值计算出一个灰度值。
然后计算每个颜色与平均值之间的差异即“delta”这个差异表示从灰色到原始颜色的距离。接着可以通过将该差异乘以饱和度水平来调整颜色。如果饱和度水平为1.0差异将完全恢复饱和度为0时颜色变为灰色。
这样的方法能够在不进行复杂的颜色空间转换的情况下调整饱和度同时保留原始的透明度Alpha通道。 在游戏中查看然后驱动它通过一个动画参数
在上面的讨论中首先通过简单的方式实现了图像的去饱和化图像变为黑白。这种效果可以通过一个动画参数来驱动使得饱和度变化呈现动态效果。通过使用GameState-Time来控制饱和度的变化可以让饱和度周期性地从全色到无色之间转换。这个效果的计算公式为GameState-Time * 0.5f 0.5 * sin(GameState-Time)通过调整这个公式可以实现饱和度随时间的动态变化。
然而这种实现方式并不是最准确的去饱和化方法。为了提高准确度可以使用HSV颜色空间的快速转换方法。虽然这种方法可能比当前的实现更精确但也不一定是完美的因此如果使用HSV转换并返回到RGB空间能够达到更好的效果。
尽管当前的帧率非常低且优化还不充分但已经能看到饱和度的变化效果。 在这种方案中光会从墙壁等地方水平反射吗
在这个方案中讨论了如何通过反射来处理光照特别是在墙面等物体上实现水平方向的反射。重点是中间层的作用这一层将用于获取局部的反射效果尽管目前并不确定这种方式的效果如何。中间层的目标是模拟光的反射但对于这种方法的实际表现尚未完全确定。
在2D光照的实现中通常采用一些“黑科技”方法效果的好坏取决于这些方法的调优程度。尽管不确定这种方式是否会有效但会继续尝试看看能否从中得到预期的结果。
太棒了现在我们可以过度饱和了
可以通过增加饱和度值来实现过度饱和的效果。通过调整该值可以看到图像的颜色变得更加饱和。此时饱和度的增大会使颜色偏离正常范围从而产生过饱和的视觉效果。
