Узкое место процессора; простой способ управления рендерингом 3D-сцены с множеством не * stati c объектов

Question

В настоящее время я работаю над небольшим движком 3D-рендеринга. Однако я столкнулся с проблемой в моем рендерере. Вот как это работает в настоящее время:

С одной стороны, у меня есть граф сцены / ECS, используемый для обработки всех объектов SceneObjects, которые есть в моей игре. Каждый объект сцены может иметь одного родителя и от 0 до N детей. Я могу прикрепить компоненты к каждому SceneObject. Компоненты могут быть различными вещами, такими как рендеринг, освещение или камеры.

С другой стороны, у меня есть мой рендерер, который полностью агностирован c вне моей иерархии сцены. Фактически, каждый раз, когда я добавляю компонент «Renderable» в SceneObject, мой визуализатор получает уведомление и создает свое собственное представление визуализируемого (Me sh, BoundingBox et c.). Мой рендерер не заботится о родителях или дочерних элементах рендеринга.

Проблема, с которой я сталкиваюсь, возникает, когда я хочу получить видимые объекты перед тем, как поместить их в RenderQueue. На стороне рендерера все рендерабельные элементы хранятся в плоском списке 1008 *, и для выполнения операций отбраковки мне нужно l oop в этом списке. К сожалению, этот список содержит все активные объекты моей игры, и я могу очень потреблять процессорное время .

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

Спасибо за вашу помощь.

Answer 1

Это больше вопрос об алгоритмах:

Это много алгоритмов разделения пространства, таких как KD-Tree , Oct-tree , VP -tree и многие другие.

Выбор наиболее подходящего алгоритма зависит от объекта, который вы хотите сохранить (они выпуклые?), их размера, как часто вам нужно вычислять пересечения с ними. они стоят c, динамические c в положении, форме?

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

Обычно движок рендеринга будет использовать как минимум 2 дерева, одно для сбора информации c обычно предварительно рассчитывается для оптимального хранения и производительности луча / пересечения), а один - для динамических c объектов.

Кроме того, в зависимости от того, является ли ваш объект выпуклым или вогнутым, а также для точности пересечения лучей, вам может потребоваться чтобы разбить ваши вогнутые объекты на выпуклые части (и пересечь ограничивающую рамку только этих частей), посмотрите на V-HACD в качестве шага предварительной обработки для ваших вогнутых объектов. Это позволяет ограничить количество вычислений пересечения луча / объекта большим квадратом вместо множества поверхностей.