Comments 24
Есть ли способ передвинуть объект на 17 и более километров от центра так, чтобы графика не взорвалась?
Или таки придётся делать floating origin?
Или таки придётся делать floating origin?
Перейти с float на double, либо да, двигать привязку координат.
Это я знаю, но.
Да, я могу отказаться от PhysX и использовать свою кинематику, основанную на double. Этого хватит на 17 миллионов (или миллиардов? не помню) километров, что для «наземной» симуляции весьма достаточно. Хватит и на миллиметровую точность или ещё точнее.
Но сам-то мир Unity3D, вроде бы, построен на float, и, помимо кинематики в вакууме, есть:
* коллизии. Сможет ли Unity безглючно рассчитать контакт автомобиля или лучше самолёта с террейном далеко от центра, если расстояние в сантиметрах будет выше ёмкости float? А мешей объектов друг с другом?
* графическое отображение. Сможет ли Unity безглючно визуализировать террейн и окружающие объекты так же далеко от центра?
Да, я могу отказаться от PhysX и использовать свою кинематику, основанную на double. Этого хватит на 17 миллионов (или миллиардов? не помню) километров, что для «наземной» симуляции весьма достаточно. Хватит и на миллиметровую точность или ещё точнее.
Но сам-то мир Unity3D, вроде бы, построен на float, и, помимо кинематики в вакууме, есть:
* коллизии. Сможет ли Unity безглючно рассчитать контакт автомобиля или лучше самолёта с террейном далеко от центра, если расстояние в сантиметрах будет выше ёмкости float? А мешей объектов друг с другом?
* графическое отображение. Сможет ли Unity безглючно визуализировать террейн и окружающие объекты так же далеко от центра?
В вопросе не было ни слова про юнити. Нет, штатная физика в юнити не умеет большие дистанции от начала координат как раз из-за ограничения точности float-ов. Нет, визуализация так же использует float-ы.
Спасибо!
Хотя вопрос включал графику к физике, что могло подразумевать фреймворк/либу, предположительно Unity ;-)
А что, есть графика на double?
Хотя вопрос включал графику к физике, что могло подразумевать фреймворк/либу, предположительно Unity ;-)
А что, есть графика на double?
А почему бы и нет? Софтовый рендер никто не отменял :)
Есть поддержка даблов вроде в свежих шойдерах от нвидии, но под рендер все равно все заточено под флоат.
Но с другой стороны — вы же все равно на миллион километров не смотрите, почему бы не рендерить с центром в начале координат?
В блоге Space Engeneer (автор космического планетария Space Engine) есть статьи про то, как он решал схожие проблемы. Для масштаба от камней до галактик дабла тоже не хватает — он собирал приемы относительных центров координат, рендер камеры со смещаемым фрустумом (чтобы рисуя 3 планеты, использовать большую часть точности именно на z-test планет, а не на пустой космос между ними) и прочие хаки.
Но с другой стороны — вы же все равно на миллион километров не смотрите, почему бы не рендерить с центром в начале координат?
В блоге Space Engeneer (автор космического планетария Space Engine) есть статьи про то, как он решал схожие проблемы. Для масштаба от камней до галактик дабла тоже не хватает — он собирал приемы относительных центров координат, рендер камеры со смещаемым фрустумом (чтобы рисуя 3 планеты, использовать большую часть точности именно на z-test планет, а не на пустой космос между ними) и прочие хаки.
Ну с 17 км будет сантиметровая точность. Но вообще в Unity да — floating origin. Можно придумать какой угодно маппинг, но по своей сути — это floating origin. И сохранить значения PhysX физики не так сложно (ну проскочит один кадр или можно сделать ручную компенсацию)
В целом тут две основные причины почему рендер на double особого смысла не имеет. Если камера движется вместе с симуляцией, то с помощью тех же матриц компенсировать позиции чисто для рендера — не самая страшная задача. Дабл работает медленнее, так как просто процессору нужно больше регистров складывать. И скажем PhysX сам по себе работает с флотом. С точки зрения рендера такая точность не имеет смысла, так как объект на расстоянии 17 км от камеры или 18 км от камеры это в большинстве случаев и так, и так пару пикселей. Если нужна точность для расчёта самой симуляции и без PhysX (какая-нить жидкостная симуляция или просто математическая, а юнити для визуализации) то проще считать всё в дабле в своих методах, где нужна точность, а потом делать отображение модели симуляции во флот со сдвигом.
В целом тут две основные причины почему рендер на double особого смысла не имеет. Если камера движется вместе с симуляцией, то с помощью тех же матриц компенсировать позиции чисто для рендера — не самая страшная задача. Дабл работает медленнее, так как просто процессору нужно больше регистров складывать. И скажем PhysX сам по себе работает с флотом. С точки зрения рендера такая точность не имеет смысла, так как объект на расстоянии 17 км от камеры или 18 км от камеры это в большинстве случаев и так, и так пару пикселей. Если нужна точность для расчёта самой симуляции и без PhysX (какая-нить жидкостная симуляция или просто математическая, а юнити для визуализации) то проще считать всё в дабле в своих методах, где нужна точность, а потом делать отображение модели симуляции во флот со сдвигом.
В общем дело тут не только в Unity. Сам PhysX на такое не рассчитан, а с точки зрения рендера такой диапазон чисел просто смысла не имеет. Так как если дистанция между объектом и камерой будет 17км, то объект тупо не будет видно в большинстве случаев с перспективной камерой. А дабл жрёт больше памяти, работает медленнее и т.п. Конечно было бы удобное апи, чтобы люди стреляли себе в ногу и не понимали, почему фпс в разы медленнее, чем на флоте, и почему PhysX всё равно глючит, если в него прокидывается дабл. А так, учитывая что всё то, что находится в фруструме камеры не требует такой точности, достаточно построить правильное преобразование всех позиций из одного трёхмерного пространства в другое. Да, применить ко всем объектам. Исходя из «абстрактной позиции мира» и «позиции камеры». Самое простое (но правда для реалтайма вряд ли подходит при сложной симуляции) — считать что камера в (0,0,0) вообще всегда для рендера, и к ней подтягивается мир. В этом случае у нас ломается только OcclusionCulling, но зато самая высокая точность с точки зрения рендера будет по идее)
Тут не просто PhysX на это не рассчитан, а тут сразу целый ворох проблем:
1) Обычные видеокарты работают во флотах, погуглите цену видеокарт которые могут и даблы и флоты — это Квадры и Теслы.
2) PhysX вообще изначально затачивался под ускорение на GPU (см 1) и векторизацию (см далее), так шо да — там только флоты
3) SSE будет работать быстрее — вместо 2-х double будет отрабатываться 4 float (вообще цифры от балды, надо смотреть по конкретному процессору сколько у него FPU и какая у них разрядность, но в любом случае, процессор за инструкцию сможет отрабатывать вдвое больше флотов чем даблов)
4) Память и пропускная способность памяти...
Но это все верно для векторизованных операций, для скалярных операций нет никакой разницы (хотя за счёт выравнивания можно немного потерять для float).
Но в любом случае доя обычной ТрыДэ графики только флоты и ничего более. Даблы — это все же для научных вычислений (вот там я сталкивался с тем что и двойной точности может не хватить).
В PhysX можно при создании сцены указать примерные размеры с которыми вы будете работать. Т.е. если у вас симулятор самолёта, то можно подсказать движку что у вас в юнете 100м, и он, скорей всего, будет внутри у себя масштабировать на это значение, чтобы не терять в точности.
Блин, рейтинга не хватает проголосовать ) нормальные статьи продолжай в том же духе ).
Спасибо) Но в целом видимо математику не любят. По сравнению с другими статьями статистика прям печальная)
а с точки зрения рендера такой диапазон чисел просто смысла не имеет
Смысл есть — если оба, и камера, и объект на 20км от центра, при этом рядом друг с другом, то неточность float, как я предполагаю, можно будет наблюдать вблизи. Хотя бы потому, что графический mesh точно так же поплывёт.
О математике: зависит от математики. Иногда авторы дают сущие трюизмы. Иногда авторы дают темы, настолько нерелевантные хабру, что я не знаю, что и говорить.
Позиции в сцене юнити для рендера и позиции в симуляции не обязаны совпадать. Абстрагировать симуляцию так, чтобы у тебя камера всегда находилась в (0,0,0) в юнити сцене, а остальное двигалось с поправкой на это — не супер большая проблема. Смысла нет, так как действительно важно расстояние между камерой и объектами. OpenGL если мне не изменяет память работает с интом и флотом (GLSL), а PhysX с флотом, то есть дабл округлится в этой точке, и мы получим тоже самое. Задача симуляции — не так часто встречается и легко обыгрывается, но на уровне движка её обыгрывать нет смысла, так как это приводит к не очевидному поведению.
По проводу тривиального забавно, как быстро профессионалы забывают, что такое быть новичком и вообще не осознавать для чего знать тот же метод Хаусхолдера. При том, что встанет задача распарсить любой формат у которого ось y в отличии от юнити направлена вниз, а сам формат хранит TRS (собственно формат LDraw про который я сейчас потихоньку пишу статью) и без матриц крякнешься думать, как это всё считать.
TRS — это вообще отдельная песня. Так как, как и с методом Хаусхолдера найти адекватное структурированное описание что это и из чего складывается — надо постараться. Сама матрица простая, если это написано не языком вышмата, а русским. Так как если мы перейдём к определению, в котором вообще это всё работает в гиперплоскости строго говоря, то думаю большинство тупо не сможет прочесть этот текст со справочником (матрица 4х4, а работаем мы с 3д пространством)
В целом меня закладки в плане статистики интересуют больше голосов, так как они больше показывают кому та или иная статья была полезна. Эта серия статей не про рокет саенс и сложные алгоритмы. Это по сути про популяризацию математики, так как чтобы была мотивация её учить, нужно чтобы было понятно — зачем. И это зачем проще объяснять на простых примерах, которые можно потрогать и поиграться с ними. И которые в целом легко прочесть.
Потом постепенно может буду увеличивать сложность материала. Но условно если брать кватернионы, про них есть крутая огромная статья объясняющая что это, и вот её цель как раз таки научить. Цель же этого цикла показать — зачем читать эту огромную статью про кватернионы к примеру, и дать готовую реализацию каких-то простых компонент для примера, чтобы было ясно, как это можно использовать в Unity. В конкретно этой статье примера нет, так как про LDraw хочется написать отдельно
По проводу тривиального забавно, как быстро профессионалы забывают, что такое быть новичком и вообще не осознавать для чего знать тот же метод Хаусхолдера. При том, что встанет задача распарсить любой формат у которого ось y в отличии от юнити направлена вниз, а сам формат хранит TRS (собственно формат LDraw про который я сейчас потихоньку пишу статью) и без матриц крякнешься думать, как это всё считать.
TRS — это вообще отдельная песня. Так как, как и с методом Хаусхолдера найти адекватное структурированное описание что это и из чего складывается — надо постараться. Сама матрица простая, если это написано не языком вышмата, а русским. Так как если мы перейдём к определению, в котором вообще это всё работает в гиперплоскости строго говоря, то думаю большинство тупо не сможет прочесть этот текст со справочником (матрица 4х4, а работаем мы с 3д пространством)
В целом меня закладки в плане статистики интересуют больше голосов, так как они больше показывают кому та или иная статья была полезна. Эта серия статей не про рокет саенс и сложные алгоритмы. Это по сути про популяризацию математики, так как чтобы была мотивация её учить, нужно чтобы было понятно — зачем. И это зачем проще объяснять на простых примерах, которые можно потрогать и поиграться с ними. И которые в целом легко прочесть.
Потом постепенно может буду увеличивать сложность материала. Но условно если брать кватернионы, про них есть крутая огромная статья объясняющая что это, и вот её цель как раз таки научить. Цель же этого цикла показать — зачем читать эту огромную статью про кватернионы к примеру, и дать готовую реализацию каких-то простых компонент для примера, чтобы было ясно, как это можно использовать в Unity. В конкретно этой статье примера нет, так как про LDraw хочется написать отдельно
По этой причине это сказано в самом начале до ката, что тут нет ничего супер сложного, и если вы разбираетесь в теме, то в статье не найдёте ничего нового. Но я работаю с огромным числом самых разных проектов, так как не являюсь штатным сотрудником, и чаще дорабатываю чужие решения. И вот костыли связанные с незнанием математики встречаются слишком часто. При этом достаточно простых вещей, а не того, что допустим при физическом моделировании, при использовании метода конечных элементов, ошибка зависит от самого острого угла треугольника, и поэтому EarClipping — не лучший алгоритм, чтобы триангулировать что-либо в подобных задачах. И надо использовать хотя бы Делоне.
>> Смысл есть — если оба, и камера, и объект на 20км от центра, при этом рядом друг с другом, то неточность float, как я предполагаю, можно будет наблюдать вблизи. Хотя бы потому, что графический mesh точно так же поплывёт.
18 км — это максимальная дальность горизонта… в море, со смотровой вышки в 25 метров. 50 км — это уже с воздушного шара и это максимальная дистанция на которой человеческий глаз будет способен заметить пламя свечи… в полной темноте.
5 км — это то расстояние на котором поверхность Земли уже имеет заметное искривление для человеческого глаза, если игровая сцена больше, то это уже надо земной шарик симулить и это уже совершенно иной уровень игр :-)
Если не делать симуляции космических миров и не заниматься научными расчетам, то я если честно плохо понимаю откуда могут взяться эти десятки километров. Если уж говорить о симуляторах, типа DCS, Orbiter, Silent Hunter, то Юнити явно не движок выбора для таких игр. Хотя вон KSP сделан на Unity, там флоты и ничего, они как-то с этим справились (хотя глюки связанные с точностью там таки вылазиют).
18 км — это максимальная дальность горизонта… в море, со смотровой вышки в 25 метров. 50 км — это уже с воздушного шара и это максимальная дистанция на которой человеческий глаз будет способен заметить пламя свечи… в полной темноте.
5 км — это то расстояние на котором поверхность Земли уже имеет заметное искривление для человеческого глаза, если игровая сцена больше, то это уже надо земной шарик симулить и это уже совершенно иной уровень игр :-)
Если не делать симуляции космических миров и не заниматься научными расчетам, то я если честно плохо понимаю откуда могут взяться эти десятки километров. Если уж говорить о симуляторах, типа DCS, Orbiter, Silent Hunter, то Юнити явно не движок выбора для таких игр. Хотя вон KSP сделан на Unity, там флоты и ничего, они как-то с этим справились (хотя глюки связанные с точностью там таки вылазиют).
Яковлев Як-9, обычный, рядовой истребитель, 1943 год.
Максимальная скорость 600км/ч на высоте 4000м.
16км — это меньше двух минут.
Для 1945 нормальные скорости 680-720км/ч.
Играть в «NATOвские истребители не могут в Эстонии превысить скорость звука, потому, что территория настолько мала и кончается слишком быстро для разгона» не охота.
С другой стороны интересно посмотреть, как это всё будет летать над танками, среди которых ультра-максимальная скорость 72км/ч. Такая же для обычного эсминца.
Скорость вне дороги 16-20км/ч, что потребует до 60 минут на 16км.
Оно, конечно, если бы я хотел поэкспериментировать с самолётиками и только — это одно.
Максимальная скорость 600км/ч на высоте 4000м.
16км — это меньше двух минут.
Для 1945 нормальные скорости 680-720км/ч.
Играть в «NATOвские истребители не могут в Эстонии превысить скорость звука, потому, что территория настолько мала и кончается слишком быстро для разгона» не охота.
С другой стороны интересно посмотреть, как это всё будет летать над танками, среди которых ультра-максимальная скорость 72км/ч. Такая же для обычного эсминца.
Скорость вне дороги 16-20км/ч, что потребует до 60 минут на 16км.
Оно, конечно, если бы я хотел поэкспериментировать с самолётиками и только — это одно.
А это вот о том что я писал — уже полноценный симулятор Вы хотите. На мой взгляд это уже не на Unity надо делать. DCS, Orbiter, Ил-2, Тундра, Элит, Стар Ситтезен, и даже такие RTS, как Steel division (там тоже территории огромные) — все на самописных движках (или очень сильно переколбашенных) и писали их очень-очень пряморукие Си++ погроммисты. И эти игры очень сильно отличаются от 99% типичных.
Т.е. либо все должно происходить в масштабах максимум 5км х 5км, а все скорости и дальности стрельбы делать в логарифмическом масштабе. Например, реально танки не 70-80 км/ч раскатывают по полю боя — это вообще что-то запредельно, раскатывают по полю боя они куда медленнее. В добавок они же должны совместно с пехотой работать, а это сразу ограничение на среднею скорость. Так что на все эти 40+ км/ч — это на марше по ровному шоссе можно рассчитывать. А например, у сверхзвукового F-16 крейсерская скорость чойт порядка 0.68..0.84 Маха (скорость звука зависит от высоты, как и крейсерская и максимальная скорость самолета), т.е. 230..280 м/с, что не сильно быстрее того же Яка-9 (и даже почти как у пассажирского Боинга), у которого эти 600 км/ч (~170 м/с, т.е. примерно 0.5 Маха) бывают только по праздникам и на большой высоте (4 км и более), так то реальный диапазон скоростей у Як-9 которым он будет оперировать на практике будет думаю где-то в районе 150-300 км/ч (в общем пролетать на нем карту 5x5 игроки в среднем будут за минуту-две, что уже дофига), а реальный оперируемый диапазон скоростей у F-16 будет начинается где-то эдак с 300 км/ч (примерно с 80 м/с), а дальше уже по ситуации, а все эти 1000+ км/ч и сверхзвуки — это на форсаже. Т.е. даже у реальных объектов рядовые цифры скромнее. Ещё есть ограничения и на скорость восприятия информации человеком. В общем если сильно не упирать на симуляция, то можно немного подрезать максимальные скорости или сделать масштаб нелинейным.
Либо принебрегать детализацией, допустим 1 unit не 1 метр, а 100 метров или сколько там можно выбрать.
Либо придется много страдать и костылять. А страдать придётся сильно. На процессоре с использованием SIMD инструкций производительность в даблах упадёт вдвое по сравнению с сингл, а на GPU (а главная фишка того же PhysX, то что он умеет юзать видеокарту для ускорение) производительность упадёт совсем круто и это будет куда больше чем в 2 раза, т.к. они (именно геймерские сегмент) заточены исключительно под сингл-прецижен, да ещё и память не резиновая у них. Собственно с графоном тоже могут начать вылазить косяки страдать гигантоманией (не уверен).
В общем без страданий и костылей в Unity3D чуда не случится. У разработчиков KSP — получилось, но если судить по тому как долго шла разработка и какие весёлые баги я там наблюдал как игрок, то костылей там немерено было и все это было через боль, страдания и унижения. wiki.kerbalspaceprogram.com/wiki/Deep_Space_Kraken/ru
Просто 6-7 значимых деесятичных знаков (сингл) вообще-то вполне себе хватает для большинства прикладных задач. 14-15 значимых знаков (дабл) — это уже уровень научных вычислений. Но если начать симулить солнечную систему в реальном масштабе (есть такая игра как Rodina, там нечто подобное), то тут и даблов может не хватит, но я с таким сталкивался всего пару раз в очень спецефических задачах.
Т.е. либо все должно происходить в масштабах максимум 5км х 5км, а все скорости и дальности стрельбы делать в логарифмическом масштабе. Например, реально танки не 70-80 км/ч раскатывают по полю боя — это вообще что-то запредельно, раскатывают по полю боя они куда медленнее. В добавок они же должны совместно с пехотой работать, а это сразу ограничение на среднею скорость. Так что на все эти 40+ км/ч — это на марше по ровному шоссе можно рассчитывать. А например, у сверхзвукового F-16 крейсерская скорость чойт порядка 0.68..0.84 Маха (скорость звука зависит от высоты, как и крейсерская и максимальная скорость самолета), т.е. 230..280 м/с, что не сильно быстрее того же Яка-9 (и даже почти как у пассажирского Боинга), у которого эти 600 км/ч (~170 м/с, т.е. примерно 0.5 Маха) бывают только по праздникам и на большой высоте (4 км и более), так то реальный диапазон скоростей у Як-9 которым он будет оперировать на практике будет думаю где-то в районе 150-300 км/ч (в общем пролетать на нем карту 5x5 игроки в среднем будут за минуту-две, что уже дофига), а реальный оперируемый диапазон скоростей у F-16 будет начинается где-то эдак с 300 км/ч (примерно с 80 м/с), а дальше уже по ситуации, а все эти 1000+ км/ч и сверхзвуки — это на форсаже. Т.е. даже у реальных объектов рядовые цифры скромнее. Ещё есть ограничения и на скорость восприятия информации человеком. В общем если сильно не упирать на симуляция, то можно немного подрезать максимальные скорости или сделать масштаб нелинейным.
Либо принебрегать детализацией, допустим 1 unit не 1 метр, а 100 метров или сколько там можно выбрать.
Либо придется много страдать и костылять. А страдать придётся сильно. На процессоре с использованием SIMD инструкций производительность в даблах упадёт вдвое по сравнению с сингл, а на GPU (а главная фишка того же PhysX, то что он умеет юзать видеокарту для ускорение) производительность упадёт совсем круто и это будет куда больше чем в 2 раза, т.к. они (именно геймерские сегмент) заточены исключительно под сингл-прецижен, да ещё и память не резиновая у них. Собственно с графоном тоже могут начать вылазить косяки страдать гигантоманией (не уверен).
В общем без страданий и костылей в Unity3D чуда не случится. У разработчиков KSP — получилось, но если судить по тому как долго шла разработка и какие весёлые баги я там наблюдал как игрок, то костылей там немерено было и все это было через боль, страдания и унижения. wiki.kerbalspaceprogram.com/wiki/Deep_Space_Kraken/ru
Просто 6-7 значимых деесятичных знаков (сингл) вообще-то вполне себе хватает для большинства прикладных задач. 14-15 значимых знаков (дабл) — это уже уровень научных вычислений. Но если начать симулить солнечную систему в реальном масштабе (есть такая игра как Rodina, там нечто подобное), то тут и даблов может не хватит, но я с таким сталкивался всего пару раз в очень спецефических задачах.
Да. Похоже что так и это пичалька. Из личного опыта — был у меня как-то проект под который внезапно расширялся штат и как раз искал программиста в первую очередь и из gamedev (кстати и сейчас ищут я, но уже не ко мне и там совсем все жёстко, как раз с ТрыДэ графоном). Шерстили геймдеве И
Именно из того расчёта, что с математикой они там точно дружат, а преобразование Хаусхолдера и кватернионы (на самом деле я сам это слово пишу часто с ошибкой) для него не будут словами из заклинания по вызову Ктулху.
Ну перебрать пришлось 50+ человек, откопал 2-3 (и таки с геймдев опытом), но реально удовлитворительный математический бэкграунд был только у одного. Я сам на самом деле с детства не люблю матрицы-шматрицы и все эти комплексные и гиперкомплексные числа, но ситуация чойт совсем пичалька если честно — математику не знают и самое главное учить не хотят. И судя по рейтингу Вашего сообщения ещё и математикофобией народ страдает.
Самое забавное тут пишут про трюизмы, но я уже сбился со счета сколько раз народ спрашивает как реализовать тот же PID регулятор на Unity (даже статью тут запилил ради этого), хотя это уже давно пережеванная и избитая тема. Так что любая практическая около математическая статья полезна — у всех есть пробелы в знаниях, а человек хорошо помнит только то, чем недавно занимался… но вот рейтинги таких статей…
Именно из того расчёта, что с математикой они там точно дружат, а преобразование Хаусхолдера и кватернионы (на самом деле я сам это слово пишу часто с ошибкой) для него не будут словами из заклинания по вызову Ктулху.
Ну перебрать пришлось 50+ человек, откопал 2-3 (и таки с геймдев опытом), но реально удовлитворительный математический бэкграунд был только у одного. Я сам на самом деле с детства не люблю матрицы-шматрицы и все эти комплексные и гиперкомплексные числа, но ситуация чойт совсем пичалька если честно — математику не знают и самое главное учить не хотят. И судя по рейтингу Вашего сообщения ещё и математикофобией народ страдает.
Самое забавное тут пишут про трюизмы, но я уже сбился со счета сколько раз народ спрашивает как реализовать тот же PID регулятор на Unity (даже статью тут запилил ради этого), хотя это уже давно пережеванная и избитая тема. Так что любая практическая около математическая статья полезна — у всех есть пробелы в знаниях, а человек хорошо помнит только то, чем недавно занимался… но вот рейтинги таких статей…
Про кватернионы хоть что-нить сказали ради приличия.
Sign up to leave a comment.
Математика в Gamedev по-простому. Матрицы и аффинные преобразования