Con*_*Man 4 3d graphics modeling
经过一段时间的 3d 建模并享受 ZBrush 无可挑剔的性能和众多功能后，我认为创建类似的东西，只是一个小型雕刻工具，对我来说是很好的 OpenGL 实践。果然我做到了，我当然无法与 ZBrush 的表现相提并论，因为一群高薪的专业人士如何胜过业余爱好者。目前我只是假设 ZBrush 是硬件加速的，想象一下当我发现它不是的时候我的惊讶，而且它既不使用 opengl 也不使用 direct3d。
这让我想在较低级别学习图形，但我不知道从哪里开始。图形库是如何制作的，以及如何在不使用 opengl 的情况下访问帧缓冲区。在没有任何预先存在的工具的情况下只显示一个像素会有多少麻烦，以及是什么魔法赋予了 ZBrush 这样的性能。
我很感激有关任何问题的任何信息以及对涵盖这些主题的书籍的推荐。我已经在阅读 Michael Abrash 的 Graphics Programming Black Book，但它并没有真正解决这些问题，或者我还没有达到那个点。
先感谢您。
（请不要发布诸如“只使用 opengl”或“学习数学”之类的答案，这似乎是我发布此问题的任何地方的反应，但这些回复与主题无关）
小智 6
ZBrush 在性能方面非常出色，但我认为这是因为它是由具有汇编专业知识的图像处理专家制作的（这也可能是由于大量的汇编代码，他们在移植到 64 位方面已经晚了近 20 年） . 它实际上开始时没有任何类型的 3D 雕刻，只是一个 2.5D 的“像素”画家，您可以在画布上喷涂像素，并为“像素”提供一定的深度和照明。直到 ZB 1.5 左右才开始雕刻。即便如此，当类似大小的画笔仅使用 Photoshop 或 Corel Painter 绘制平面像素会使帧率变得口吃时，它也给人们留下了深刻印象，您可以在画布上喷涂这些 2.5D“像素”的速度有多快。因此，即使在他们处理任何 3D 之前，他们在性能上也处于领先地位，并且所做的只是在画布上喷涂像素；这往往需要一些精英的微观优化魔法。
当您使用 ZB 雕刻 2000 万个多边形模型时，需要注意的一件事是它甚至不使用 GPU 光栅化。所有的光栅化都是在 CPU 中完成的。因此，它无法从具有大量 VRAM 支持最新 GLSL/HLSL 版本的强大显卡中受益；它所需要的只是可以将彩色像素绘制到屏幕上的东西。这可能是它与 MudBox 相比使用如此少内存的原因之一，因为它不必将内存使用量增加三倍，比如 VBO（这往往会使系统内存使用量增加一倍，同时还需要数据存储在 GPU 上）。
至于你如何开始使用这些东西，IMO 一个让你的脚变湿的好方法是编写你自己的光线追踪器。我不认为 ZBrush 使用，比如说，扫描线光栅化，当你拥有更多的多边形时，它的成本往往会成比例地上升，因为它们会减少在旋转模型时渲染的像素数量。这表明他们用于光栅化的任何技术在性能方面更依赖于渲染的像素数，而不是渲染的图元（顶点/三角形/线/体素）的数量。光线追踪符合这些特征。另外恕我直言，光线追踪器实际上比扫描线光栅化器更容易编写，因为您不必费心处理棘手的情况，并且可以免费消除透支。
一旦你得到一个软件，它的操作成本与渲染像素的数量比几何体的数量成正比，那么你可以向它扔一大堆多边形，就像他们演示 2000 万时所做的那样大约 17 年前，在 Siggraph 以柔滑的帧速率雕刻多边形。
然而，很难让光线追踪器以交互方式更新以响应网格数据，因为网格数据不仅以交互方式雕刻，而且有时还以交互方式更改其拓扑。因此，很可能他们使用的数据结构不同于光线追踪中流行的标准 BVH 或 KD-Tree，而是一种非常适合动态网格的数据结构，这些网格不仅会变形，而且会改变其拓扑结构。也许他们可以非常快速地动态地对网格进行体素化和反体素化（或“像素化”和“再像素化”），并将光线直接投射到体素化表示中。考虑到他们的技术最初是如何围绕这些具有深度的 2.5D“像素”旋转的，这将开始变得有意义。
无论如何，我建议从光线追踪开始，即使它只是让你的脚弄湿并且让你离 ZB 的性能还差得很远（这仍然是如何将 3D 几何和照明转换为有吸引力的 2D 图像的一个很好的开始） . 您可以在网络上找到仅用一百行代码编写的最小光线跟踪器示例。构建光线追踪器的大部分工作通常是性能和处理丰富多样的着色器/材质。你不一定需要为后者而烦恼，ZBrush 也没有那么多（他们使用这些廉价的 matcaps 进行建模）。然后，您可能必须创新某种非常适合网格更改的数据结构，才能开始与 ZB 相提并论并对其进行微调。
我同样受到 ZB 的启发，但没有直接跟随他们的脚步，而是使用 GPU 光栅化器和 OpenGL。我发现很难像 ZB 那样探索在 CPU 上做所有这些事情的原因之一是因为你失去了游戏引擎和 NVidia 和 AMD 已经在实时照明模型中提出的如此多的工业研究和革命性技术的好处等等，所有这些都受益于 GPU 端处理。有 99% 的 3D 行业，然后有 ZBrush 在自己的小角落里做其他人没有做的事情，你需要大量的空闲时间，也许还有很多球来放弃行业的其余部分并尝试跟进ZB的脚步。
我最接近 ZB 性能的是 90 年代后期在 Athlon T-Bird 1.2GHz 和 256MB RAM 上以超过 30 FPS 的速度雕刻 200 万个多边形网格，这是在经过 6 周的密集编程和重新审视绘图之后在一个非常简单的演示中一遍又一遍地董事会，那是一个非常罕见的时间，我的公司给了我如此多的研发时间来探索 ZB 正在做什么。尽管如此，ZB 仍然以相同的帧速率处理 5 倍的几何图形，即使在那个时候，在相同的硬件上使用一半的内存。我什至无法接近，尽管我最终对 Pixologic 的程序员产生了新的尊重和钦佩。我还不得不坚持让我的公司做这项研究。那里的一些人认为 ZBrush 永远不会成为任何值得注意的东西，而只会是一个可爱的艺术应用程序。
当时很多人认为 ZB 处理如此多多边形的能力是不切实际的，你可以只绘制凹凸/法线/位移贴图，然后将所需的任何细节添加到纹理中。但这忽略了事情的工作流程方面。当您可以直接处理大量几何图形时，您就可以统一应用相同的工具和工作流程来选择顶点、多边形、边、刷过物体等。它成为创建如此详细和复杂模型的最直接方式，之后您可以将细节烘焙成凹凸/法线/位移贴图，以供其他引擎使用，这些引擎会吐出 2000 万个多边形。现在我认为没有人仍然质疑ZB的实用性。
[...] 但它并没有真正解决这些问题，或者我还没有达到那个点。
需要注意的是，没有人发表过任何关于如何实现与 ZB 相媲美的性能的文章。否则，在雕刻、dynamesh、zspheres 等方面，会有许多应用程序与其性能和功能相媲美，而且它也不会如此特别。你肯定需要你的研发份额来想出任何接近它的东西，但我认为光线追踪是一个好的开始。之后，除了大量微调之外，您可能还需要为算法和数据结构提出一些非常有趣的想法。
我可以相当自信地说：
如果你真的有兴趣探索这个，我很想看看你能想出什么。也许我们可以交换笔记。我职业生涯的大部分时间都只是对弄清楚 ZB 正在做什么感兴趣，或者至少想出一些我自己可以与它正在做的事情相媲美的东西。对于我多年来处理的几乎所有其他事情，从光线跟踪到粒子模拟，再到流体动力学和视频处理等等，我至少能够提出与竞争对手的性能相匹敌或超越的演示，但是不是 ZBrush。ZBrush 仍然是我身边难以捉摸的荆棘，我无法弄清楚他们是如何做到如此高效的。
如果你真的想在开始走路之前爬行（我认为光线追踪是一个不错的开始，但如果你想从更基础的开始）那么也许自然的演变是首先专注于图像处理：过滤图像，用画笔等绘制它们，并支持基本矢量图形，如微型 Photoshop/Illustrator。然后继续光栅化一些基本的 3D 图元，比如可能只是使用 Wu 线光栅化和一些基本投影功能渲染的模型的线框。然后在没有任何照明或纹理的情况下对填充三角形进行光栅化，此时我认为您将更接近 ZBrush，专注于光线跟踪而不是具有深度缓冲区的扫描线。然而，无论如何，做一点后者可能是一个有用的练习。然后开始渲染点亮的三角形，可能从直接照明和单个光源开始，仅根据法线相对于光源的角度计算亮度。然后使用 baycentric 坐标处理带纹理的三角形，以确定要渲染的纹素。然后致力于间接照明和多个光源。这应该是大量的功课，让您对光栅化的基本原理有一个相当全面的了解。
现在一旦你开始使用光线追踪，我实际上会推荐一种效率最低的数据结构，通常是：八叉树，而不是 BVH 或 KD 树，主要是因为我相信八叉树可能更接近于允许 ZB 允许的。在这种情况下，您的瓶颈与使用复杂的漫反射材料和间接照明以及用于抗锯齿的子像素样本渲染最漂亮的图像无关。它涉及使用简单的照明和简单的着色器处理大量几何图形，每个像素一个样本，这些样本在运行中不断变化，包括拓扑。在这种情况下，八叉树似乎比 KD 树或 BVH 更适合作为起点。
如今忽略基本原理的问题之一是，许多年轻的开发人员已经失去了屏幕上从三角形到像素的联系。因此，如果您不想将这种光栅化和投影视为理所当然，那么您最初的目标是将 3D 数据投影到 2D 坐标空间中并对其进行光栅化。