[Glam Troll]

При интенсивном использовании (десятки тысяч вызовов подряд) метода AcDb3dSolid::imprintEntity обнаружил огромные утечки памяти. Причём, даже если тела не соприкасаются и в них не происходит никаких изменений. Например, если нарисовать 125 не контактирующих друг с другом кубиков и вызвать импринт для каждой пары из них, то занимаемая память увеличится более чем на 200 мегабайт, хотя абсолютно никакой полезной работы не совершилось. Вызовы acdbAcisDeleteModelerBulletins не только не помогают, но в ObjArx2015 этой функции вовсе нет. (разумеется, imprintEntity вызывается не просто так, а по очень веской причине и в рабочем документе содержится несколько тысяч тел, различным образом контактирующих друг с другом. В реальном документе утечки достигают 10-20 гигабайт и я страдаю).
Может кто-то сталкивался с такой проблемой и знает способы её решения?

P.S. В ADN уже вопрос написал, но мало ли когда они ответят, поэтому надежда на соо вообще и Александра Ривилиса в частности

Вот код примера, если хочется поэкспериментировать с косяком. Если делать imprintEntity не на оригинале, а на временном теле в памяти, то на размере утечек это никак не сказывается.

Код:

[Выделить все]

 
#include "StdAfx.h"
#include "resource.h"
#include <dbacis.h>
#include <vector>

#define OBJECT_ARX_VERSION 20

//-----------------------------------------------------------------------------
#define szRDS _RXST("TEST")

void ImprintAll();

//-----------------------------------------------------------------------------
//----- ObjectARX EntryPoint
class CMiniImpApp : public AcRxArxApp {

public:
	CMiniImpApp () : AcRxArxApp () {}

	virtual AcRx::AppRetCode On_kInitAppMsg (void *pkt) {
		// TODO: Load dependencies here

		// You *must* call On_kInitAppMsg here
		AcRx::AppRetCode retCode =AcRxArxApp::On_kInitAppMsg (pkt) ;

		// TODO: Add your initialization code here

		return (retCode) ;
	}

	virtual AcRx::AppRetCode On_kUnloadAppMsg (void *pkt) {
		// TODO: Add your code here

		// You *must* call On_kUnloadAppMsg here
		AcRx::AppRetCode retCode =AcRxArxApp::On_kUnloadAppMsg (pkt) ;

		// TODO: Unload dependencies here

		return (retCode) ;
	}

	virtual void RegisterServerComponents () {
	}


	static void CMiniImpApp_ImprintTest()
	{	ImprintAll();	}

} ;

//-----------------------------------------------------------------------------
IMPLEMENT_ARX_ENTRYPOINT(CMiniImpApp)

ACED_ARXCOMMAND_ENTRY_AUTO( CMiniImpApp, CMiniImpApp, _ImprintTest, ImprintTest, ACRX_CMD_NOINTERNALLOCK | ACRX_CMD_TRANSPARENT | ACRX_CMD_NOHISTORY, NULL );


void ImprintAll()
{
	ads_name ent0, ent1; 

	if( acdbEntNext(NULL, ent0) != RTNORM )
	{ 
		acdbFail(L"Drawing is empty\n"); 
		return; 
	}

	std::vector<AcDbObjectId> allSolids;

	Acad::ErrorStatus err( Acad::eOk );
	do
	{ 
		AcDbObjectId objId;
		err = acdbGetObjectId(objId, ent0);

		AcDbObjectPointer<AcDb3dSolid> object( objId, AcDb::kForRead, FALSE );
		if( object.openStatus() != Acad::eOk )
			continue;

	//	AcDb3dSolid * solid = new AcDb3dSolid;
	//	solid->copyFrom( object );

		allSolids.push_back( objId );

		ads_name_set(ent0, ent1);

	}
	while( acdbEntNext(ent1, ent0) == RTNORM ); 


	for( int i = 0; i < allSolids.size(); ++i )
	{
		AcDbObjectPointer<AcDb3dSolid> solid1( allSolids[i], AcDb::kForWrite, FALSE );

		for( int j = i; j < allSolids.size(); ++j )
		{
			if( i == j )
				continue;

			AcDbObjectPointer<AcDb3dSolid> solid2( allSolids[j], AcDb::kForWrite, FALSE );

			if( Acad::eOk == solid1->imprintEntity( solid2 ) )
			{
				solid2->imprintEntity( solid1 );
			}
		}
	}
}

[Кулик Алексей aka kpblc]

Glam Troll, ты в заголовке темы укажи - язык, под какую версию пишешь и проч.

[Glam Troll]

ObjectArx, C++
Не могу заголовок исправить...

[Кулик Алексей aka kpblc]

Можешь: Как переименовать тему?

[Do$]

