FMEditor Project

[Chuzhoi]

Поясняю на примере. 0,001 х 0,005 = 0,000005. Ну как, увеличилась разрядность? А если на это число потом надо делить, а разрядности не хватает для отображения значащих цифр?

Тут дело еще в том, что сама арифметика с плавающей точкой по своей природе приблизительна. И при перемножении данных чисел после 0,000005, скорее всего, окажется еще несколько нулей и следом будут идти какие-нибудь цифирки. Более того, даже при переводе 0,001 и 0,005 в двоичную систему, вероятно, возникнет какая-нибудь погрешность и при обратном переводе это уже будут не совсем 0,001 и 0,005. Я не знаю нюансов, но предположу, что в каких-то отдельных случаях - скажем, при сложении/вычитании целых чисел - плавающая точка и даст абсолютно точный результат. Но когда дело доходит до поворотов, тут в дело вступает тригонометрия с ее иррациональностью и погрешности просто не могут не появиться. А учитывая, что вертексы у брашей не существуют сами по себе, а их координаты обсчитываются относительно центра, который у каждого браша свой, то два вертекса, которые принадлежат разным брашам и которые до поворота имели совпадающие координаты, при повороте слегка разъедутся и мир, так сказать, даст небольшую трещину, которая, несмотря на свою микроскопичность (а может, и благодаря ей), скажется при дальнейших расчетах (bsp/портализация). Все это должен учитывать автор редактора. И, надеюсь, учитывает, раз он так смело крутит брашами.

[nemyax]

вертексы у брашей

У брашей плоскости.

Более того, даже при переводе 0,001 и 0,005 в двоичную систему, вероятно, возникнет какая-нибудь погрешность и при обратном переводе это уже будут не совсем 0,001 и 0,005.

Вот тут можно посмотреть, во что преобразуются вещественные: https://www.binaryconvert.com/convert_float.html

[Chuzhoi]

У брашей плоскости.

Ну в данном контексте это не так важно.

[off]Кстати, в UnrealEd (по крайней мере, ранних версий) можно независимо перемещать вертексы у брашей, и редактор совершенно не следит, чтобы они были в одной плоскости - это возлагается на дизайнера. И если дизайнер на этим не уследил, то редактор при ребилде карты не сможет построить по вертексам плоскость и возникает глюк типа "hall of mirrors".[/off]

Вот тут можно посмотреть, во что преобразуются вещественные: https://www.binaryconvert.com/convert_float.html

Да, любопытно.

[HellRaiser]

М-да. Числа с плавающей точкой - это частенько боль для разработчиков. Один только вывод чего стоит (100500+ способов и ни одного единственно правильного). Округления, округления и ещё раз округления или пренебрежения незначащими знаками, а насколько они значащие, по иронии, знает только сам разработчик.

Все всё правильно написали, просто чуть дополню.
Далеко не всякое число можно точно представить в данном формате: например безобидная 1.64 (или 1.24?) будет в разных фреймворках представляться по-разному. Наиболее точное значение 1.639999... Но оно не нужно пользователю! Поэтому надо округлять, причём правильно. То, что у флоута 7 знаков ПОСЛЕ запятой - это заблуждение. А правильно на самом деле: у флоута 7 знаков, у дабла 15. Всего! (естественно, в нормализованном виде и НЕ экспоненциальной нотации).
Таким образом, во флоут без потерь можно записать число наподобие 123.4567 или 1.234567, в дабл - побольше. Всё остальное уже тонкие материи, операции с незначащими или условно значащими знаками определены в даташитах конкретных (со)процессоров.
Хорошим тоном при работе с плавающими числами считается преобразование исходных данных из флоута в дабл (или из дабл в лонг дабл) и выполнение операций над расширенными значениями, с последующим преобразованием результата в исходное (если оно вообще возможно). Чаще всего, в повседневных задачах это прокатывает.
ЗЫ: Со всякими моделированиями на супер-ЭВМ я не знаком, но там совершенно другие, более точные алгоритмы работы с плавающими числами, причём их диапазон намного превышает вместимость обычных даблов и лонг даблов (числа размером в сотни или даже тысячи байт). Причём, обрабатываться всё это барахло может как сугубо софтово, так и софтово-аппаратно (может и только аппаратно, я не в курсе какие сейчас ФПУ стоят на супер-ЭВМах и что они самостоятельно умеют делать с длинными числами).

[Zontik]

Скорее всего и на рендере видно щель при большом приближении, раз проваливается.

У меня был случай при работе над 9-й миссией "Патриота". Редактор отрапортовал о незначительной ошибке. Некоторое время спустя я, исследуя проблемную область, обнаружил место, в котором проваливаешься в преисподнюю прямо сквозь ровный и плоский газон. Никаких щелей, разумеется, нет, да и все координаты круглые как глобус. Проблему решил, только когда работа над миссией уже была практически закончена: изменил способ и порядок наложения воздушных/твердых брашей.  Сделал это просто так, в порядке бреда. Внешне ничего не поменялось, а ошибка ушла бесследно.

Скорее всего и на рендере видно щель при большом приближении, раз проваливается.

