什么是稀疏体素八叉树？
我读了很多关于稀疏体素八叉树在未来图形引擎中的潜在用途的文章。
但是我一直无法找到有关它们的技术信息。
我理解体素是什么，但是我不知道稀疏体素八叉树是什么，或者它们如何比现在使用的多边形技术更有效。
有人可以解释或指出我对此的解释吗？
I have reading a lot about the potential use of sparse voxel octrees in future graphics engines.
However I have been unable to find technical information on them.
I understand what a voxel is, however I dont know what sparse voxel octrees are or how are they any more efficient than the polygonal techniques in use now.
Could somebody explain or point me to an explanation for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
以下是关于此主题的 id 软件的片段。
另外这里有一篇关于此的论文。
在此很棒的博客条目。
Here's a snippet about id Software on this subject.
Also here's a paper on this.
Found more information in this great blog entry.
八叉树有 8 个邻居，因为如果你想象一个正方形，它被切成 4 个相等的四分之一，
那么它将是一个“四”（四）树。
但在 3 维中，你有自己，一个立方体，而不是一个正方形，所以水平、垂直和沿 Z 轴切割它，你会发现 8 个块，而不是 4 个，就像
希望那样……
是什么让SVO 的独特之处在于它存储体素信息，体素信息是空间中的一个点，具有颜色、法线等属性。SVO
背后的想法是忽略三角形和纹理的需要，将它们放在一起形成一个单个 SVO，其中包含体素化三角形外壳（模型）及其表面纹理全部在一个对象中。
这里需要八叉树的原因是，否则统一的网格结构将需要大量内存来供现有显卡处理。
因此，使用 SVO 可以实现某种 Mip-Mapped 3D 纹理。MipMapping
基本上是相同的图像，但在不同比例下，具有更多细节的图像，以及具有最少细节的最新图像（但从远处看起来非常相似），
靠近的对象可以从 SVO 流式传输更多细节，而较远的对象流式传输细节较少..也就是说，如果您使用光线投射。光线距离相机越远，我们对巨型纹理/SVO 的挖掘就越少。
但是，如果您像“Euclideon”那样跳出框框思考，其“无限-detail”，您只需使用平截头体切片和平面/aabb 相交，使用切片广告牌的投影 UV 来查找屏幕上的每个纹理像素颜色，而不是宽度 * 高度像素，射出光线，并使用 nvidia 的天真“光束优化” ”。
PS（有点题外话）：对于任何不明白欧几里得如何做他们的shi的人，我相信这是最实用的解决方案，并且我有理由支持它（他们不使用光线投射）
他们拥有的最大的谜团，不是渲染，而是存储它们的数据.. RLE 根本不会削减它.. 因为一些体积/体素数据可能更随机，并且不太“可靠”，而 RLE 没用，对我来说通常还需要压缩至少 5 个字节。 他们说他们通过压缩输出了大约一半的内容。所以他们使用了 2.5 字节，这与现在的三角形大致相同
an octree has 8 neighbors because if you imagine a square, that was cut into 4 equal quarters like so
then it would be a "quad"(four)-tree.
but in 3 dimensions, you have yourself, a cube, rather then a square, so cutting it horizontally, vertically, and along the Z axis, you'll find 8 chunks rather then 4 like so
hope that makes since..
what makes the SVO unique, is that it stores Voxel information, which is a point in space, that has properties such as Color, Normal, etc..
the idea behind SVO is to ignore triangles, and the need of textures, by putting them together into a single SVO which contains the Voxelized Triangle Hull(the Model), and its surface textures all in one object.
The reason a Octree is needed here, is that otherwise a uniform grid structure would require far to much memory for existing graphics cards to handle..
so using the SVO allows for a sort of Mip-Mapped 3D Texture..
MipMapping basically is the same image, but at difference scales, one which has more detail, and the latest which has the least detail(but look fairly similar from a distance)
that way near objects can stream from the SVO with greater detail, while further objects stream with less detail.. that is if you're using Ray-Casting.. the further away the ray from the camera, the less we dig into our Mega-Texture/SVO
But, if you think outside the box like "Euclideon" with its "unlimited-detail", you would just use frustum slicing, and plane/aabb intersection, with projected UV of our sliced billboard for finding each texels color on the screen, opposed to Width*Height pixels, shooting out rays, with nvidia's naive "beam optimizations".
PS(sorta off topic): for anyone who doesn't understand how Euclideon does their shi, I believe thats the most practical solution, and I have reason to back it up(that they DO NOT use ray casting)
The biggest mystery they have, isn't rendering, but storing their data.. RLE simply doesn't cut it.. because some volume/voxel data may be more random, and less "solid" where RLE is usless, also compression of which for me typically requires at least 5 bytes into anything less. they say they output roughly half of what is put in) through their compression.. so they're using 2.5 bytes, which is about the same as a Triangle now-adays
名为高效稀疏体素八叉树 – 分析、扩展和实现的 NVIDIA 白皮书
此处描述得非常详细
A NVIDIA whitepaper named Efficient Sparse Voxel Octrees – Analysis, Extensions, and Implementation
describes it very detailed here
实际上，1.15 位让我怀疑它们只是以某种非常简单的方式按顺序存储内容。 也就是说，如果它们只存储体积数据而不存储颜色或纹理数据等数据。
这样想：1 个体素只需要 1 位：它存在还是不存在？ （存在或不存在，换句话说：P）。 它所在的八叉树节点由 8 个体素和一个用于存储该物体是否包含任何东西的位组成。 即每个体素一位加上每 8 位一位。1 + 1/8 = 1,125。 添加另一个具有 7 个兄弟节点的父节点，得到 1 + 1/8 + 1/8/8 = 1,140625。 可疑地接近他们提到的 1.15。 虽然我可能还很遥远，但它可能会给某人一些线索。
actually, the 1.15 bits make me suspect they just store things sequentially, in some brilliantly simple way. that is, if they're only storing the volume data and not things like colour or texture data as well.
think about it like this: 1 voxel only needs to be 1 bit: is it there or is it not there? (to be or not to be, in other words :P). the octree node it's in is made of 8 voxels and a bit to store whether the thing contains anything at all. that's one bit per voxel plus one per 8. 1 + 1/8 = 1,125. add another parent node with 7 siblings and you get 1 + 1/8 + 1/8/8 = 1,140625. suspiciously close to the 1.15 they mentioned. although i'm probably way off, it may give someone some clue.
您甚至可以简单地对所有点进行光栅化，现在您需要光线跟踪或光线投射，因为视频卡可以投射大量的点。 使用八叉树是因为它是一个立方体形状，不断地划分形成越来越小的立方体。 （体素）我现在有一个使用光栅技术的引擎，它看起来不错。 对于那些说你不能对体素进行动画处理的人，我认为他们确实没有对这个主题进行太多思考，当然这是可能的。 在我看来，制作世界很像“无限 3D 涂层”，因此查找 3D 涂层，关卡设计将与该程序的工作方式非常相似。 主要缺点包括流速度不够快，光线追踪或光栅不能达到 60 fps，绘制实际体素对象的计算量非常大，目前我可以在大约 12 秒内绘制 1024x1024x1024 球体，但所有这些问题可以补救，这是一个令人兴奋的未来。 目前我的最大世界尺寸是一兆一兆，但实际上我可能会将其放大 8 倍。 当然，另一个实际上相当严重的问题是，即使在压缩后存储一个8192x8192x8192字符也需要大约100兆，所以环境会比这个更多。 尽管如此，与我们今天在游戏中看到的相比，说你将拥有 8192x8192x8192 的字符是完全荒谬的......整个世界曾经是 8192x8192x8192 :)
你如何通过仅存储每个指针的位来做到这一点是指针是在运行时构造的在视频内存中......只要你想清楚这一点，你就可以拥有自己的引擎。 :)
You can even simply raster all the points, you needent raytrace or raycast these days, since video cards can project obscene amounts of points. You use an octree because its a cube shape, continually dividing making smaller and smaller cubes. (voxels) I have an engine on the way now using a rastered technique and its looking good. For those that say you cant animate voxels I think they really havent thought much about the topic, of course its possible. As I see it, making the world is alot like "infinite 3d-coat" so look up 3d coat and the level design will be very similar to the way this program works. Main draw backs involve streaming speed not being fast enough, the raytracing or rastering not quite making 60 fps, and plotting the actual voxel objects is very computationally expensive, at the moment I can plot a 1024x1024x1024 sphere in about 12 seconds, But all these problems could be remedied, its an exciting future. My maximum world size at the moment is a meg by a meg by a meg, but I actually might make it 8 times bigger than this. Of course the other problem which is actually quite serious is it takes about 100 meg to store a 8192x8192x8192 character even after compression, so an environment will be even more than this. Even though, saying your going to have characters 8192x8192x8192 is completely absurd compared to what we see in games today... an entire world used to be 8192x8192x8192 :)
How you do it by only storing bits per pointer is the pointers are constructed at runtime in video memory... get your mind around that and you could have your own engine. :)