Если на C++, да к тому же член ADN, то прямая дорога сюда: http://adn-cis.org/forum/index.php?board=3.0

[Александр Ривилис]

Сообщение от Glam Troll P.S. В ADN уже вопрос написал, но мало ли когда они ответят, поэтому надежда на соо вообще и Александра Ривилиса в частности

Если это баг, то тут я не помогу ничем. Если ты этого не делаешь, то сначала проверяй на пересечение габаритных контейнеров. Если они не пересекаются, то незачем и пытаться пересекать объекты.
P.S.: А с acdbEntNext ты меня пробил на ностальгию. Я эту функцию не использовал лет пятнадцать.

[Glam Troll]

Сообщение от Александр Ривилис сначала проверяй на пересечение габаритных контейнеров

Разумеется габаритные контейнеры проверяю. Тут без проверки, чтобы ошибку явно показать. На каждый импринт "утекает" буквально килобайт памяти, но из-за сложности конструкции накапливаются десятки гигабайт за считанные минуты...
С габаритными контейнерами у автокада тоже баг есть (или фича ). Для некоторых импортированных моделей габаритный контейнер возвращается с учётом координаты 0:0:0. Причём не только методом getextend, но и прям в окне документа если вызвать zoomAll. Причём, только при виде сверху. Стоит повернуть чертёж и нулевая точка не учитывается при вычислении габаритов при зуммировании, но всё-равно учитывается в getextend. Надо про это тоже в АДН написать, хорошо, что напомнили.

Сообщение от Александр Ривилис acdbEntNext ты меня пробил на ностальгию. Я эту функцию не использовал лет пятнадцать.

Буду очень благодарен за что-то менее лисповое. Этот код скопипастил у коллег и сделал вид, что так и надо.

[Александр Ривилис]

Сообщение от Glam Troll Буду очень благодарен за что-то менее лисповое. Этот код скопипастил у коллег и сделал вид, что так и надо. Glam Troll вне форума вставить имя Обратить внимание модератора на это сообщение

Тебя интересуют 3DSolid'ы только в Пространстве Модели или все, которые есть в чертеже, в том числе и лежащие в блоках?

[Glam Troll]

Интересуют вообще все entity, которые есть в БД документа. Причём, типы некоторых из них мне даже неизвестны (сторонняя библиотека по AcDbObjectId возвращает его солидное представление). В простейшем случае, нужны все солиды и сюрфэйсы с видимых слоёв, включая те, которые в блоках или вставлены по xref.

Кстати! Нынешний код вполне рабочий и его быстродействие меня вполне устраивает. А вот с блоками есть непонятки. К телам в блоках ведь могут применяться различные трансформации и, вытаскивая тело из блока, у меня не всегда эти трансформации удаётся применить. Проблема настолько редкая, что я даже про неё не стал спрашивать в виде отдельной темы. Может сталкивались с подобным?

[Александр Ривилис]

Сообщение от Glam Troll А вот с блоками есть непонятки. К телам в блоках ведь могут применяться различные трансформации и, вытаскивая тело из блока, у меня не всегда эти трансформации удаётся применить. Проблема настолько редкая, что я даже про неё не стал спрашивать в виде отдельной темы.

Ну AutoCAD не идеален...

Сообщение от Glam Troll Интересуют вообще все entity, которые есть в БД документа. Причём, типы некоторых из них мне даже неизвестны (сторонняя библиотека по AcDbObjectId возвращает его солидное представление). В простейшем случае, нужны все солиды и сюрфэйсы с видимых слоёв, включая те, которые в блоках или вставлены по xref.

Посмотри. Может из этого кода что-то почерпнёшь:

Код:

[Выделить все]

 static void IterateDatabase () {
   Acad::ErrorStatus es;
   AcDbDatabase *pDb = acdbCurDwg();
   // Метка первого объекта в чертеже
   AcDbHandle firstHandle = pDb->blockTableId().handle();
   // Метка следующего объекта после последнего
   AcDbHandle lastHandle = pDb->handseed();
   int nObjects = pDb->approxNumObjects();
   ACHAR buf1[256],buf2[256];
   firstHandle.getIntoAsciiBuffer(buf1);
   lastHandle.getIntoAsciiBuffer(buf2);
   __int64 iFirst = 0; swscanf(buf1,_T("%I64x"),&iFirst);
   __int64 iLast = 0; swscanf(buf2,_T("%I64x"),&iLast);
   __int64 nTotal = 0;
   acutPrintf(_T("\nПервая метка объекта: <%s>, последняя метка объекта: <%s>"),buf1,buf2);

   for (__int64 i = iFirst; i < iLast && nObjects > 0; i++) {
     AcDbHandle h(i);
     AcDbObjectId id = AcDbObjectId::kNull;
     if ((es = pDb->getAcDbObjectId(id,false,h)) == Acad::eOk) {
       if (id.objectClass()->isDerivedFrom(AcDb3dSolid::desc()) ||
         id.objectClass()->isDerivedFrom(AcDbSurface::desc())) {
           // Нашли 3DSolid или Surface
           // AcDbEntityPointer pObj(id,AcDb::kForRead);
           // if (pObj.openStatus() == Acad::eOk) {
           //   // Печатаем информацию о нём
           //   pObj->list();
           // }
           nTotal++;
       }
     }
   }
   wsprintf(buf1,_T("\nВсего найдено твердых тел и поверхностей %I64d."),nTotal); 
   acutPrintf(_T("%s"),buf1);
}