У меня был случай при работе над 9-й миссией "Патриота". Редактор отрапортовал о незначительной ошибке. Некоторое время спустя я, исследуя проблемную область, обнаружил место, в котором проваливаешься в преисподнюю прямо сквозь ровный и плоский газон. Никаких щелей, разумеется, нет, да и все координаты круглые как глобус. Проблему решил, только когда работа над миссией уже была практически закончена: изменил способ и порядок наложения воздушных/твердых брашей.  Сделал это просто так, в порядке бреда. Внешне ничего не поменялось, а ошибка ушла бесследно.

Тут дело еще в том, что сама арифметика с плавающей точкой по своей природе приблизительна. И при перемножении данных чисел после 0,000005, скорее всего, окажется еще несколько нулей и следом будут идти какие-нибудь цифирки.

Забавно. Я как-то иначе представлял себе арифметику. Впрочем, это ведь уже и не она вовсе, так?
Как-то странно все это работает. Аналоговая математика?
Что любопытно - именно так в редакторе и происходит, непонятно откуда может вылезти значащая цифра в n-ном знаке после запятой. А поскольку по умолчанию отображаются только две значащие цифры, ты обычно об этом и не знаешь, пока гром не грянет. Выход - обнуление вручную.

Далеко не всякое число можно точно представить в данном формате: например безобидная 1.64 (или 1.24?) будет в разных фреймворках представляться по-разному. Наиболее точное значение 1.639999...

А можно в простых словах  объяснить, ПОЧЕМУ так происходит? А главное - ЗАЧЕМ?
Кстати, ручное управление вертексами в DromEd тоже присутствует, хоть и в сильно усеченном виде (я же правильно понимаю, что вертекс - это вершина? Как плохо без переводчика...) Есть одна хитрая операция, которую рекомендуется выполнять только в рамках строгих ограничений. Если ошибешься - порой случается тот самый hall of mirrors. А если не ошибешься - удается совместить вершины, которые путем базовых манипуляций с примитивами не совмещаются ну никак. И построить ломаную крышу, которая не течет.
Сейчас точно не вспомню, как называется операция - нет редактора под рукой, но, по-моему, она даже в меню присутствует.

[HellRaiser]

А можно в простых словах  объяснить, ПОЧЕМУ так происходит? А главное - ЗАЧЕМ?

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

[Zontik]

Вам, наверное, будет смешно это читать, но я до сих пор даже не задумывался, что в двоичной системе можно выражать не только целые числа! Теперь-то понятно, в чем проблема.

Спойлер

Все люди делятся на 10 категорий:
- понимающие двоичную систему;
- не понимающие ее.

[свернуть]

[nemyax]

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

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

[Force]

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

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

Шон Баррет как раз об этом писал, что это был его серьезный косяк, он строит BSP-дерево налету, вместо того чтобы сначала анализировать геометрию, а потом уже разбивать оптимальным образом. Из-за этого, его деревья могли получаться очень несимметричными.

[Marzec]

Привет. Я публикую ссылку на наш первый девлог:

https://youtu.be/epmTvLwDay0

[Force]

Marzec
Привет! Спасибо за внимание к русскоязычному сообществу Thief!
Ты выбрал замечательную дату, чтобы опубликовать это видео: сегодня Thief 2 исполняется 21 год!
Чуть ранее я уже публиковал эту ссылку в теме миссии Зонтика, которую показали в этом видео .
Многие с предвкушением ожидают публикации вашего проекта, чтобы, возможно впервые, опробовать свои навыки в строительстве миссий для Thief.

-------------

Hi! Thanks for your attention to the Russian-speaking Thief community!
You've chosen a great date to publish this video: Thief 2 turns 21 today!
Earlier, I already published this link in the topic of the Zontik's mission, which was shown in this video .
Many are eagerly awaiting the publication of your project so that, perhaps for the first time, they can try their skills in building missions for Thief.

[Marzec]

Hi! Thanks for your attention to the Russian-speaking Thief community!

Well, Russian is one of the three languages of my website, so I should have posted something already here long time ago

The truth is I have my personal translator, which makes this possible

Then, I think writing here on your forum in English is not very nice. My Russian is almost zero, so probably I will occasionally reply to your posts here, with the help of said person.

You've chosen a great date to publish this video: Thief 2 turns 21 today!

Of course it was intentional

Earlier, I already published this link in the topic of the Zontik's mission, which was shown in this video .

I see, so that's why YouTube analytics showed me your website already has link to it

Many are eagerly awaiting the publication of your project so that, perhaps for the first time, they can try their skills in building missions for Thief.

This is what motivates me & Juliusz K. (PinkDot) to finish this project. We both like DromEd, but DromEd doesn't like new potential FM authors. Our goal is to solve this problem.

[Zontik]

Then, I think writing here on your forum in English is not very nice.

I think it's so special occasion and nobody bothers.
Good luck with your project!
(Никто же не возражает, правда? Удачи с проектом!)

[nemyax]

Никто же не возражает, правда?

Конечно никто. Но тогда всё-таки nobody minds, иначе получается "всем лень".

[Zontik]

А, точно!
Хотя в моем варианте тоже есть доля правды.