好久不见！

个人库的地址：（GitHub - JJJJJJJustin/Nut: The game_engine which learned from Cherno），可以看到我及时更新的结果。

-------------------------------Saving & Loading scene------------------------------------

》》》》更改 Premake 文件构架

这一集中 Cherno 对 premake 文件进行了操作，不过此时 Premake 文件的构架发生了改变（现在每个项目的 premake 被放置在项目的文件夹下，而不是集中放置在 Nut 根目录下的 Premake 文件中），这是因为之前的一次 pull request。

本来准备先完善引擎 UI ，后面集中对引擎进行维护，现在看来就先提交一下这个更改吧。

具体可以参考：（ https://github.com/TheCherno/Hazel/pull/320 ）

》》》》一个问题：关于 premake 文件中的命名

当我将 yaml-cpp 作为键（Key) ，并以此来索引存储的值 (Value），此时会出现一个错误：

编译器似乎将 '-' 识别为算术运算符，而不是文本符号，这导致他尝试进行算术运算操作。

但是当我将 '-' 更改为 '_' 时，这样的问题便消失了。

》》》》关于最新的 YAML 导致链接错误的解决方案

编译器疑似在以动态库的方式尝试运行 yaml-cpp 库，并发出了很多警告

初步解决方案：

》》 AND.. 

首先我已经在 yaml-cpp 的 premake 文件中声明了 "YAML_CPP_STATIC_DEFINE" ，并且打开了 staticruntime，但我发现没有作用。

接着解决：

问题是，你还需要在你所使用项目的 premake 文件中再次声明 "YAML_CPP_STATIC_DEFINE"

总结：

》》》》什么是 .editorconfig 文件？有什么作用？

问题引入：在深入研究这次提交时，一个以 .editorconfig 署名的文件映入眼帘，这是什么文件？

文件介绍：

作用：

通过使用 EditorConfig 文件，团队中的每个成员可以确保他们的代码遵循相同的格式，降低因代码风格不一致而引起的问题。许多现代代码编辑器和 IDE（如 Visual Studio Code、Atom、JetBrains 系列等）都支持 EditorConfig，可以自动读取这些规则并应用到打开的文件中。

使用规范：

详情参考文档：（ EditorConfig Specification — EditorConfig Specification 0.17.2 documentation ）

代码理解：

《《《《拓展：什么是 Hard tabs？什么是 Soft tabs？

选择使用哪种方式通常取决于团队的编码标准或个人偏好。

》》》》 Y A M L   U know what I'm saying

》》》》YAML YAML YAML

》》》》关于这次 premake 构架的维护，我只上传了一部分，剩下的留到之后维护时再做。现在我去了解一下 YAML。

》》》》YAML, What is yaml ? What we can do by yaml ?

介绍：

理解：

在程序中，我们可以使用 yaml 对文件进行两种操作：序列化和反序列化（Serialize & Deserialize）。

序列化意味着我们可以将复杂的数据转变为字节流，进而可以将其轻易保存到文件或数据库中。

反序列化则意味着我们可以对已经序列化的数据进行逆处理，进而将数据转换回原始的数据结构或对象状态。

基础：

基本结构

2. 嵌套结构

3. 数据类型

》》》》yaml-cpp 的使用（详情请阅览： https://github.com/jbeder/yaml-cpp/blob/master/docs/Tutorial.md ）

在 C++ 中使用 yaml-cpp 库，可以方便地处理 YAML 数据的读取和写入。（以下是读取 Yaml 文件和写入 Yaml 文件的示例）

YAML::Node

Sequences 和 Maps

Sequences 和 Maps 的不同之处

序列和映射都是 YAML::Node 的一种。你可以在一个映射中嵌套序列，反之亦然。

不同之处：

Converting To/From Native Data Types

YAML-CPP 提供了方便的方法来将 YAML::Node 转换为 C++ 的原生数据类型。你可以使用 as<T>() 方法进行转换。

》》由此引出两个疑惑：

问题一：

查阅文档时，我发现当插入的索引超出当前序列的范围时，YAML-CPP 会将节点视为映射，而不是继续保持序列

结论：动态类型：YAML::Node 的类型是动态的，可以在运行时根据操作的不同而变化。当你使用整数索引时，它保持序列。当你使用非连续的索引或字符串键时，它会转变为映射。

问题二：如何为Node添加一个映射？

在 YAML::Node node = YAML::Load("[1, 2, 3]"); 的情况下，使用 node[1] = 5 是不合适的.

如果你想让 node[1] 表示一个映射，node[1] = 5 会将序列中索引为 1 的元素（即第二个元素）设置为整数 5，而不是将其更改为一个映射。

注意：

》》》》ifstream 和 ofstream 之间的关系

二者定义在 <fstream> 头文件中，管理文件流。

易混淆：<iostream>和文件流没有关系，<iostream> 是提供输入或输出流的标准库，主要包括 std::cin, std::cout, std::cerr 等。

》》 ofstream 的使用：std::ofstream 用于创建和写入文件

》》ifstream 的使用：std::ifstream 用于读入文件，进而对读入的文件进行一些处理。

（图例：逐行读取文件内容到字符串中）

或者（比上述方法更加高效，迅捷）

《《《《 什么是 rdbuf();

在 C++ 中，rd 通常是 "read" 的简写，意味着与读取操作相关的函数。

rdbuf()

》》》》FIEL STRUCTURE   U know what I'm saying

》》》》YAML YAML YAML

》》》》YAML 文件构架，YAML 文件设置思路

因此我们也可解释 Deserialize() 函数中做出的操作：从 data(map) 中取出序列 entities(seq) ，然后通过 For 循环对序列中的 entity(map）进行读取，随后根据读取的数据去复现场景。

需要提醒的是： Map 中的元素不能重复， Seq 中的元素可以重复。

》》》》 YAML::Emitter out << YAML::Flow;

概念：out << YAML::Flow  是 C++ 中使用 YAML 库（如 yaml-cpp）时的一种语法，它用来设置 YAML 输出的格式为“流式”（flow style）。

详解：YAML::Flow 是一个常量，指示输出的 YAML 数据应采用流式表示形式。

  流式表示形式将集合（如数组和映射）以更紧凑的方式表示，例如使用方括号 [] 表示数组，使用花括号 {} 表示映射。

使用场景：

  当你想要以更紧凑的格式输出数据时，可以使用流式表示形式。相比于块状表示（block style），流式表示在视觉上更简洁，适用于小型数据结构或在单行内表示数据。

示例代码：

#include <yaml-cpp/yaml.h>
#include <iostream>

int main() {
    YAML::Emitter out;
   
    out << YAML::Flow; // 设置为流式格式
    out << YAML::BeginMap
        << YAML::Key << "items" << YAML::Value
        << YAML::BeginSeq
            << "item1" << "item2"
        << YAML::EndSeq
        << YAML::EndMap;

std::cout << out.str() << std::endl;
}

》》》》设计上的理解

1.Serialize

2.Yaml data

3.Deserialize

》》 There are few issues you need to know:

1.字符匹配：查找value所用的key需要正确无误，比如你想查找yaml文件中的 Fixed Aspect Ratio，你就必须用 Fixed Aspect Ratio 作为索引，而不是 FixedAspectRatio.

2.Map访问：如果你在map中查找其中存储的元素，你只能访问顶层的元素，而不能访问靠底层的元素。比如 CameraComponent

图例此时处于 cameraComponent，你通过这两个 key 访问其中的 value：Camera 和 Primary（比如调用 cameraComponent["Camera"] ）。可是如果你想通过 CameraComponent 访问 projectionType，就不能使用 cameraComponent["ProjectionType"] 这样的语句，而必须使用 cameraComponent["Camera"]["ProjectionType"]，否则会报错。

》》》》Cherno 将文件保存在 .hazel 后缀的文件中，这可以吗？为什么？只有Hazel 才能处理这种文件吗？？

这取决于你的打开方式，现在 Hazel （或者 Nut） 有能力接受这种文件，通过我们定义的函数，Hazel（或者 Nut）通过文件流合理读入文件，然后识别文件内容并且做出了相应操作。如果你使用 word 打开这种文件，应用程序就会通过文本格式打开这个文件，这样也是被允许的，因为我们就是以文本的形式去设置了 yaml 文件。不过使用其他打开方式可能就会出错。

》》》》注意事项/可改进事项

AND

------------------------------------------ Save/Open file dialog ----------------------------------------------

》》》》什么是 commdlg 库？

概念： commdlg.h 是 Windows API 中的一个头文件，它用于实现标准对话框功能，如文件打开和文件保存对话框。这个头文件定义了与这些对话框相关的结构、常量和函数，使开发者能够方便地在应用程序中集成文件选择功能。

在使用 commdlg.h 时，通常会涉及到以下几个函数：

》》》》 glfw3.h 和 glfw3native.h 这两个库之间的不同

不同：glfw3.h 和 glfw3native.h 之间的区别在于：glfw3.h 用于创建 glfw 类型的窗口， glfw3native.h 用于获取原生操作系统中的窗口的句柄，以此来进行更底层的操作。

》》》》关于 glfw3native.h    和   #define GLFW_EXPOSE_NATIVE_WIN32

首先：glfwGetWin32Window() 是 glfw3native.h 中的函数（以下是其定义）。不过该函数在使用之前，需要通过定义 GLFW_EXPOSE_NATIVE_WIN32 将其暴露出来。

》》》》对话框函数设计思路：

这个函数 FileDialogs::OpenFile 的作用是打开一个文件对话框，让用户选择一个文件，并返回所选文件的路径。

下面逐句解释代码的功能：（标蓝的函数/类型名/变量有额外笔记）

《《 关于 OPENFILENAMEA 的定义

《《 关于 ZeroMemory 函数的定义

在 minwinbase.h 函数中：

《《 ofn.lpstrFilter = filter; 之中，filter 为什么是 const char* ? 填入的时候有什么规范？

lpstrFilter 格式

示例：

const char *filter = "Hazel Files (*.hazel)\0*.hazel\0All Files (*.*)\0*.*\0\0";

格式：

每一组文件类型描述由两部分组成 -> 描述字符串和扩展名字符串：

描述字符串是用户在对话框中看到的文件类型名称，扩展名字符串指定了可以被选择的文件扩展名。各组之间用 \0 分隔，最后以两个 \0 结束。

对话框如何识别和表示：

Hazel Files (*.hazel)\0*.hazel\0 -> 在文件对话框中，用户会看到“Hazel Files (*.hazel)”作为文件类型的选项。当选择这个选项后，对话框会过滤出所有以 .hazel 结尾的文件。

All Files (*.*)\0*.*\0 -> 如果用户选择“所有文件 (.)”，则会显示所有文件，包括 .hazel 文件。

例如：

Nut Scene(*.yaml) 为显示的文本提示，通常设置为你可以选择的过滤器，通过文本提示，代码会索引到合适的过滤器

.hazel 则会根据你选择的文本索引到你设置的过滤器，然后对所有文件进行过滤，如果符合.hazel 后缀，便显示在对话窗口中。

《《  GetOpenFileNameA 函数的作用：

GetOpenFileNameA 是 Windows API 中的一个函数，用于显示一个标准的“打开文件”对话框，让用户选择一个文件。

《《 Flags 详细解释：

在 OPENFILENAME 结构体中，可以设置多个标志（Flags）来控制对话框的行为。

《 关于 OFN_NOCHANGEDIR 的详细说明

背景：在 Windows 应用程序中，当前工作目录是指程序在文件系统中默认访问的位置。当应用程序启动时，它会有一个初始的工作目录，通常是可执行文件所在的位置。

使用场景：

当用户打开文件对话框并选择一个文件时，默认情况下，Windows 会将当前工作目录更改为用户选择的文件所在的路径。这意味着如果用户选择了一个不同位置的文件，之后程序的所有文件访问操作都会基于这个新的工作目录。

然而，在某些情况下，这种行为可能会导致问题。例如：

• 依赖于相对路径：如果程序中的文件操作使用相对路径，工作目录的变化可能会导致文件访问失败。
• 多次调用：如果你的应用程序需要频繁打开文件，改变工作目录可能会使管理变得复杂，特别是在需要回到原始路径时。

假设你有一个文本编辑器应用程序，用户可以打开和编辑多个文件。在这个程序中，用户最开始可能在 C:\Documents 中打开一个文件。

OPENFILENAME ofn;       // common dialog box structure
char szFile[260];      // buffer for file name

// Initialize OPENFILENAME
ZeroMemory(&ofn, sizeof(ofn));
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = hwnd;
ofn.lpstrFile = szFile;
ofn.lpstrFile[0] = '\0';
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFilter = "Text Files\0*.TXT\0All Files\0*.*\0";
ofn.nFilterIndex = 1;
ofn.lpstrFileTitle = NULL;
ofn.nMaxFileTitle = 0;
ofn.lpstrInitialDir = NULL;
ofn.lpstrTitle = "Open File";
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_NOCHANGEDIR;

// Display the Open dialog box
if (GetOpenFileName(&ofn)) {
    // 用户选择了文件
    // 这里可以进行文件读取等操作
}

在此示例中：

如果没有设置 OFN_NOCHANGEDIR，选择一个位于 D:\OtherFiles 的文件可能会把当前工作目录从 C:\Documents 改为 D:\OtherFiles。

这意味着接下来如果程序尝试以相对路径访问文件（例如，读取 data.txt），它会在 D:\OtherFiles 查找，而不是在用户原本的路径 C:\Documents。

加入 OFN_NOCHANGEDIR 后的效果：

通过加入 OFN_NOCHANGEDIR，即使用户选择了位于不同文件夹的文件，程序的当前工作目录仍然保持在 C:\Documents。这样，任何依赖于该目录的文件操作都不会受到影响。

》》》》问题：触发断点 -> 为什么将 CreateRef 改为 Ref 时会触发断点异常？

因为 Ref（std::shared_ptr<T>() ） 创建了一个智能指针，但未分配内存；

而 CreateRef（std::make_shared<T>() ）创建并初始化一个智能指针，同时分配内存并构造对象。

》》》》关于快捷键触发这个事件函数的设计：

1.GetRepeat() 在这里的作用：防止处理重复按键事件。

e.GetRepeatCount() 函数用于获取按键的重复次数。当一个按键被按下并保持时（比如长按），操作系统会不断生成按键按下事件，这样会导致该事件被多次触发。

所以当检测到重复按键时，函数直接返回 false，意味着后续的代码（如处理快捷键的逻辑）将不会被执行。这可以防止同一个快捷键被多次触发，从而避免造成意外的重复操作。

2.这个函数为什么只在事件重复时返回一个布尔量，其他条件下不返回值呢。为什么 GetRepeat() 需要设置在函数最前面？

在事件触发之后，我们运行实际逻辑代码（OpenScene/NewScene），但是我们不能返回 true，因为 true 不会阻止事件运行，这将会导致事件会被连续触发。

其次，如果在逻辑代码之后返回 false，而不是在函数开头返回 false，都会导致事件被触发第二次，因为在判断是否重复触发时依旧会先运行逻辑代码，随后判断出来结果是 false（应该阻塞），不过此时已经没有用了。

3.GetKeyCode 和 GetRepeatCount 中返回的 keycode 和 count 是在哪里自动获取的，所以我们才能使用其返回值来进行判断

在之前设置的回调函数中：WindowsWindow.cpp 中

4.为什么只有在鼠标单击了视口这个区域时（聚焦在 Viewport 窗口时），快捷键才能使用？

因为是在 EditorLayer::OnEvent() 函数中设置的事件分发。

--------------------------------------- ImGuizmo ---------------------------------------------

》》》》这段 premake 代码什么意义？

》》》》为什么Nut-editor 中没有包含 ImGui 库目录却可以使用 ImGui，但是没有包含 yaml-cpp 库目录的时候却不能使用 yaml-cpp?

因为实际上 ImGui 在 "%{wks.location}/Nut/vendor" 中已经被包含了。

》》》》代码设计：gizmo库中对于 ImGuizmo.cpp 的更改：（ https://github.com/TheCherno/ImGuizmo/commit/218d60bde7d22061ac525d0d71e05360b4dcf978）

我猜想Cherno做的是一些对于 ImGuizmo 样式的更改，并且由于时间原因，最新的 ImGuizmo.cpp 结构发生了很多改变，这让我不容易同步这个更改。

所以我决定先保持默认值，后续再查看是否需要同步此更改。

》》》》什么是万向锁，什么情况下会触发万向锁？什么是四元数，为什么四元数可以解决万向锁？ glm/gtx/quaternion.hpp 中处理四元数的函数怎么使用？

万向锁（Gimbal Lock）

万向锁是一种在三维空间中旋转时遇到的现象，通常发生在使用欧拉角表示旋转的情况下。它指的是在某些特定的旋转配置下，系统的自由度减少，使得无法进行预期的旋转。

万向锁通常在以下情况下发生：

万向锁的影响：

当发生万向锁时，物体可能会无法按预期方向旋转，或者某些旋转会变得不可用。这在动画、飞行控制和机器人运动等应用中会造成问题。

参考文档：（ https://medium.com/@lalesena/euler-angles-rotations-and-gimbal-lock-brief-explanation-de1d4764170 ）

参考图片：

https://miro.medium.com/v2/resize:fit:498/format:webp/1*7JT7g5dLeZ-Q5uOYnX8hCw.gif

https://miro.medium.com/v2/resize:fit:400/format:webp/1*OCkqKWmTtmDtzrukAX4hSA.gif

四元数（Quaternion）是一种扩展了复数的数学结构，通常用于表示三维空间中的旋转。它由一个实数部分和三个虚数部分组成，形式为：

q=w+xi+yj+zkq=w+xi+yj+zk

其中：w 是实数部分，x,y,z 是虚数部分（向量部分），i,j,k 是虚单位。

四元数通过以下方式解决万向锁问题：

参考文档---涉及到数理知识：（  3D数学：欧拉角、万向锁、四元数 - HighDefinition - 博客园 ）

》》》》代码设计： TransformComponent 中的更改：

这可以防止通过 imGuizmo 调整物体旋转时图像极速发生变化的问题（通过 ImGuizmo 可视化工具轻轻更改欧拉角，角度却会极速增加，这会导致图像迅速旋转并闪烁）

并且防止可能出现的万向锁问题（可以查看上述的： 万向锁（Gimbal Lock）  ）。

》》》》一些 ImGuizmo 函数：

》》》》 ImGuizmo::SetRect()

释义：ImGuizmo::SetRect() 是 ImGuizmo 库中的一个函数，用于设置 ImGuizmo 操作区域的矩形。

          在使用 ImGuizmo 进行变换操作时，你需要定义一个矩形区域来限制 ImGuizmo 的界面和交互区域。这通常是你在应用程序中想要显示和使用的 GUI 区域。

函数原型： void SetRect(float x, float y, float width, float height);

参数解析：

》》》》ImGuizmo::SetDrawList();

ImGui 的绘制列表

定义: 在 ImGui 中，绘制列表（ImDrawList）是一个存储了绘制命令的对象，包含了要渲染的所有图形的信息（如线条、矩形、文本等）。

功能: 每个 ImDrawList 都包含了多种绘图命令和状态信息，例如：

顶点数据

颜色

纹理….

ImGuizmo::SetDrawList() 

释义：

原型：static void SetDrawList(ImDrawList* draw_list);

参数：

draw_list: 指向 ImDrawList 的指针，这是一个 ImGui 的绘制列表，用于管理和记录图形的绘制命令。

示例：

ImDrawList* backgroundDrawList = ImGui::GetBackgroundDrawList();

ImDrawList* foregroundDrawList = ImGui::GetForegroundDrawList();

// 在背景绘制列表中绘制某个背景元素

backgroundDrawList->AddRectFilled(ImVec2(0, 0), ImVec2(100, 100), IM_COL32(50, 50, 50, 255));

// 在前景绘制列表中设置 gizmo 绘制

ImGuizmo::SetDrawList(foregroundDrawList);

ImGuizmo::SetRect(0, 0, ImGui::GetWindowWidth(), ImGui::GetWindowHeight());

ImGuizmo::Manipulate(viewMatrix, projectionMatrix, ImGuizmo::OPERATION::TRANSLATE, ImGuizmo::MODE::LOCAL, &modelMatrix[0][0]);

》》》》 ImGuizmo::Manipulate()

释义：ImGuizmo::Manipulate 是 ImGuizmo 库中用于处理物体变换的函数。这个函数可以在用户界面中允许用户通过拖动来对物体进行平移、旋转和缩放操作。

函数原型：

bool Manipulate(const float* view, const float* projection,
                OPERATION operation, MODE mode,
                float* matrix, float* deltaMatrix,
                const float* snap = nullptr, const float* pivot = nullptr);

参数解析:

》》》》ImGuizmo::OPERATION 的定义

》》》》代码设计：窗口响应

更改前：只要不满足 聚焦于窗口上/悬停在窗口上 的任一一个条件，便会阻塞当前窗口中的事件（不再捕获鼠标或键盘的活动）

更改后：只有 窗口没有被聚焦且鼠标没有悬停在窗口上的时候，才会阻塞事件。

这让我们在结构面板中选中实体之后，只需要将鼠标悬停在 viewport 窗口上，便可以通过键盘调整/响应 Gizmo，这在实际使用中很舒服（  本人亲测 :>

》》》》为什么这里需要使用 Const 标识？

可能是因为不需要对 cameraComponent 进行更改吧。

》》》》这个函数的意义？

》》》》这段代码的意义？

------------------------------------ Editor camera ------------------------------------------

》》》》 关于引擎的操作界面和简单操纵，我们已经完成了很多，Cherno 在接下来将开始实现鼠标选择实体，不过我可能会将之前遗漏的维护补充一下。

》》》》总之先让我们开始这一集吧。

》》》》这一集中，主要围绕 编辑时摄像机 和 运行时摄像机 两个概念来设计。

我目前是这样理解的：

• 编辑时摄像机：用于在引擎中编辑物体，此摄像机为默认存在。只要你需要对物体进行编辑，那么直接建立一个 sprite 实体，在编辑器中便应该能够直接查看和编辑该实体，而不需要额外添加摄像机（运行时摄像机），这符合游戏引擎的使用逻辑。
• 运行时摄像机：用于在实际游戏程序运行时添加，此摄像机需要手动添加。游戏中不需要“上帝视角”的编辑时摄像机，而只需要用来观察物体的运行时摄像机，该摄像机不像编辑时摄像机一样默认存在，因为编辑器和游戏程序的逻辑是不同的。

这两个摄像机不是同时存在的：在编辑器中，底层默认存在一个编辑时摄像机，该相机只在编辑器运行时存在并更新；同样的，游戏程序中不使用编辑时摄像机，而是用运行时摄像机，该相机只在游戏程序运行时存在并更新。

由于我们现在在编辑器中设计程序，所以只需要对所有实体使用编辑时摄像机即可。对于游戏，我想我们应该需要在编辑器中添加一个游戏运行时摄像机，然后打开游戏程序，进行游玩。

---------------------------- Multiple Render Targets and Framebuffer refactor----------------------------------

》》》》很久没 commit 了，之前准备先做维护，奈何 Cherno 后面实现的内容太过诱人，好奇心驱使我又观看了五六集，维护的事情后面再说吧 X-D

》》》》接下来我将努力实现 Mouse Picking，然后根据个人时间考虑内容浏览面板的制作，或者是提交一波维护，因为维护已经落下很久了。

》》》》前言：

》》》》gl_VertexID 在 GLSL 中关于顶点ID的一些细节：

》》》》这一节的概述：

Cherno 为了实现类似顶点ID的效果，于是开始更改帧缓冲的操作模式。这样一来就可以更方便的实现鼠标选中，在这一节中，Cherno 只是对帧缓冲的实现过程进行了完善，使代码可以通过初始化列表标识帧缓冲，并自动的识别这些标识用来创建帧缓冲。虽然是顶点ID的前瞻操作，但实际上只是一些铺垫，不必担心看不明白。

》》》》代码的理解：

反复观看代码之后，我将所有代码分为两部分：设置结构体 和 重构帧缓冲的创建，第一部分的作用是：通过声明一些结构体来简化帧缓冲的使用方式/简化帧缓冲的设计，第二部分的作用是：通过已有的条件，动态的构建帧缓冲。

这引出了我的一些问题：

In FrameBuffer.h

》》这三个结构体有什么作用？之间有什么关系？

In OpenGLFrameBuffer.h

》》m_ColorAttachmentSpecification 和 m_ColorAttachments 的区别在哪里？分别起到什么作用？

前言：帧缓冲中的纹理与纹理附件的关系？帧缓中是否可以包括多个纹理？一个纹理中是否可以附加多个纹理附件？这些附件有什么作用？

一个帧缓冲绘制的场景中可以绘制一些物体，也可以绘制多个纹理，而纹理附件则是存储这些渲染结果的地方。此时如果你使用帧缓冲中的颜色附件作为纹理进行后续渲染，那这个颜色附件就可以被称为纹理附件。

在帧缓冲中每一个纹理的创建都和普通纹理的创建过程差不多，不过我们需要对这些纹理额外的附加 Attach 一些附件。一个纹理可以附加多个附件（颜色附件可以同时附加多个，但深度附件一般只能附加一个），如果你在帧缓冲对象（FBO）中使用多个颜色附件，那并不意味着你能绘制更多的物体，而是指在一次渲染过程中，你可以同时输出多个数据流。

m_ColorAttachmentSpecification 用于存储所有的纹理附件，而 m_ColorAttachments 存储的是帧缓冲中所有纹理附件的 ID 。

》》那么这个ID是怎么分配的呢？

》》这个 ID 是怎样和片段着色器中的输出变量 Color 关联起来的？也就是说纹理附件的 ID 是怎样和片段着色器中的输出变量关联起来的？

比如 Cherno 是怎样明确纹理附件的 ID：0 就指的是片段着色器中的第1个颜色（输出变量），ID：1就指的是片段着色器中的第2个颜色（输出变量）。

Eg.

通过纹理 ID 索引到纹理附件

通过纹理附件（颜色附件）索引到输出变量

现在我们已经可以通过纹理 ID 索引到想要访问的纹理附件了，可如何将 ID 与片段着色器中的颜色输出变量联系起来？

渲染目标的设置：在使用多重渲染目标（MRT）时，可以将片段着色器的输出变量映射到不同的颜色附件。

Eg.

》》》》代码上的疑问：为什么需要在附加附件之前创建纹理

为什么每附加一个附件就需要创建一次纹理？

虽然一个纹理对象可以附加多个颜色附件，且只能附加一个深度附件，那为什么需要在附加深度缓冲附件之前再次新建一个纹理？

这些纹理都代表什么，为什么可以创建这么多？

颜色附件和深度附件的规范

创建多个纹理的原因

在深度附件之前创建纹理的原因

》》》》附件的附加代码：附加时使用不同函数的意义是什么？

两种附件中使用的函数 ： glTexImage2D 和 glTexStroage2D 区别在哪里？

1. 创建纹理存储的方式

适用场景：

》》关于纹理创建和附加操作的一点理解：

1 由于颜色附件（纹理附件）需要附加多个，所以需要创建多个纹理，并逐一对其进行 Attach 操作。

2 但是深度附件只需要添加一个，所以只创建一个纹理，并对其进行一次 Attach 操作。

》》》》以下两段代码的区别

和

的区别：

答：Size > 1 是数量从 2 开始的情况，!empty() 是数量只要不为0，也就是数量从 1 开始的情况。

》》》》glDrawBuffers 函数的作用是什么？

--------------- Preparing mouse picking (Get mouse pos and Read pixel) ---------------------------------

》》》》关于这一集，可以分为三部分：1.调整帧缓冲的使用方法    2.读取当前帧缓冲区（或指定帧缓冲区）中的像素数据   3.获取正确的窗口大小边界，并获取鼠标相对于窗口中的位置

》》》》关于读取当前帧缓冲区（或指定帧缓冲区）中的像素数据

glReadBuffer

glReadPixels

》》》》关于窗口和鼠标交互部分代码的理解

// 确定窗口边界（考虑标签栏）

auto viewportOffset = ImGui::GetCursorPos(); // Includes tab bar

auto windowSize = ImGui::GetWindowSize();

ImVec2 minBound = ImGui::GetWindowPos();

minBound.x += viewportOffset.x;

minBound.y += viewportOffset.y;

ImVec2 maxBound = { minBound.x + windowSize.x, minBound.y + windowSize.y };

m_ViewportBounds[0] = { minBound.x, minBound.y };

m_ViewportBounds[1] = { maxBound.x, maxBound.y };

// 确定鼠标在视口中的相对位置，并做出对应的操作

auto[mx, my] = ImGui::GetMousePos();

mx -= m_ViewportBounds[0].x;

my -= m_ViewportBounds[0].y;

glm::vec2 viewportSize = m_ViewportBounds[1] - m_ViewportBounds[0];

my = viewportSize.y - my;

int mouseX = (int)mx;

int mouseY = (int)my;

if (mouseX >= 0 && mouseY >= 0 && mouseX < (int)viewportSize.x && mouseY < (int)viewportSize.y)

{

int pixelData = m_Framebuffer->ReadPixel(1, mouseX, mouseY);

HZ_CORE_WARN("Pixel data = {0}", pixelData);

}

 ----- ImGui::GetCursorPos()

注意

ImGui::GetCursorPos() 返回的是 ImGui 光标的位置，而不是鼠标光标的位置。这里的“ImGui 光标”是一个特定的概念，与 GUI 元素的布局和绘制有关。

ImGui 光标

概念：在 ImGui 中，光标是用于管理和控制 UI 元素（如按钮、文本框、滑动条等）排列和绘制的一个指示器。它并不是真正的鼠标光标，而是指示下一个元素应该放置在何处的虚拟光标。

特性：

实际应用：

当你在 ImGui 中创建界面时，通常不会直接处理鼠标光标的位置，而是依赖于 ImGui 光标自动控制 UI 元素的布局。

Eg.

ImGui::Text("Hello, World!");
ImGui::Button("Click Me!");

在这个例子中，Text 和 Button 会根据 ImGui 光标的位置自动排列。当第一个元素被绘制后，光标会向下移动，按钮会出现在文本的下方。

ImGui光标的格式

----- ImGui::GetWindowSize()

----- ImGui::GetWindowPos()

----- ImGui::GetMousePos()

《《代码理解：为何以下代码可以动态的计算出视口（窗口）的可用区域？（动态：指的是可以根据标签栏是否存在，计算出此时的窗口可用区域）

auto viewportOffset = ImGui::GetCursorPos(); // Includes tab bar

ImVec2 minBound = ImGui::GetWindowPos();

minBound.x += viewportOffset.x;

minBound.y += viewportOffset.y;

根据上述 GetWindowSize() 函数的理解，我们得知这个函数返回的是 ImGui 光标的位置。这个光标记载了 ImGui 控件的位置，当便签栏存在时，这个函数返回的值会发生变化（无标签栏时返回可用区域的左上角坐标；有标题栏的时候，会因为窗口中多绘制的标题栏控件，而返回已经发生变化的坐标）

（全局坐标 + 相对坐标 -> 符合需求的全局坐标）

由于 ImVec2 minBound = ImGui::GetWindowPos() 这里得到的是窗口在屏幕中的全局坐标，而 ImGui::GetCursorPos() 得到的是控件在窗口中的相对坐标，所以对于这个全局坐标，我们加上相对坐标，便可以计算出控件存在时的可用范围。

无标签栏时：

有标签栏时：

《《 代码理解：如何计算的相对坐标（相对坐标->指的是将鼠标的全局位置修改为相对于视口窗口的坐标，准确位置相对于视口窗口的左上角。因为对于鼠标坐标，我们都对其减去了minBound）

auto[mx, my] = ImGui::GetMousePos();

mx -= m_ViewportBounds[0].x;

my -= m_ViewportBounds[0].y;

（全局坐标 - 全局坐标 = 对于窗口的相对坐标）

计算全局鼠标坐标相对于窗口的位置，比如：假设全局鼠标坐标是 (500, 300)，窗口左上角的坐标是 (450, 250)。通过计算：

mx = 500 - 450 = 50

my = 300 - 250 = 50

这表明，鼠标在窗口中的位置是 (50, 50)，即距离窗口左上角50像素的位置。

》》》》一个小Bug：（白色小光标表示鼠标位置）

正确的操作：

错误的操作：当鼠标在视口中，但是鼠标位于视口靠上方时，会出现无效值。

发生这个错误的原因是：ImGui::GetWindowSize() 获取的是整个窗口的尺寸，包括边框和标题栏等。而我们需要的窗口的客户端区域尺寸不包括能边框，否则在计算鼠标相对与窗口左上角的位置坐标时，我们获取的坐标 mouseX , mouseY 会发生偏移，想要解决这个问题，就应该使用 ImGui::GetAvailableRegion() 来获取窗口尺寸。

而 m_ViewportSize 恰好是这样获取的。

》》》》疑问：

疑问1.0：为什么需要特别计算一个 viewportSize ，以此作为判断依据呢？为什么不可以按照 maxBound 来判断呢？

比如这样：

答：因为 m_ViewportBounds[1] 中存储的 maxBound 是屏幕全局中的坐标，而这里我们获取的鼠标坐标是经过处理的视口相对坐标，所以如果需要进行条件判断，则必须按照 minBound 和maxBound 计算出从[0,0] 开始的整个视口的相对坐标，并将其作为判断依据。

疑问1.1：但是ReadPixel中也填写了mouseX,MouseY这两个相对坐标，这是否正确？

正确，因为这个函数是使用在 Framebuffer 之下的，我们使用 mouseX 和 mouseY 来读取视口中的数据。虽然 mouseX,MouseY 并不是整个屏幕上的绝对坐标，但他们是窗口上的相对坐标。由于窗口完全被视口填充，且这个坐标的大小也被限制在视口的尺寸之内，所以这两个坐标可以表示视口（"Viewport"这个窗口）中的位置，因此这个函数参数的使用是正常的。

疑问2：这里对于坐标进行整形转化的用意是什么？不做会怎样？

《《《《 Tips: You can use (  ImGui::GetForegroundDrawList()->AddRect(minBound, maxBound, IM_COL32(255, 255, 0, 255));   ) to draw the available region with colored rectangle

--------------------------------Clear texture attachments & Support multiple entity IDs--------------------------------------------

》》》》这一次我要提交两个部分：清除和多个实体ID（清除指的是将空白区域的鼠标输出改为：-1，多实体区域指的是每一个实体都将拥有一个ID，作为鼠标输出）

》》》》一些当下的理解：

当前，我们创建了一个帧缓冲对象，并且为其创建了两个颜色附件（纹理附件）：RGBA8、RED_INTEGER，一个深度附件、一个模板附件。

其中颜色附件的RGBA8被用来绘制物体，RED_INTEGER被用来储存或处理实体ID。

而且由于我们使用了批渲染，所以理论上所有渲染的物体应该是一个整体，所以不用使用多个颜色附件。

在实际的代码操作中，我们会根据 FrameBuffer::Create 填入的参数顺序来分配附件索引，也就是说：

如此一来，我们可以访问不同附件插槽上的数据，如果此时我们在着色器中设置了 color2 ，并将其作为 Attachment1，就可以读取到我们在着色器中对其设定的值。（此处示例为 color2 = 50)

如果我们选择在特定情况下读取该附件的内容，并打印，才会有类似的效果。

但是只有鼠标停留在窗口中已绘制的物体上时，才可以访问到有效的 Attachment （如果鼠标停留在窗口内空白区域，此处没有绘制物体，而附件 Attachment 又恰恰是在绘制一个物体时才创建的，所以此时打印的值是无效数字 : 1036831949）

如果此时想清除空白区域的无效数字，则需要在访问所有区域之前，使用 ClearTexImage() 清空所有数据（使用 ClearTexImage() 将 Attachment0 + index 这里的数据临时更改为指定值：-1），这样一来当鼠标位于空白区域时，就会返回我们设置的值。（如果后续鼠标会位于物体上，我们只需要使用函数 ReadPixel() 重新读取 Attachment0 + index 存放的值即可。）

》》》》关于 glClearTexImage()

glClearTexImage()

------------------------- Unique Entity ID for mouse picking (Mouse picking) -----------------------------

》》》》这一次提交的主要思路为：为顶点再添加一个属性 -> EntityID，这个 EntityID 会被实体默认生成的ID所填入，进而在顶点中标识某一个实体，我们也可以访问到。

具体思路是：

1. 确定新的顶点属性 layout( location = 5) in int a_EntityID  

2. 根据这个新增的顶点属性，我们首先需要更改着色器中的对应语句。其次，还需要更改 VertexArray 的 SetLayout() 函数，以便我们能够正确的添加新增的顶点属性 。最后，我们还需要更改实际的绘制函数，以便我们在绘制的过程中保存对应的 entityID

3.调用更新后的绘制函数，为图像添加新的顶点属性

4.也可以通过读取出来的 EntityID 将实体信息放在 ImGui 窗口中实时查看

》》》》我们在 OpenGL 上下文中访问的顶点属性数据（比如访问片段着色器中的输出变量 color2），此时这个变量存放在哪里？我们从哪里读取到这个数据？

前提：

Eg.假设这里有一段着色器代码(glsl)

Vertex shader

#version 330 core

layout(location = 0) in vec3 a_Position;  // 顶点位置

layout(location = 1) in int a_EntityID;   // 顶点的 EntityID（来自顶点缓冲区）

out flat int v_EntityID;  // 传递给片段着色器的 EntityID

void main()

{

    gl_Position = vec4(a_Position, 1.0);

    // 将 EntityID 从顶点着色器传递到片段着色器

    v_EntityID = a_EntityID;  }

Fragment shader

#version 330 core

// 接收来自顶点着色器的 EntityID

in flat int v_EntityID; 

out vec4 FragColor;

void main()

{

    FlagColor = v_EntityID;

}

首先让我们明确一下使用逻辑：

》此时我的问题是，在访问过程中，片段着色器中的 FlagColor  变量存储在哪里？因为 FlagColor  = v_EntityID，我还想知道 v_EntityID 此时存放在哪里？

问题一：v_EntityID 存放在哪里？

传递过程：

当 OpenGL 上下文尝试访问 v_EntityID 时，是从顶点着色器传递来的。这是具体的传递过程：

顶点缓冲区存储：每个顶点有一个对应的 EntityID，通常通过顶点属性传入（比如通过 a_EntityID）。

顶点着色器处理：顶点着色器将 EntityID 从输入的顶点数据传递给片段着色器（通过 out 变量 v_EntityID）。

片段着色器访问：片段着色器通过 in 变量 v_EntityID 获取这个值，并根据它执行不同的渲染操作。

所以，v_EntityID 实际上是存储在 GPU 的顶点缓冲区中的，并在顶点着色器和片段着色器之间传递。

问题二： FlagColor（Color2)存放在哪里？