[Glam Troll]

Сообщение от Александр Ривилис Может из этого кода что-то почерпнёшь

Благодарю!
А непосредственно по AcDbHandle итерировать не пробовали? Для них ведь и оператор < и != определён. Судя по "AcDbHandle h(i);" это будет одно и то же.

[Александр Ривилис]

Сообщение от Glam Troll А непосредственно по AcDbHandle итерировать не пробовали? Для них ведь и оператор < и != определён. Судя по "AcDbHandle h(i);" это будет одно и то же.

Перечитай,только внимательно мой код и обрати внимание на pDb->getAcDbObjectId(id,false,h)) - без него ты можешь получить несуществующий в даном чертеже AcDbHandle

[Glam Troll]

Сообщение от Александр Ривилис pDb->getAcDbObjectId(id,false,h))

Действительно, не обратил внимания. С учётом огромного количества объектов в документе (там ещё и текст и 2Д построения и куча прочего мусора) и их создания/удаления код выглядит как-то опасно. В принципе, инвалидный объект всё-равно не откроется. А вот что может потребоваться тысячи идентификаторов уже "удалённых" объектов отсеивать... Думаю, автокад делает примерно то же самое в методе acdbEntNext, пропуская идентификаторы удалённых объектов.

[Александр Ривилис]

Можешь из спортивного интереса засечь скорость работы обоих методов. Достоинство моего метода в том, что можно работать и с чертежами, которые не загружены в редактор AutoCAD (т.е. открыты через AcDbDatabase::readDwgFile) или не являются активными в редакторе AutoCAD. Функция acedEntNext работает только с активным dwg-файлом.

[Glam Troll]

Сообщение от Александр Ривилис можно работать и с чертежами, которые не загружены в редактор AutoCAD

А вот это круто! У меня есть пакетная работа с файлами, этот способ может пригодиться. У меня сейчас через именованную таблицу данные находятся, может что-нибудь оптимизировать получится.

[Александр Ривилис]

В дальнейшем, пожалуйста, посмотри в мою подпись и можешь задавать вопросы там. Во всяком случае специалистов по ObjectARX там больше и легче программистским коллективом "давить на Autodesk".

[Дима_]

Сообщение от Glam Troll При интенсивном использовании (десятки тысяч вызовов подряд) метода AcDb3dSolid::imprintEntity

А в чем причина такого частого вызова (видимо идет сравнение "каждый к каждому") - какова конечная цель? Быть может возможно будет придумать оптимизацию.

[Glam Troll]

Сообщение от Дима_ А в чем причина такого частого вызова

В реальной программе imprint делается только для тех тел, чьи габаритные контейнеры пересекаются (но это всё-равно тысячи вызовов). По этим телам строится КЭ сетка и сеточному генератору необходимо, чтобы в зоне контакта сетки совпадали. Обеспечить это можно только проецированием тел друг на друга. Если с плоскими гранями ещё можно что-то придумать, дробить самостоятельно сетку, после получения её из BREP'a, то вот с не плоскими поверхностями выбора никакого нет. BREP аппроксимирует кривые так, как ему приспичит и состыковать тела просто невозможно без imprint'a.

[Дима_]

Сообщение от Glam Troll По этим телам строится КЭ сетка и сеточному генератору необходимо, чтобы в зоне контакта сетки совпадали.

Вот эту часть можно поподробней -оперируя только автокадными понятиями.

[Glam Troll]

Сообщение от Дима_ оперируя только автокадными понятиями

Автокадными понятиями это не объяснить, потому что к автокаду отношения в принципе не имеет.) Если попытаться... То при использовании BREP, контактирующие грани должны совпадать.

[Александр Ривилис]

Сообщение от Glam Troll В реальной программе imprint делается только для тех тел, чьи габаритные контейнеры пересекаются (но это всё-равно тысячи вызовов).

Ну можно еще сократить количество вызовов imprintEntity если смотреть пересечение не габаритных контейнеров, а наличие взаимного пересечения AcBrFace пары тел.

[Glam Troll]

Сообщение от Александр Ривилис пересечения AcBrFace пары тел.

