CGAL начин за съхранение е извличане на геометрична информация за пълна клетка в триангулацията

Планирам да използвам класове CGAL Triangulation и Delaunay Triangulation като опорна геометрична структура за алгоритми за планиране на движението на робота. Основната трудност, която съм срещал досега, е при присвояването на допълнителни геометрични данни на пълни клетки в абстрактен комплекс. Например, за да намеря най-краткия път през пълна клетка, трябва да изчисля набор от нормални вектори към всички аспекти. За тази цел използвам скъпа псевдо обратна процедура. Тъй като тези изчисления трябва да се извършват няколко пъти във всяка пълна клетка, предпочитам да съхранявам тези данни, след като бъдат изчислени, и да ги извличам по време на последователни изчисления. Освен това бих искал да съхранявам данни за сблъсъци за всяка пълна клетка, вместо да ги изчислявам отново отново след прецизиране на дадена триангулация.

Разглеждайки някои отговори тук и опитвайки се да разбера структурата на CGAL, постигнах известно разбиране по този въпрос:

  1. Наистина е лоша идея да се пренапише геометрично ядро ​​само за това...
  2. Виждал съм примери за използване на базов клас на върха с информация, в която точките са увеличени с индекси тук. Въпреки че използването на Triangulation_cell_base_with_info изглежда като лесно заобиколно решение, аз го смятам за неелегантен хак, защото изисква от мен да внедря обвиващ клас за съхраняване на допълнителни данни и да предам този клас на алгоритъма за планиране.
  3. Мога да извлека клетъчен клас от Triangulation_ds_cell_base. Това изглежда като най-приемливия начин да правите нещата, но не мога да намеря добър пример за код, който да ми помогне да започна. Имам нужда не само от извличане на клас, но и от примерен код за това как да получа достъп до клетъчни данни в различни сценарии: чрез итератор, съседство на върхове и т.н.

И така, ето моите два въпроса:

  1. Какъв е CGAL начинът за съхраняване и извличане на допълнителни геометрични данни на клетка?
  2. Има ли добър пример за код, който прави точно това?

РЕДАКТИРАНЕ: Забравих да спомена, че трябва да използвам dD триангулация, въведена в CGAL 4.6


person Dmitry Yershov    schedule 18.06.2015    source източник
comment
В 2D/3D *_with_info е правилният начин и не разбирам защо ви изглежда хакерско. В dD изглежда, че можете да подадете като втори аргумент на триангулацията: Triangulation_data_structure<Dimension, Triangulation_vertex<K>, Triangulation_full_cell<K, MyInfo> >.   -  person Marc Glisse    schedule 19.06.2015
comment
Ако не искате да се задълбочавате твърде много в изпълнението на CGAL, можете лесно да създадете отстрани (хеш)карта, която свързва каквато и да е информация с Full_cell_handle.   -  person Marc Glisse    schedule 19.06.2015
comment
Гледайки изходния код на CGAL, имам чувството, че добавянето на MyInfo клас/структура като политика за съхранение за структурата на триангулационните данни ще спре кода. Политиката за съхранение приема политика по подразбиране или политика за огледало, всяка от които всъщност съдържа комбинаторни данни за пълна свързаност на клетките. Ако просто го замените с клас на трета страна, тази необходима структура от данни ще липсва... Също така смятам, че използването на хеш карти е дори по-сериозен хак от съхраняването на индекси в информацията за клетката. Основната причина е, че не искам да прилагам клас обвивка, за да запазя тези данни.   -  person Dmitry Yershov    schedule 19.06.2015
comment
Е, чети по-добре. Това, което предложих, се свежда до замяна на No_full_cell_data (празен клас) с какъвто и да е клас, съдържащ вашите данни, това не променя политиката. Ако смятате да наричате всички чисти решения хакове, това е много лошо за вас. И все още не сте обяснили онзи бизнес с клас обвивка, от който се оплаквате.   -  person Marc Glisse    schedule 19.06.2015
comment
Лошото ми... Отметнах Triangulation_ds_full_cell вместо Triangulation_full_cell. Ще се опитам да последвам предложението ви. Благодаря.   -  person Dmitry Yershov    schedule 19.06.2015