对的

多等等看，不放心可以在每一步都打一下日志看看在什么地方卡住了。提问的时候具体一点，不然大家也只能帮你猜

你的 object.cpp 是 UTF-8 with BOM 格式的，解码不了。

UTF-8 和 UTF-8 with BOM 的区别主要在于 Byte Order Mark（BOM）的存在。以下是两者的具体区别：

UTF-8

• 定义：UTF-8（8-bit Unicode Transformation Format）是一种可变长度的字符编码，用于表示 Unicode 字符。它可以编码任何 Unicode 字符，且向后兼容 ASCII。
• 特点：UTF-8 不包含任何前导字节，即没有 BOM。它直接从文本的第一个字节开始编码字符。

UTF-8 with BOM

• 定义：UTF-8 with BOM 是 UTF-8 编码的一个变体，开头包含一个特殊的字节序标记（Byte Order Mark, BOM）。这个 BOM 由三个字节组成：EF BB BF。
• 特点：BOM 用于标识文件的编码格式（在本例中为 UTF-8），并且在某些情况下有助于软件识别文件的编码。然而，对于 UTF-8 来说，BOM 并不是必需的，因为 UTF-8 本身不区分字节顺序。

使用场景和影响

• 兼容性：许多文本编辑器和编译器能够识别和正确处理 UTF-8 BOM。然而，有些系统或工具可能会将 BOM 作为文本内容的一部分进行处理，从而导致问题。
• 跨平台性：在跨平台开发中，尤其是 Web 开发，通常建议不使用 BOM，因为某些浏览器和服务器可能无法正确处理包含 BOM 的文件。

示例

• UTF-8：

  61 62 63 0A (表示文本 "abc\n")
  

• UTF-8 with BOM：

  EF BB BF 61 62 63 0A (表示文本 "abc\n"，包含 BOM)
  

在你组装完三角形以后，光栅化时进行视口剔除。文档只要求大家做视口剔除。

你可以先用简单的 cube 模型进行测试，方便找到和复现你的错误，自己检查是不是什么位置的指针写错了

可以完全自定义场景

1. 本实验主要是在“软”光栅的基础上实现并行，所以不涉及 GPU，而且也不是所有设备都支持 CUDA。
2. 我不知道你看的是哪篇公开文章，但是在某些时候是可能发生超线性加速的，具体可以参考 加速比 - 维基百科，自由的百科全书。
3. 你当然可以在 work_thread 内部再维护一些线程在内部再进行任务的并行运算，但是没有必要。如何保持这些内部线程数据一致性，并且达到加速的效果，是个比较麻烦的事情。所以考虑如何增加各个阶段的 work_thread，以及如何优化各个阶段内的算法，就已经足够了。

你的法线计算是不是正确的？修改环境光也是这样的吗？

你按照构建指南下载对应的链接库文件并放到指定位置了吗？

只做 2.2 的话可以不用考虑

验收回答一下问题就可以了

法线和坐标也要进行透视矫正插值

为简单起见不用考虑反射后的光线经过光源的情况，只用判断场景内有 mesh 的物体间有没有发生相交，ior 自己设定一个值就可以了

不影响

实验 2.6 已经修复，会帮你重新提交。但是实验 2.1 等提交中，我发现你没有主动进行类型转换，你提交的代码中把原本存在的 static_cast<int> 删除了。

一般来说，段错误是由于非法的内存访问引起的。所以建议你在模型加载的代码部分前后，加入探针进行问题定位，找到发生段错误的具体位置。

请检查你的光线方向，视线方向等计算是否正确

如果不是直接使用现成的 API，例如 Eigen 提供的四元数欧拉角转换。只要通过了测试，就不可以再次提交了。

提问前请先看看历史帖子，以前就有同学问过

单元测试进程不会修改 dandelion 进程里的数据，所以自然不会修改图形界面里的内容，你查看 test 里的代码就知道了

稍后会进行检查和修改，谢谢你的提问

如果能正常编译的话，是不会出错的，但是请把每个实验做过的修改分开。

测评服务器已将 dandelion 版本更新到了 1.1.0 版本，现在应该没问题了，可以再提交试试

检查 server log，可以看到 CMake 提示 C:/data/submissions/tmp/build/deps/fmt 目录不存在，这是因为你在指定 SOURCE_DIR 时指定的是 optimier 下的 deps/fmt，而 build 目录中没有 deps 文件夹，自然也没有 fmt。所以总而言之，就是你的 fmt 路径指定有问题。我在修改你的 FetchContent 中的 SOURCE_DIR 后就可以成功生成项目了。

你的 CMakeList 在配置 fmt 时指定的源位置有问题，CMake 找不到，也就没办法生成解决方案。这个和你用没用 Visual Studio 没关系。

把 rar 压缩包后缀名改成 zip 难道就变成 zip 压缩包了吗？
用可口可乐瓶子装百事可乐难道就变成可口可乐了吗？
可乐没变，压缩包大概或许，也没变吧

可以从 Realease 里下载测试集
Release Fall 2023 Lab Docs · XJTU-Graphics/Dandelion-docs (github.com)

不冲突，就是这样的

你可以用一些 debug 的工具观察内存中的变量变化，尝试观察执行 flip 操作的边附近面的数据变化，看看其有没有真的消失，进而判断是否是反转操作有误，还是框架本身有 bug。