从Visual C ++导出U3D/PDF3D [英] Exporting U3D/PDF3D from Visual C++

问题描述

已要求我解决在试图将图形导出到PDF3D时出现的用Visual C ++编写的CAD应用程序的内存使用问题.

I have been requested to solve a problem of memory usage of a CAD application written on Visual C++ that occurs when trying to export the drawing to PDF3D.

导出功能在简单模型或仅复杂模型的一部分中表现良好，但不适用于整个复杂模型.

Exporting feature behaves well for simple models or only parts of a complex model, but not for an whole complex model.

我们正在使用U3D sourceforge项目创建U3D对象；将其插入PDF之后.问题是对象创建部分.

We are using the U3D sourceforge project for creating the U3D object; after we insert it into the PDF. It is the object creating part that is problematic.

U3D sourceforge项目是一个用C ++构建的库，也可以在C ++中使用，该库自2007年以来就已失效，文档不多，而且其样本收集还远远不够！在该项目的TODO列表中还指出它存在内存问题！

The U3D sourceforge project is a library built in C++ for use in C++ too that is dead since 2007, has a poor documentation and its samples' collection is far from enough! In the TODO list of the project is also stated that it has memory issues!

所以有人要求我从两个方面来解决这个问题:

So I have been asked to attack the problem by two sides:

1. 维护U3D代码.

1. Do maintenance of the U3D code.

更改应用程序与U3D库进行交互的方式.

Change the way the application interacts with the U3D library.

他们还说，第二方面更可取，因为它在我们的控制之下.

They also said the side 2. preferrable, as it is under our control.

当试图解决问题时，我得到两个结论:

When trying to solve the problem, I got two conclusions:

1. 我强烈怀疑U3D方法EncodeX会导致内存滥用.

1. I am strongly suspecting that the U3D method EncodeX is responsible for memory misusage.

我尝试了许多小事情的改变，以便使应用程序与lib交互(更改压缩参数，标志等)，并且每次结果都是内存过度分配.

I tried a lot of changes of small things for the way the apllication interacts with the lib (changing compression parameters, flags, etc) and everytime the result was memory over-allocation.

所以问题是:继续使用这个库值得吗?阅读它的代码不是一件令人愉快的事情……或者出于相同的目的考虑其他库可能是个好主意吗? 我没有进行探索，但是我正在认真考虑切换到VCGlib或libharu ...如果您知道这很好，请提出其他建议.

So the question is: Is it worth to continue using this library? The code of it is not a joy to read... Or maybe it could be a good idea to look at other libs for the same purpose? I didn't explore them, but I am seriously thinking about switching to VCGlib or libharu... please suggest something else if you know that is good.

其他选择是:使用成本不可接受的Visual Technologies PDF3D导出器，或开发我自己的U3D导出器实现，但缺点是U3D功能有限，而且它无法为预期的截止日期做好准备. 因此，请禁止使用这些选项.

The other alternatives would be: use the Visual Technologies PDF3D exporter, which has an inacceptable cost, or to develop my own implementation of an U3D exporter,which would have the disadvanges of being a very limited set of the U3D funcionality and also it could'nt get ready for the expected deadline. So take these options as forbidden.

我真的需要帮助来决定最好的方法.

I really need help to decide what's best.

预先感谢， 塞焦(Sérgio)

Thanks in advance, Sérgio

推荐答案

经过一阵绝望和糟糕的夜晚，试图发现内存泄漏或其他内存问题，我们得出了最实用的解决方案:

After some desperation and bad-sleeping nights, trying to discovery memory leaks or some other memory troubles, we concluded for the most practical solution:

仅提取加载文件所需的代码部分，并将其作为U3D导出到一个小程序中，并使主CAD应用程序对其进行调用.即使这不是最优雅的解决方案，它也确实可以很好地工作-甚至在接近2 GB障碍的情况下，所有进程都无法达到内存使用量.

Extract only the code part needed to load a file and export it as U3D to a small program and make the main CAD application call it. Even though it is not the most elegant solution, it really works well - none of the processes reaches memory usage even close to the 2 GB barrier.

我希望我已经被授权以较早的方式解决问题.我提出了其他一些建议，例如:

I wish I had been authorized to solve things this way earlier. I proposed some other things like:

• 迁移到64位

• migrating to 64 bits

使用现代Windows版本支持的选项将每个进程的内存限制扩展到2 GB以上

use an option that modern Windows versions support for extending the memory limit of each process to more than 2 GB

这两个解决方案中的任何一个都不可接受，因为这将迫使一些客户重新安装已经在运行的硬件或软件.

None of these two solutions were acceptable, because it would be needed to force some customers to reinstall already-running hardware or software.

这篇关于从Visual C ++导出U3D/PDF3D的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！