Как я понимаю, придётся проверять пересечение каждой грани одного тела с каждой гранью второго. Утечку с импринтом я вычислил на чертеже из нескольких сотен деталей, по 2-3 тысячи граней в каждой. BREP там вообще страдает очень сильно, от таких моделей.

----- добавлено через ~2 мин. -----

Сообщение от Александр Ривилис Александр Ривилис

Offtop: Зарегистрировался на вашем сайте (по ссылке в подписи). Антибот у вас там впечатляющий... Нигде столь усиленной проверки не встречал.

[Дима_]

Сообщение от Glam Troll То при использовании BREP, контактирующие грани должны совпадать.

Важны детали - что есть - должны совпадать?? Найти грани которые точно равны, пересекаются, одна грань полностью лежит внутри другой, частично и пр. Нарисуйте пример и укажите что нужно - если конечно видите в этом смысл. По моей практике, в большинстве случаев, все подобные "геометрические" задачи имеют "резервы" к упрощению (к усложнению алгоритма - но росту производительности).

[Glam Troll]

Сообщение от Дима_ что есть - должны совпадать?

После того, как грани триангулируются, они представляются не параметрически, а при помощи треугольников. И необходимо, чтобы контактирующие грани были одинаково триангулированы (хотя бы по периметру).
Вот на картинке два параллелепипедовых кубика размером 100*100*20. И у них есть контактирующая поверхность площадью 50*50. Без импринта каждый кубик триангулируется независимо и совместить точки на контактирующей поверхности будет невозможно. А, если делать импринт, то на обоих телах появятся новые грани, которые в точности друг с другом совпадают и BREP обеспечивает их совместную триангуляцию.

контактирующая поверхность


Она же, но с сеткой. Специально сетка крупная, чтобы хоть что-то увидеть


А когда доходит до поверхностей с трёхмерной кривизной, то дела обстоят ещё хуже. Речь уже не о том, что узлы не совпадают, там уже один цилиндр может стать пятиугольником, а второй - десятиугольником. А, за счёт импринта, в месте стыка они будут аппроксимированы синхронно, с увеличением или уменьшением числа граней на одном из тел (смотря какое раньше будет обработано).

Я даже рассматривал возможность использовать внешний триангулятор (благо выгрузка в SAT присутствует), только вот от импринта всё-равно избавиться никак не получается. Если из моего опуса что-то стало понятно или появилась светлая мысль, то буду очень благодарен.

Ну и причина необходимости совпадения сеток - таково требование генератора КЭ сетки. Иначе тетраэдры не будут совпадать и генерация сетки падает.

[Дима_]

коротко - т.к. с телефона, вариант оптимизации каждого к каждому - копию каждого тела немного отмасштабировать относительно центра, чтоб касающиесия тела начали пересекаться, а затем последовательно объединять их все в одно тело, анализируя объем до и после - если ‘прирост‘ оказался меньше объема тела, значит оно заползает на какое либо из уже добавленных - то есть с ними надо будет проверить импринт, если прибавка к объему = объему тела -то его можно не проверять.

[Glam Troll]

Сообщение от Дима_ копию каждого тела немного отмасштабировать относительно центра,

Вот это кстати неплохая идея. Только не объединять в одно тело, а найти объём на пересечении тел (выполняется мгновенно даже на сложных телах). Вычисление объёма слишком трудозатратная операция. На сложных телах (особенно построенных лофтингом по сплайнам) может занимать часы или вообще вешать Автокад.
В принципе идея понятна. Можно будет отфильтровать тела, чьи габаритные контейнеры пересекаются, но контакта тел нет. Только от утечки памяти на импринтах, которые всё же есть, это не избавит.(

[Дима_]

Сообщение от Glam Troll Вычисление объёма слишком трудозатратная операция. На сложных телах (особенно построенных лофтингом по сплайнам) может занимать часы или вообще вешать Автокад.

Я с таким моделями еще не сталкивался, но в общем верю. По моей практике анализ через однократное сложение тел идет быстрее чем сверка каждого к каждому.

[Glam Troll]

Сообщение от Дима_ однократное сложение тел

Только вот эта проверка лишь сообщит о факте контакта, а вот с каким из уже сбуленных тел этот контакт происходит - неизвестно. Т.е. опять придётся проверять каждый с каждым. Но, хотя бы, можно отсечь заведомо не контактирующие тела, у которых габаритные контейнеры пересекаются.
В ADN утечки признали вроде, может хоть в 2016 каде поправят и будет мне счастье.

[Дима_]

Не совсем каждый к каждому - проверять только те которые "просигнализировали", к тем, которые уже проверены до него. До кучи - если есть ограничения по возможным вариантам взаиморасположения (они как правило есть - надо только посмотреть внимательно), вполне возможно что достаточно будет проделать ту-же процедуру сложения тел, но в обратном порядке.