Вопрос к Майским долгожителям.

[Михаил Потапов (MihaPot)]

Объясните пожалуйста, исходя из вашего опыта, когда Майа быстрей считает (что соответственно отображается на качестве манипуляций ну и динамики), когда объект 10000 на 10000 см, или когда 100 на 100 см, в Преференсах 1см.
В Ципинской книге есть расплывчивый намёк, что "маленькие объекты Майа считает быстрее").
Вопрос к тому стоит ли луг (поляну, стадион), подгонять в еденицах Преференса к реалиям, или делать мелко но наплывать камерами. Где девочка М будет шустрей шевелится.

 

[dimm 653]

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

 

попробуй создать 10 тысяч маленьких кубиков и посмотреть, что будет с майкой...

 

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

 

[R-r-r]

Хочу предупредить господ миниатюристов.
Ибо есть иная крайность...
Если сделать объект слишком маленьким, то Майке небудет хватать знаков после запятой, что повлечёт за собой еще более интересные и трудноисправимые артефакты.
Например если в сцене будет скелетированый перс, мелкие кости будут "соскакивать". Т.е. в одном фрейме кость тут, а в следующем уже совсем нетут....

 

Согласен на 100%. Масштаб имеет значение. При рендеринге - не знаю, но тоже на 90% уверен, что разница будет той же. Увеличение точности не бесплатное. ПлАтите временем.

 

[Ruslan_3D]

Не забывайте про камеру. Она не может наезжать беконечно близко на объекты. А что если нужно показать очень маленький объект очень крупным?

 

Я, кстати, не говорил, что маленькое==быстрое. Я говорил о точности. А для "маленького" она как раз высока, так что речь идет о "средних" масштабах, когда значение имеют до 8 знаков после запятой. ес-сно, желательно - ещё меньше. если мне не изменяет память, при бОльшем количестве будет увеличиваться длина цепочки (8 байт?), иначе - нет.
И наоборот - при длинных числах, но уже больших будет растягиваться и экспонента. Это была "как-бы теория".
Хотя всё это - фуфло. Наверняка в майке сделали скачкообразное масштабирование для ячеек данных. Может, в несколько ступеней, может - нет, не знаю. Так что не стоит мучаться. Единственная проблема, которая действительно может возникнуть - это огромные объекты наряду с микроскопическими в одной сцене. Тут уж прийдётся париться.... Самое простое решение в таких случаях - разрывать сцену на несколько сцен и рендерить в несколько проходов.

 

Граждане, имхо тут какой-то метафизикой пахнет В целочисленной арифметке может быть потеря точности при слишком маленьких значениях, а в плавающей - откуда ей взяться? (само собой, если не извращаться за пределами MINFLOAT Подумайте сами: float или double - это же просто мантисса+степень... Масштабирование в 1.00001 раз одинаково изменит значение мантиссы, независимо от того, имеем ли мы дело с 1е-6 или 1е32.
А уж по скорости-то всяко никакой разницы быть не должно...
Или я не прав?

 

не прав. лев. =)
Действительно, откуда ж ей взяться - потери точности-то? Это ж не целые биты, а "вещественные"...

Нет, конечно, потерь не будет при указанных числах.

А как насчет многократного умножения/деления? Во сколько раз теряется точность? =)
При сложении/вычитании - 1 бит (можно вообще не считать, слишком мало). А какая прогресси для умножения/деления?а если экспоненты слишком разные?
Я так понимаю, настоящие проблемы могут возникнуть на очень больших объектах, где имеют значение микроскопические изменения этих объектов.

ЗЫ: я не думаю, что в майке имеет место быть тип "float".

 

> Я так понимаю, настоящие проблемы могут возникнуть на очень
> больших объектах, где имеют значение микроскопические
> изменения этих объектов.

Согласен. Но если сцену уменьшить/увеличить в 1000000 раз, к лучшему ничего не изменится

> ЗЫ: я не думаю, что в майке имеет место быть тип "float".

Опять же согласен, я просто обобщал

 

да, и ещё. "Вещественная" арифметика - та же "целочисленная", тока в профиль.... =) Привычка игровые движки с целыми (и соответствующей скоростью) экстраполировать до 3Д-грфики с цестными вычислениями - не совсем хорошая привычка. Целые могут дать бОльшую точность. Просто их для этого не используют.

 

.

 

Вот к чему:
> В целочисленной арифметке может быть потеря точности при слишком
> маленьких значениях, а в плавающей - откуда ей взяться?

 

.

 

[dimm 653]

Ну развели теорию. Провел я тут эксперимент. Была у меня старая и очень тяжелая (порядка 80 mb) чиста полигональная нетекстуренная и не анимированная сцена изготовленная с разумной детализацией без излишеств и mech smooth-ов в пределах координатной сетки. Учитывая что это был цельный дворцовый комплекс c фонтанами, деревьями и прочей лабудой (просто большей сцены мне было не нарыть нигде, а кубики множить неспортивно как то) я просто тупо сгруппировал все и добавил ко всем линейным значениям масштаба этой группы по паре нулей. Далее сохранил результат предварительно убив историю перезагрузил шарманку и открыв попытался покрутить. Результат не обрадовал и машину завесил (до того крутилась довольно резво). Так что все же какое-то значение это имеет. В теорию лазать опять же не буду бо правду занют только отцы-разработчики, но при юзерской практике можно таки считать что кроме количества полигонов условный размер значение имеет.

 

Э, так нечестно Надо было не только историю убить, а и freeze transform сделать и потом все обратно разгруппировать...

 

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