Question

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.

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.

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. Do maintenance of the U3D code.

  2. 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. I am strongly suspecting that the U3D method EncodeX is responsible for memory misusage.

  2. 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.

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.

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.

Thanks in advance, Sérgio

Was it helpful?

Solution 2

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

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:

  • migrating to 64 bits

  • 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.

OTHER TIPS

Some comments: VCGlib - unrelated, MeshLab relies on VCGlib for core functions, but for U3D export command-line tool to convert from a text format to U3D is used, and that tool is from the sf U3D lib. libharu - can embed 3D models into its PDF output, not create the models (U3D or PRC files).

Another option is to outoput the other Adobe 3D PDF format, PRC. Acrobat SDK has format description in form of pseudocode. Based on that PRC output was implemented in Asymptote tool. Find it on sourceforge and ask question at Asymptote forum if you are interested.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top