Это только очень частный случай. А представьте себе какая-то ваза стоит на полу и немного "вдавлена" в пол. Тут мы имеем сотни отрезков пересечения. Очевидно что пытаться классифицировать все случаи бесполезно, нужна более общая "engine". Какая?

Понял, разместил, даю ссылку
http://i022.radikal.ru/0908/b0/b948c7d4e4f7.png

Для простоты полагаем что все состоит из треугольников имеющих представительную площадь. Например на картинке каждый квадрат состоит из 2 треугольников. Результат должен быть в том же формате - корректная геометрия. 

На деле все намного хуже. Сначала смотришь - солидная компания, солидный сайт и т.п.. Разрабатывайте пожалуйста, вот Вам бета-тестирование, мы обеспечиваем на своем сайте и все такое. Ну пашешь конечно как папа Карло. И только потом доходит - меня просто использовали, ничего я здесь заработать не мог "в принципе". И тот кто мне письма хорошие писал - прекрасно об этом знал. И я далеко не первый и не последний мотылек прилетевший на этот огонь 

1) в 3-х измерениях
2) Никаких принципов пока нет - это и есть цель/тема обсуждения. Пока я умею находить точки/отрезки пересечений.
3) Цель - та же геометрия но с новыми вершинами (вертексами) в местах пересечений. Для этого надо построить новые треугольники.
4) Гарантируется что все исходные полигоны корректны (планарны). Все в памяти (примерно до 12 Gb) свапа на диск нет.

Edit: хотел "прикрепить картинку" а она что-то "не прикрепляется"   Наверное что-то не так делаю

Здравствуйте

Есть полигоны (только треугольники), нужно разбить их в местах где они пересекают друг друга. Задача очень близка к boolean, но в данном случае цель - улучшение качества карты освещенности. Сам инструмент collision detection у меня есть. Я могу определять что ребро и/или полигон пересекает другой полигон, могу найти точки пересечения. Проблема в том что делать когда пересечения найдены и как вообще организовать данные. Например, один большой полигон (такой как пол или потолок) может пересекаться с очень многими другими. Что мне делать с найденными отрезками пересечений? Как собрать их в новые полигоны?

Идеи, предложения?

Заранее спасибо

Я буду сидеть на 10.5 до последней возможности. Неприятности искать не надо, они сами нас находят    От 10.6 уже получил: скорее всего прийдется переписывать драйверы для hardware key, т.к. все ядро 10.6 в 64-bits.  

Вызов new/delete гораздо дороже чем передача структуры по значению. Само инвертирование довольно сложное, больше 100 строк, поэтому надо держать его в 1 функции. Разумеется, Ваш и мой варианты будут работать, но согласитесь: ковбой из Колорадо написал короче/проще     

Spectre, я просто рассказал все что я знаю на Mac по этому поводу (начиная с 1994) . Ecли Вас это не устраивает - это не моя проблема (к счастью не я разрабатываю OSX). Будьте здоровы

Так сходу не получается  Defaulrt NULL не имеет смысла, нет исходной матрицы - нечего инвертировать. Присвоение theInvertedMatrix ничего не дает т.к. theInvertedMatrix должна (довольно тщательно) вычисляться. Логика мало изменилась со времен Аристотеля - и она столь же неумолима (знание классов мало помогает :-)) 

Таких сайтов довольно много, и я (к сожалению) имел (не)счастье с этой системой ознакомиться на практике. Мои личные выводы: НИКОГДА юзер не воспринимает серьезно программу/продукт которая "даже" не имеет своего сайта, своей системы платежей и.т.п.  Не имейте иллюзий что кто-то будет продавать Вашу программу за Вас - хотя такой продавец и найдется, его цели будут совсем другие.

Глагол "ложить" должен употребляться с приставкой, глагол "класть" - без приставки. Так и с продажей программ - какую-то "приставку" нужно иметь 

Для приколов есть другие threads. Здесь же (увы) прийдется все разжевывать. Часто (в большинстве случаев)  нужно инвертировать матрицу "на месте". В этом случае theInvertedMatrix и theSourceMatrix указывают на тот же адрес. При передаче обеих матриц по адресу/ссылке надо это предусмотреть:


А он просто сказал компилятору то же сделать  и спокойно вызывает

Нативные файловые диалоги "Open" и "Save" = 2 совершенно разных диалога (по крайней мере на Mac). Разные нативные функции (типа NavGetFile/NavPutFile) используются для каждого, разные нативные ресурсы и т.п. Это 2 разных сервиса, а не 2 режима того же диалога. Для "Open" диалога строки ввода никогда не было, а для "Save" всегда была. Претензии к Qt программистам в данном случае беспочвенны     

Прямое попадание. все правильно. Поздравляю! 

Подумайте как было бы удобно (и неудобно) вызывать функцию InvertMatrix. Какие проблемы/неудобства могут возникнуть при использовании классического

void InvertMatrix( Matrix * theInvertedMatrix, const Matrix * theSourceMatrix );

?

Пережил 3 поколения нативных файл диалогов в Mac (каждый раз приходилось переписывать программы). Но ни разу не видел строку ввода чтобы в режиме "Open"   Конечно, можно ее добавить через customize, но то глухой нативняк.