Объем замкнутой триангулированной оболочки проще посчитать как сумму ориентированных объемов тетраэдров (треугольных призм), каждый из которых образован одним из треугольников оболочки (с учетом его ориентации) и произвольной точкой (например началом координат). Т.е. аналогично двумерному случаю, где площадь замкнутого невыпуклого многоугольника можно посчитать как сумму ориентированных площадей треугольников, образованных каждым ребром и произвольной точкой.
На мой взгляд это проще для понимания и реализации, по крайней мере для вычисления нужны только операция умножения и сложения/вычитания и не нужно вычисление квадратного корня.
Ну выглядит так, что -> там перегруженный оператор, которые возвращает nullptr, если has_value() возвращает false. Т.е. key_data_ это что то типа какого то умного указателя, типа shared_ptr.
Так это я сам на свой комментарий и ответил :)
Тут ситуация аналогичная такой: допустим есть указатель ptr на какой то класс, у которо есть метод foo(), возвращающий bool. Если написать
if ((ptr != nulptr) && ptr->foo())
то все будет нормально, даже если ptr будет nullptr, а если написать
if ((ptr != nullptr) & ptr->foo())
то ptr->foo() вызовется в любом случае и все упадет.
Не вижу, как эта ошибка могла на что то влиять. Поведение в обоих случаях должно быть одинаковым, если обе функции возвращают bool (на что указывает их название). Скорее просто исправили эту описку в процессе поиска реального бага.
Интерполяцию сплайнами тоже делал. Только использовал эрмитов сплайн, потому что он ведет себя более предсказуемо. Обычный кубический сплайн часто начинает осцилировать, особенно если в интерполируемых данных присутствует шум. Ну и при изменении одной точки эрмитов сплайн меняется только локально. Но зато вторая производная у него не непрерывна.
Поэтому делал так: интерполировал ломаную сплайном, а потом уже делал тесселяцию сплайна ломаной, но уже с более мелким шагом, и для нее уже использовал метод с поворотом координатной системы.
Делал такое для ломаных линий. Там нельзя посчитать нормаль по понятным причинам, поэтому просто в первой точке выбирал произвольное направление нормали, перпендикулярное направлению. А потом просто в каждой новой точке поворачивал координатную систему на угол поворота вектора направления (т.е. осью вращения было векторное произведение векторов предыдущего направления и нового).
Странно, кстати, что в статье нет упоминания про проблему пересечения сечений. Для заданных значения кривизны кривой и радиуса сечения всегда существует минимальный шаг между сечениями при котором сечения начнут пересекаться, в результате чего модель получается некорректной.
100 метровые файлы у него бинарные. А ASCII файл, про который речь в статье, судя по тому, что в нем 7982 треугольников, занимает всего несколько десятков килобайт.
По моему автор этого комментария просто не понял смысл правок. В том месте (parse_args.c ), которое, как я понял, он назвал «оптимизацией», на мой взгляд цель в другом — сделать так, чтобы аргументы остались лежать в памяти подряд, как они и лежали до этого.
Но баг то как раз не в этом месте, а в правке в первом файле (sudoers.c).
Речь не про конкретный формат, а про потерю точности. В DICOM обычно минимум 12 бит на пиксель, а бывает и больше. При конвертации в картинку обычно все обрезается до 8 бит, соответственно точность теряется.
Можно ведь и в 16-битный grayscale конвертировать. Не знаю точно, поддерживает ли PNG 16-битный цвет, но думаю да. Для КТ вообще проблем не должно быть, т.к. там единая шкала Хаунсфилда, просто нужно все аккуратно сконвертить. Для МРТ придется как то нормализовывать конечно, т.к. там нет единой шкалы.
Здесь, как я понял, они даже со шкалой Хаунсфилда не разобрались и из-за этого у них какие то проблемы были.
Томографы пишут файлы в стандарте DICOM, но интерпретация стандарта и форматы записи могут сильно отличаться, поэтому много времени и нервов ушло на поддержку файлов, которые пишут все КТ аппараты.
Похоже вы просто не разобрались, как хранятся изображения в формате DICOM. И скорее всего в итоге работали с RGB картинками, а не с исходными DICOM изображениями. Хотя не могу сказать, влияет ли это на результат.
Судя по коду (оригинальному и исправленному) нового героя можно купить только через 7 дней после покупки предыдущего. Флаг здесь означает — прошло или нет 7 дней с покупки предыдущего героя, при этом параллельно ведется количество прошедших дней. От номера недели, на которой был куплен герой, ничего не зависит и в коде номер недели никак не фигурирует.
Если так, тогда не факт, что и ваш патч правильный, т.к. он вполне может изменить задуманную логику совместной работы этого флага, выставленного другими способами, и сброса через количество дней.
Приведенный код — хороший пример того, как не надо писать. Зачем заводить две сущности — флаг доступности таверны и число дней с момента покупки героя, когда достаточно одной — числа дней? Из-за этого код и получается запутанным и в нем легко ошибиться. С одной сущностью (числом дней) логика была бы гораздо проще и ошибиться в ней было бы гораздо сложнее.
Но к самому патчу это, конечно, не имеет отношения. Понятное дело, что приходится работать с тем, что есть :)
По-моему с прямоугольниками очень даже понятно. Хотя возможно это индивидуально. Но конечно нужно уже иметь какое то представление, что такое floating point.
На мой взгляд это проще для понимания и реализации, по крайней мере для вычисления нужны только операция умножения и сложения/вычитания и не нужно вычисление квадратного корня.
Тут ситуация аналогичная такой: допустим есть указатель ptr на какой то класс, у которо есть метод foo(), возвращающий bool. Если написать
то все будет нормально, даже если ptr будет nullptr, а если написать
то ptr->foo() вызовется в любом случае и все упадет.
Поэтому делал так: интерполировал ломаную сплайном, а потом уже делал тесселяцию сплайна ломаной, но уже с более мелким шагом, и для нее уже использовал метод с поворотом координатной системы.
Странно, кстати, что в статье нет упоминания про проблему пересечения сечений. Для заданных значения кривизны кривой и радиуса сечения всегда существует минимальный шаг между сечениями при котором сечения начнут пересекаться, в результате чего модель получается некорректной.
А на примеры данных где то посмотреть можно? Хотелось попробовать как будет выглядеть в нашем софте.
Но баг то как раз не в этом месте, а в правке в первом файле (sudoers.c).
А U/N может быть гораздо больше чем N, как в вашем же примере из этого комментария.
Можно ведь и в 16-битный grayscale конвертировать. Не знаю точно, поддерживает ли PNG 16-битный цвет, но думаю да. Для КТ вообще проблем не должно быть, т.к. там единая шкала Хаунсфилда, просто нужно все аккуратно сконвертить. Для МРТ придется как то нормализовывать конечно, т.к. там нет единой шкалы.
Здесь, как я понял, они даже со шкалой Хаунсфилда не разобрались и из-за этого у них какие то проблемы были.
Похоже вы просто не разобрались, как хранятся изображения в формате DICOM. И скорее всего в итоге работали с RGB картинками, а не с исходными DICOM изображениями. Хотя не могу сказать, влияет ли это на результат.
Но к самому патчу это, конечно, не имеет отношения. Понятное дело, что приходится работать с тем, что есть :)