Кривой бокс

Автор
Сообщение
На сайте c 05.12.2019
Сообщений: 5
Всем мученикам 3ds max привет) Такая вот проблема, 2018 версия, создаётся не ровный бокс, просто открываешь макс, создаёшь бокс и он кривой, в максимальном зуме видно как точки не в плоскости, причём бывает повёрнут в 2х плоскостях, дважды перебивал винду, никто не понимает даже в какую сторону смотреть, может кто сталкивался подскажите где зарыта та псина) Фото прикреплю.

На сайте c 23.07.2016
Сообщений: 805

А с противоположной стороны что? Такое же смещение или ровно ?

На сайте c 31.03.2008
Сообщений: 1095
Москва

Вы даже если Plane создатите, то при максимально-неадекватном зуме он будет визуально кривым.

Формально он ровный, координаты точек по Z одинаково нулевые. Это вид на горизонтальный плейн из вьюпорта Front.

При таком уровне зума вьюпорт вообще ведет себя неадекватно, зачем вам это?

Скорее всего это связано не с самой геометрией а с проекцией во вьюпорте. Сложно сказать наверняка.

На сайте c 17.03.2020
Сообщений: 3252
spb

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

в автокаде такая же фигня иногда вылазит. на рабочку не влияет, на "натуру" тоже

На сайте c 31.03.2008
Сообщений: 1095
Москва
Цитата madYuppie:
это может быть проявлением проблемы округления, т.к. в векторных форматах иногда невозможно добиться конечной точности.

Вы правы.

Числа с плавающей точкой это фундаментальная вещь в любом софте, не только в "кривом 3дмаксе". Компуктеру неудобны эти ваши десятичные системы исчисления (он пока-что умеет хранить лишь бит вкл и бит выкл), а в его двоичном представлении не любое число является тем, которое мы видим на экране.

Можно считать, что красота несовершенства находит своё проявление даже в таких вещах :)

На сайте c 19.04.2018
Сообщений: 762
а какие единицы стоят и сколько после запятой?
На сайте c 13.06.2015
Сообщений: 918
Ukraine, Kyiv

У меня тоже такая же проблема. Тоже заметил что если создать бокс, повернуть по двум осям на 90 градусов, и растиражировать. То точки на боксе будут не в плоскости, так же как и сами боксы. При максимальном зумме.

Проверил это на 3х 3д максах: 2015, 2018, 2020. Везде одно и то же. Интересно почему так?)

На сайте c 31.03.2008
Сообщений: 1095
Москва

Кажется уже объяснялось на форуме, но вряд ли это будет легко найти. Не знаю зачем я это щас буду объяснять, мне просто нечем заняться :)

___

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

На сегодняшний день 3дмакс для своих вычислений использует 32 битные числа с плавающей точкой.

Каждое числовое значение в максе занимает одну "коробочку" размером 32 бит, это значит что в коробочке лежат 32 переключателя, и каждый из них может быть либо вкл, либо выкл. Набор этих переключателей и интерпретируется как число.

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

В случае с целыми числами (integer) всё достаточно интуитивно. Максимальное кол-во комбинаций это 2 в 32 степени, плюс нам нужно поделиться половиной комбинаций для отрицательных чисел, и еще ноль.

В случае с дробными числами (float) всё почти также, но интересней.

Заходим на сайт https://www.h-schmidt.net/FloatConverter/IEEE754.html 

Вводим в You entered 1000.0, ниже видим число, которое на самом деле хранится в памяти - тоже 1000. Кайф.

А если 1000.00091? Упс. Хранится уже 1000.00091552734375, потому что именно такое число определяется ближайшей возможной комбинацией переключателей в коробочке (наша комбинация написана в Binary Representation).

А если 1000.00092? То же самое. Потому что следующая возможная комбинация это уже 1000.0009765625 и между ними разница (ошибка) больше.

Что если мы подвинем точку вправо. Сделаем 10000009.1, храниться будет 10000009. И для .2 и .3 тоже.

Ну ничего себе, раньше у нас была ошибка какие то крошечные ~0.000014, а сейчас аж целые 0.3! Да, ведь мы потратили нашу коробочку на хранение длинного числа, и для оставшихся после точки чисел у нас осталось не так уж много бит.

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

И будет ясно, что же это за Resulting Accuracy и почему сцену колбасит далеко от центра координат.

На сайте c 05.12.2019
Сообщений: 5
Цитата -NiK-:

Кажется уже объяснялось на форуме, но вряд ли это будет легко найти. Не знаю зачем я это щас буду объяснять, мне просто нечем заняться :)

___

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

На сегодняшний день 3дмакс для своих вычислений использует 32 битные числа с плавающей точкой.

Каждое числовое значение в максе занимает одну "коробочку" размером 32 бит, это значит что в коробочке лежат 32 переключателя, и каждый из них может быть либо вкл, либо выкл. Набор этих переключателей и интерпретируется как число.

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

В случае с целыми числами (integer) всё достаточно интуитивно. Максимальное кол-во комбинаций это 2 в 32 степени, плюс нам нужно поделиться половиной комбинаций для отрицательных чисел, и еще ноль.

В случае с дробными числами (float) всё почти также, но интересней.

Заходим на сайт https://www.h-schmidt.net/FloatConverter/IEEE754.html  

Вводим в You entered 1000.0, ниже видим число, которое на самом деле хранится в памяти - тоже 1000. Кайф.