在大多数情况下，这些输出值被存储在与当前绑定的帧缓冲关联的颜色附件中，比如片段着色器的输出通常会存储在帧缓冲的一个 颜色附件（Color Attachment）中。

OpenGL 允许你绑定多个附件位置，我们可以通过 OpenGL 提供的宏常量：GL_ATTACHMENT0，GL_ATTACHMENT1 ….. ，通过附件绑定的位置访问附件。

》》》》GLSL 中的 flat 修饰词有什么作用？

实际情况说明：

在没有 flat 修饰符的情况下，当你从顶点着色器向片段着色器传递数据时，数据会被插值。而插值是为了平滑过渡而设计的（通常应用于浮点数），所以，如果你希望 v_EntityID 在片段着色器中始终保持不变（不被插值），你需要使用 flat 修饰符来阻止插值。

例如，在光栅化过程中，可能有多个片段（像素）在不同的计算单元上处理，如果没有 flat 修饰符，v_EntityID 会进行插值操作，但由于 int 类型是离散的，插值可能会导致无效的值（例如，v_EntityID 在两个顶点之间的值不会是整数，可能导致错误）。此时使用 flat 可以避免这种插值，确保每个片段获得完全相同的值。

错误注意：

》》》》glVertexAttribIPointer( ) 有什么意义？怎么使用？

glVertexAttribIPointer() 是 OpenGL 中的一个函数，专用于设置整数类型的顶点属性指针。

这个函数的作用是告诉 OpenGL 如何在顶点缓冲区中读取顶点属性数据，尤其是当这些数据是整数类型时。它类似于 glVertexAttribPointer()，但专门处理整数类型数据，而不涉及浮点数据。

》》》》运行之后，我注意到一个问题打印出来的 EntityID 为什么不是 0,1,2 而是 0,2,3 ?

这是因为我们在 yaml 文件中存储的实体顺序是这样的（我们不仅存储了三个物体实体，还存储了一个摄像机实体，而这个摄像机实体由于一些原因被放置在第二个实体的位置上）

》》而我们只需要在文件中调整几个实体的位置即可实现 0,1,2 的效果：

》》》》使用思路：这句代码是怎样实现对应功能的？

m_HoveredEntity = pixelData == -1 ? Entity() : Entity((entt::entity)pixelData, m_ActiveScene.get());

前提：在使用 Ctrl + O 之后，会调用一个函数 --> OpenScene();  这个函数将会继续调用 --> serializer.Deserialize(filepath);  在 Deserializer() 中，有这两句代码：

 Entity& deserializedEntity = m_Scene->CreateEntity(name);       // Create a new entity in m_Scene with all default values

 DeserializeEntity(entity, deserializedEntity);                  // Update values in this entity accroding to yaml file

也就是说， OpenScene() 函数会为我们创建实体，通过调整实体的属性，我们得以在引擎中查看文件的内容。

理解：所以在我们打开某个文件之后，画面中绘制的所有物体，其实就是我们创建的实体（这些实体在 OpenScene() 中被创建，并且调整了组件中的属性:Translate, Color ….）。如果此时我们在特定情况下，使用相同的数据再次创建一个新实体（Entity 类型对象），就可以确保新实体是对应旧实体的副本。

Eg.

Ctrl + O 打开文件，最终会运行此函数。其中高亮的代码部分会确保我们在读取文件之后，创建 YAML 文件中的实体

CreateEntity() 会创建实体，m_Registry.create() 会自动分配 entityID，这个ID是唯一的。

这时，比如在代码中，如果鼠标光标在视口范围内、且悬停在物体上方，我们就创建实体：HoveredEntity

由于我们在 DrawQuad() 这个绘制函数中，将 EntityID( EntityHandle )传入了顶点着色器，所以通过 ReadPixel() 我们可以读取对应的 EntityID。并使用这个 EntityID(pixelData)创建一个实体。

那么这个实体 和 打开YAML文件时创建的实体 有什么联系呢？为什么我们可以通过 HoveredEntity 使用 GetTagcomponent()，访问到先前实体的数据？

因为 Deserializer() 中创建的实体，是通过 EntityID( m_Registry.Create() ) 和 Scene( this 即 m_ActiveScene )创建的，这两个参数都是唯一的标识，我们可以通过这样的唯一标识访问组件。

如果此时我们又新建了一个实体，比如HoveredEntity， 并使用了相同的参数将其初始化，这样我们就拥有了先前实体的一个副本，这个副本就是 HoveredEntity。由于  HoveredEntiy 中保存着这些唯一标识，我们当然可以使用 GetComponent() 访问到对应的组件，并且组件的内容 等同于 先前实体组件中的内容。

》》》》代码中的 OpenGL 版本号管理代码，在哪里？

在代码中并没有明确表示OpenGL版本号( 比如通过 GLFWWindowHint() 设置版本号），所以GLFW 会检测你的图形卡及其驱动程序支持的 OpenGL 版本。如果没有明确指定版本，GLFW 会选择一个合适的默认版本，通常是当前系统支持的最新版本。

本机为：

》》》》我对Cherno的代码做了一点更改

在这里，我觉得满足条件判断之后，会一直调用构造函数，可能比较耗费性能。

更改之后：

不过从数据分析上看起来，虽然优化了一部分性能，但是本来好像就没有很大的性能负担。:-)

--------------------------------- Left click to select entities -----------------------------------------

》》》》ImGuizmo::IsOver( )

》》》》我所做的改进：

我新添了一个实体，这个实体只在 鼠标单击具体物体 / 单击某一实体的 Guizmoa 时更新实体，这样一来，尽管 HoveredEntity 会因为鼠标的位置实时发生改变，但是 UsingEntity（Entity in use) 不会轻易改变，只有鼠标操作某一物体时才会发生更改。

m_UsingEntity 逻辑更新代码：

ImGui::Text() 打印代码：

----------------------------------- Maintenace ---------------------------------------------------

》》》》后续会整合 Jul/22 2020 之后的维护