Устранение неполадок в физике
При работе с физическим движком вы можете столкнуться с неожиданными результатами.
Хотя многие из этих проблем можно решить с помощью настройки, некоторые из них являются результатом ошибок движка. Список известных проблем, связанных с физическим движком, можно найти в разделе открытые проблемы, связанные с физикой на GitHub. Ознакомление со списком закрытых проблем также может помочь найти ответы на вопросы, связанные с поведением физического движка.
Объекты проходят друг через друга на высоких скоростях
Это называется туннелированием (tunneling). Включение параметра Continuous CD в свойствах RigidBody иногда может решить эту проблему. Если это не помогает, попробуйте другие решения:
Увеличьте толщину статических коллизий. Например, если у вас тонкий пол, под который игрок по какой-то причине не может попасть, вы можете сделать коллайдер толще визуального представления пола.
Измените форму столкновения быстро движущегося объекта в зависимости от его скорости. Чем быстрее движется объект, тем больше должна выступать форма столкновения за его пределы, чтобы обеспечить более надёжное столкновение с тонкими стенами.
Увеличьте значение Physics Ticks per Second в расширенных Project Settings. Хотя это и даёт другие преимущества (например, более стабильную симуляцию и уменьшение задержки ввода), это увеличивает нагрузку на CPU и может быть нецелесообразным для мобильных и веб-платформ. Для плавного отображения на большинстве дисплеев рекомендуется использовать множители по умолчанию
60(например,120,180или240).
Сложенные объекты неустойчивы и шатаются
Несмотря на кажущуюся простоту задачи, стабильная симуляция RigidBody с наложенными друг на друга объектами сложно реализуется в физическом движке. Это вызвано суммированием сил, действующих друг на друга. Чем больше наложенных друг на друга объектов, тем сильнее будут эти силы. В конечном итоге это приводит к тому, что симуляция становится неустойчивой, и объекты не могут лежать друг на друге без движения.
Увеличение частоты симуляции физики может помочь решить эту проблему. Для этого увеличьте значение Physics Ticks per Second в расширенных настройках проекта. Обратите внимание, что это увеличивает нагрузку на процессор и может быть неэффективным для мобильных и веб-платформ. Для плавного отображения на большинстве дисплеев предпочтительны множители по умолчанию 60 (например, 120, 180 или 240).
В 3D переключение физического движка с GodotPhysics по умолчанию на Jolt также может повысить стабильность. Подробнее см. Использование физики Jolt.
Масштабированные физические тела или формы столкновений не сталкиваются правильно
Godot в настоящее время не поддерживает масштабирование физических тел и форм столкновений. В качестве обходного решения измените границы формы столкновения вместо её масштаба. Если вы хотите, чтобы масштаб визуального представления также изменился, измените масштаб базового визуального представления (Sprite2D, MeshInstance3D и т.д.) и измените границы формы столкновения отдельно. В этом случае убедитесь, что форма столкновения не является дочерним элементом визуального представления.
Поскольку ресурсы по умолчанию являются общими, вам придётся сделать ресурс формы столкновения уникальным, если вы не хотите, чтобы изменение применялось ко всем узлам, использующим этот же ресурс формы столкновения в сцене. Это можно сделать, вызвав duplicate() в скрипте для ресурса формы столкновения перед изменением его размера.
Тонкие предметы шатаются, когда лежат на полу
Это произошло по одной из двух причин:
Форма столкновения пола слишком тонкая.
Форма столкновения RigidBody's слишком тонкая.
В первом случае это можно облегчить, сделав форму столкновения пола толще. Например, если у вас тонкий пол, ниже которого игрок каким-то образом не может пройти, вы можете сделать коллайдер толще, чем визуальное представление пола.
Во втором случае эту проблему обычно можно решить только увеличением скорости физического моделирования (поскольку увеличение толщины формы приведет к разрыву между визуальным представлением RigidBody's и его столкновением).
В обоих случаях увеличение частоты симуляции физики также может помочь решить эту проблему. Для этого увеличьте значение параметра Physics Ticks per Second в расширенных настройках проекта. Обратите внимание, что это увеличивает нагрузку на процессор и может быть нецелесообразным для мобильных и веб-платформ. Для плавного отображения на большинстве дисплеев предпочтительны множители по умолчанию 60 (например, 120, 180 или 240).
Формы столкновения цилиндров нестабильны
Переключение физического движка со стандартного GodotPhysics на Jolt должно повысить надёжность столкновений цилиндров. Подробнее см. в документе Использование физики Jolt.
При переходе от Bullet к GodotPhysics в Godot 4 формы столкновений цилиндров пришлось переопределять с нуля. Однако формы столкновений цилиндров — одна из самых сложных для поддержки форм, поэтому многие другие физические движки не предоставляют для них никакой поддержки. В настоящее время известно несколько ошибок с формами столкновения цилиндров.
Если вы придерживаетесь GodotPhysics, мы рекомендуем пока использовать для персонажей формы столкновений в виде коробок или капсул. Кубы, как правило, обеспечивают наибольшую надёжность, но имеют недостаток: персонаж занимает больше места по диагонали. Формы столкновений в виде капсул лишены этого недостатка, но их форма может затруднить точные прыжки по платформам.
Симуляция VehicleBody нестабильна, особенно на высоких скоростях
Когда физическое тело движется с высокой скоростью, оно проходит большое расстояние между каждым физическим шагом. Например, при использовании соглашения 1 единица = 1 метр в 3D, транспортное средство, движущееся со скоростью 360 км/ч, будет проходить 100 единиц в секунду. При частоте обновления физической модели по умолчанию 60 Гц транспортное средство перемещается примерно на 1,67 единицы за каждый физический тик. Это означает, что транспортное средство может полностью игнорировать мелкие объекты (из-за туннелирования), но также и то, что у моделирования в целом мало данных для работы на такой высокой скорости.
Быстро движущиеся транспортные средства могут значительно выиграть от повышения частоты моделирования физики. Для этого увеличьте значение параметра Physics Ticks per Second в расширенных настройках проекта. Обратите внимание, что это увеличивает нагрузку на процессор и может быть неэффективным для мобильных и веб-платформ. Для плавного отображения на большинстве дисплеев рекомендуется использовать множители по умолчанию 60 (например, 120, 180 или 240).
Столкновение приводит к ударам, когда объект движется по тайлам
Это известная проблема физического движка, возникающая из-за того, что объект ударяется о края фигуры, даже если этот край закрыт другой фигурой. Это может происходить как в 2D, так и в 3D.
Лучший способ обойти эту проблему — создать «составной» коллайдер. Это означает, что вместо столкновения отдельных тайлов вы создаете единую форму столкновения, представляющую столкновение для группы тайлов. Как правило, вам следует разделять составные коллайдеры по каждому острову (это означает, что каждая группа соприкасающихся тайлов получает свой собственный коллайдер).
Использование составного коллайдера также может в некоторых случаях повысить производительность физического анализа. Однако, поскольку составная форма реализуется гораздо сложнее, она не во всех случаях может принести чистый выигрыш в производительности.
Совет
В Godot 4.5 и более поздних версиях создание составного коллайдера выполняется автоматически при использовании узла TileMapLayer. Размер фрагмента (по умолчанию 16 тайлов на каждой оси) можно задать с помощью свойства Physics Quadrant Size в инспекторе TileMapLayer. Большие значения обеспечивают более надёжное столкновение, но при этом замедляют обновление при изменении TileMap.
Частота кадров падает, когда объект касается другого объекта
Вероятно, это связано с тем, что один из объектов использует слишком сложную форму столкновения. Выпуклые формы столкновений должны использовать как можно меньшее количество фигур из соображений производительности. Полагаясь на автоматическую генерацию Godot, возможно, вы получите десятки, если не сотни фигур, созданных для одного ресурса столкновения выпуклых форм.
В некоторых случаях замена выпуклого коллайдера парой примитивных форм столкновения (коробка, сфера или капсула) может обеспечить лучшую производительность.
Эта проблема также может возникнуть со StaticBodies, которые используют очень подробные коллизии с использованием вогнутых сеток (треугольных сеток). В этом случае используйте упрощённое представление геометрии уровня в качестве коллайдера. Это не только значительно улучшит производительность моделирования физики, но и повысит стабильность, позволяя исключить мелкие фиксаторы и трещины из рассмотрения при коллизиях.
В 3D переключение физического движка с GodotPhysics по умолчанию на Jolt также может повысить производительность. Подробнее см. Использование физики Jolt.
Частота кадров внезапно падает до очень низкого значения за пределами определенного уровня симуляции физики
Это происходит из-за того, что физический движок не справляется с ожидаемой частотой симуляции. В этом случае частота кадров начинает падать, но движку разрешено симулировать лишь определённое количество шагов физики за один отрисовываемый кадр. Это приводит к ситуации, когда частота кадров продолжает падать, пока не достигнет очень низкого значения (обычно 1-2 FPS), что называется физической спиралью смерти.
Чтобы избежать этого, следует проверить наличие в проекте ситуаций, которые могут привести к чрезмерному количеству одновременных симуляций физики (или к чрезмерно сложным формам столкновений). Если избежать таких ситуаций невозможно, можно увеличить значение параметра проекта Max Physics Steps per Frame и/или уменьшить значение Physics Ticks per Second, чтобы смягчить последствия.
Физическое моделирование ненадежно, когда оно находится далеко от начала координат мира
Это вызвано ошибками точности операций с плавающей точкой, которые становятся более выраженными по мере удаления моделирования физики от начала координат. Эта проблема также влияет на рендеринг, приводя к рывкам камеры при удалении от начала координат. Подробнее см. в документе Большие мировые координаты.