А если 1000.00091? Упс. Хранится уже 1000.00091552734375, потому что именно такое число определяется ближайшей возможной комбинации переключателей в коробочке (наша комбинация написана в Binary Representation).

А если 1000.00092? То же самое. Потому что следующая возможная комбинация это уже 1000.0009765625 и между ними разница (ошибка) больше.

Что если мы подвинем точку вправо. Сделаем 10000009.1, храниться будет 10000009. И для .2 и .3 тоже.

Ну ничего себе, раньше у нас была ошибка какие то крошечные ~0.000014, а сейчас аж целые 0.3! Да, ведь мы потратили нашу коробочку на хранение длинного числа, и для оставшихся после точки чисел у нас осталось не так уж много бит.

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

И будет ясно, что же это за Resluting Accuracy и почему сцену колбасит далеко от центра координат.

вот это завернул)) вообщем суть теперь понятна) миллиметры само собой... а ползунок лучше не трогать?

 

На сайте c 31.03.2008
Сообщений: 1095
Москва
Цитата YurijRylin:
ползунок лучше не трогать?

Ползунок ни на что не влияет. Он просто показывает какая будет точность для числа (а число это расстояние от центра координат).

___

А еще цитировать можно не всё сообщение, а только выделенный кусочек :)

На сайте c 05.12.2019
Сообщений: 5

Постараюсь всем ответить, для начала спасибо что разъяснили ситуацию. Дело в том что догадывался что проблема не только у меня, просто когда бокс не один да и с чамферами и их начинаешь с привязкой стыковать начинается нечто, потом уже хрен поймёшь куда вязать) да и ещё, может кто вкурсе, два обьекта рядом с привязкой и в максимальном зуме выбираешь поочерёдно то они двигаются как ненормальные, если ресет иксформ применить то вообще сдвигаются, волшебство вообщем) Кстати NiK растолковал на молекулярном уровне) теперь понятно почему иногда бокс создаётся нормальный(из-за разных видимо размеров) и с разных сторон бывает по разному. На счёт проекции вьюпорта, на это как то повлиять можно? потому что наново установил макс и он мне сразу мне вот такую подставу кривую выдал.

Цитата freys2011:

У меня тоже такая же проблема. Тоже заметил что если создать бокс, повернуть по двум осям на 90 градусов, и растиражировать. То точки на боксе будут не в плоскости, так же как и сами боксы. При максимальном зумме.

Проверил это на 3х 3д максах: 2015, 2018, 2020. Везде одно и то же. Интересно почему так?)

Вот тут прям в точку)) ад перфекциониста)) тем более когда работаю с мелкими зачастую деталями... Почитай мою писанину, тож такие траблы когда жмёшь всё двигается? и ресетиксформ...

Цитата -NiK-:
Цитата YurijRylin:

А еще цитировать можно не всё сообщение, а только выделенный кусочек :)

ок)) я так сказать не опытный на форумах)

На сайте c 20.08.2018
Сообщений: 563
работаю в 2018 уже почти 2 года. Никаких проблем. Тем более с привязками и ровностью граней. Если make planar не работает и грани все равно кривые, то у вас в компе живет барабашка.
На сайте c 05.12.2019
Сообщений: 5
Цитата murad.odeev:
работаю в 2018 уже почти 2 года. Никаких проблем. Тем более с привязками и ровностью граней. Если make planar не работает и грани все равно кривые, то у вас в компе живет барабашка.

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

На сайте c 20.08.2018
Сообщений: 563

Цитата freys2011:
Тоже заметил что если создать бокс, повернуть по двум осям на 90 градусов, и растиражировать

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

Цитата YurijRylin:
так вот и я уже думаю о барабашке

определенно он. Дома Nvidia видюха. На работе Radeon. На одном I3, на другом I7. Никогда не замечал никаких отклонений в линиях, ибо я тоже очень придирчивый в этом. Вроде бы такая дрянь была в 2017 максе, который даже при движениях обычных подвисал. Он вообще мне попался забагованный и быстро улетел в корзину. Но после установки обычного 2018 без sp, стало все нормально работать и до сих пор без нареканий. 

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

На сайте c 31.03.2008
Сообщений: 1095
Москва

Цитата murad.odeev:
все боксы идеальны

Дело же не в боксах вовсе. Какого они у вас размера при каких юнитах?

Цитата murad.odeev:
Видимо это сам вьюпорт глючит иногда и дает не точный ровный угол просмотра.

Именно

На сайте c 20.08.2018
Сообщений: 563

Цитата -NiK-:
Дело же не в боксах вовсе. Какого они у вас размера при каких юнитах?

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

Создал 5000 мм и на вид одинаковые, но при выделении начала одна грань вылазить. 

50000 мм даже при приближении начали выдавать двойную грань, которая при выборе стала глючить (появляться и исчезать)

Сцена в киллометрах вообще отказывается показывать бокс в 50 мм :)

На сайте c 31.03.2008
Сообщений: 1095
Москва

Вот пожалуйста

https://forums.autodesk.com/t5/3ds-max-ideas/double-precision-for-max/idi-p/6788410 

Голосуйте за дабл пресижн, если конечно эти голоса вообще хоть на что-либо влияют.

На сайте c 19.04.2018
Сообщений: 762
оно итак натужно работает а вы хотите чтоб ещё больше код раскурочили.
Читают эту тему: