PDF 3D 图像无法正常移动
我正在尝试将 3D 模型放入 PDF 文件中。当我在 Acrobat 中加载 PDF 文件时，它就会出现。
但是，当我使用旋转、自旋或手动控制时，3D 图像保持相同方向，而相机视点似乎指向不同方向，因此即使轻微旋转也会使图像离开屏幕，除非我缩小很多。这与其工作原理相反：3D 图像旋转时相机应保持静止。
我是第三个参与此代码的人，这表明了这一点。该软件是 libharu、Sourceforge 的 U3D 代码（本质上是英特尔的废弃代码）以及实习生编写的一些东西的组合。
那么，有人见过这样的事情并找出为什么会发生吗？是否有任何参考可以以编程方式构建包含 3D 图像的 PDF 文件，该文件比 PDF 标准更能解释事物？关于如何解决这个问题还有其他建议吗？
I'm trying to put a 3D model into a PDF file. When I load the PDF file in Acrobat, it comes up.
However, when I use the rotate, spin, or hand control, the 3D image stays in the same orientation while the camera viewpoint seems to point in different directions, so even a slight rotate will send the image off the screen unless I zoom way out. This is the opposite of how it should work: the camera should stay still while the 3D image rotates.
I'm the third guy to be working on this code, and it shows. The software is a combination of libharu, the U3D code from Sourceforge (Intel's castoff code, essentially), and some stuff written by an intern.
So, has anybody seen anything like this and found out why it's happening? Is there any reference out there for programmatically building a PDF file with 3D images that is better at explaining things than the PDF standard? Any other suggestions on how to approach this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想通了。
在 PDF 规范的第 13.6.4 节中，有相机视点的定义。它包括几件事，其中一件事我一开始不太明白：二氧化碳价值。其作用是设置视点的旋转中心，即相机正前方的 CO 值。
在这种情况下，CO 中出现了负数。这使得旋转中心位于相机前面一些负单位，这意味着旋转中心位于相机后面。这意味着视点围绕距离图像一定距离的球体移动，因此无法绕过图像，但可以指向远离图像的方向。
对于任何以编程方式在 PDF 中构建 3D 图像的人来说，如果您有 CO 值，请确保它是正值。
I figured it out.
In the PDF spec, section 13.6.4, there is the definition of camera viewpoint. It includes several things, one of which I didn't quite understand at first: the CO value. What this does is sets the center of rotation of the point of view, which is the CO value directly in front of the camera.
What happened is that a negative number got into the CO in this case. That put the center of rotation some number of negative units in front of the camera, which meant that the center of rotation was behind the camera. That meant that the point of view traveled around a sphere some distance away from the image, and so couldn't get around the image but could point away from it.
For anybody programmatically building a 3D image in a PDF, if you have a CO value, make sure it's positive.