Вопрос

Мне было предложено решить проблему использования памяти приложения CAD, написанного на Visual C ++, которая возникает при попытке экспортировать чертеж в PDF3D.

Экспорт функций ведет себя хорошо для простых моделей или только частей сложной модели, но не для всей сложной модели.

Мы используем проект U3D Sourceforge для создания объекта U3D; После того, как мы вставляем его в PDF. Это задача, создавая часть, проблематичная.

Проект U3D Sourceforge - это библиотека, встроенная в C ++ для использования в C ++, которая также является мертвой с 2007 года, имеет плохую документацию, а коллекция ее образцов далеко не достаточно! В списке Todo проекта также указывается, что у него проблемы с памятью!

Поэтому меня попросили напасть на проблему двумя сторонами:

  1. Сделайте обслуживание кода U3D.

  2. Измените способ взаимодействия приложения с библиотекой U3D.

Они также сказали, что сторона 2. предпочтительна, как она находится под нашим контролем.

Пытаясь решить проблему, я сделал два вывода:

  1. Я твердо подозреваю, что Encodex метода U3D отвечает за неправильное управление памятью.

  2. Я попробовал много изменений мелочей для того, как Aplication взаимодействует с LIB (изменяющиеся параметры сжатия, флаги и т. Д.), И каждый раз результатом был чрезмерный распределение памяти.

Итак, вопрос: стоит ли продолжать использовать эту библиотеку? Кодекс этого не очень рад читать ... или, может быть, было бы неплохо взглянуть на другие либералы для той же цели? Я не изучал их, но я серьезно думаю о переходе на VCGlib или Libharu ... пожалуйста, предложите что -нибудь еще, если вы знаете, что это хорошо.

Другими альтернативами являются: используйте экспортер Visual Technologies PDF3D, который имеет неподходящую стоимость, или разработать мою собственную реализацию экспортера U3D, который может иметь недостатки очень ограниченного набора функциональности U3D, а также это могло Приготовьтесь к ожидаемому крайнему сроку. Так что возьмите эти варианты как запрещенные.

Мне действительно нужна помощь, чтобы решить, что лучше.

Заранее спасибо, Серджио

Это было полезно?

Решение 2

После некоторого отчаяния и плохих ночей, пытаясь обнаружить утечки памяти или некоторые другие проблемы с памятью, мы пришли к выводу за наиболее практическое решение:

Извлеките только кодовую часть, необходимую для загрузки файла, и экспортировать его в виде U3D в небольшую программу и сделать его основным приложением CAD. Несмотря на то, что это не самое элегантное решение, оно действительно работает хорошо - ни один из процессов не достигает использования памяти даже близко к барьеру 2 ГБ.

Я хотел бы, чтобы я был уполномочен решать вещи таким образом раньше. Я предложил некоторые другие вещи, такие как:

  • мигрируя на 64 бита

  • Используйте опцию, которую поддерживают современные версии Windows для расширения предела памяти каждого процесса до более 2 ГБ

Ни одно из этих двух решений не было приемлемым, потому что потребовалось бы, чтобы некоторые клиенты переустановили уже трудное оборудование или программное обеспечение.

Другие советы

Некоторые комментарии: VCGlib - не связанный, Meshlab полагается на VCGlib для основных функций, но для инструмента командной строки U3D используется командная строка для преобразования из текстового формата в U3D, и этот инструмент от SF U3D Lib. Libharu - может встраивать 3D -модели в свой выход PDF, а не создавать модели (файлы U3D или PRC).

Другой вариант - превзойти другой формат Adobe 3D PDF, prc. Acrobat SDK имеет описание формата в форме псевдокода. На основании этого вывода КНР был реализован в асимптоте инструмента. Найдите его в Sourceforge и задайте вопрос на форуме Asymptote, если вы заинтересованы.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top