Дизайн системы частиц?
Некоторые базы данных позволяют нескольким значениям быть сохраненными в отдельном столбце единственной строки, но обычно более удобно использовать отдельную таблицу.
Составляют таблицу с двумя столбцами, тот, который содержит указатели на первичный ключ таблицы объектов и тот, который содержит указатели на первичный ключ фруктовой таблицы. Затем если объект имеет три фруктов, существует три строки в object_fruit таблице что вся вся точка к тому же объекту, но к трем различным фруктам.
3 ответа
Эта настройка должна подойти. Я надеюсь, вы думаете о том, какие данные будут составлять частицу, которая будет в классе частиц. Вам нужно иметь только самое необходимое, поэтому вам нужно будет читать / писать как можно меньше памяти при работе системы.
Что касается управления данными, это должно быть довольно просто. Я бы предложил вариант загрузки в формате xml и двоичном формате. так что вы можете легко настраивать вещи во время разработки (и не имея инструмента). Когда у вас есть инструмент или вы закончите настройку, я бы преобразовал xml в двоичный файл для быстрой загрузки.
Вам также может понадобиться класс менеджера, который обрабатывает создание и обновление этих систем частиц. Это также позволит вам обрабатывать другие функции, связанные со всеми вашими системами. Некоторыми примерами этого являются ограничение количества систем частиц или частиц, которыми можно управлять из соображений производительности, или наличие плоскости столкновения, которую должны учитывать все системы.
Вы упоминаете, что это сделано в образовательных целях, и в этом отношении эти вещи довольно придирчиво (но важно, если вы собираетесь использовать это в игре, в которой много частиц).
Я предполагаю, что для рендеринга используется API, такой как DirectX или OpenGL. В этом отношении я бы хотел, чтобы все эффекты частиц использовали один и тот же пул памяти для вашей информации о вершинах. Это очень помогает скорости рендеринга. Я бы также отслеживал границы области, затронутой системой частиц, для использования с отсечкой усеченного конуса (AABB или Circle).
Огромная часть обновления системы частиц - это то, как атрибуты переходят от одного значения к другому. Чем более динамичным вы можете сделать интерполяцию значений, тем лучше будут выглядеть ваши эффекты. Простая линейная интерполяция может быть достаточно хорошей, но может быть лучше иметь динамический график, который используется для интерполяции значений. Например, вместо того, чтобы переходить от 0 до 255 синего за секунду, может быть круто перейти от 0 до 128 за 0,2 секунды, а затем от 128 до 255 за 0,8 секунды. Добавление этого значительно расширит возможности того, как выглядят ваши эффекты.
Кроме того, я думаю, у вас есть довольно хорошее представление о том, что вы хотите сделать. Ваше упоминание о рендеринге различных типов частиц говорит мне, что вы правильно думаете об этом. Я видел, как люди создают движки частиц, просто сосредотачиваясь на рендеринге четырехугольника с билбордами. Возможность испускать трехмерную геометрию действительно делает вещи великолепными. Вы также можете подумать о (если вы еще не t уже), имея возможность вашей системы получать информацию о модели и динамически разбивать ее на отдельные частицы, которые будут испускаться. На самом деле взрыв модели выглядит намного лучше, чем отображение какой-нибудь частицы взрыва и затемнение объекта или его перевод в поврежденное состояние.
Просто несколько идей по оптимизации простых двумерных частиц спрайтов.
Хорошая идея - отправить все частицы в массив вершин / VBO и использовать вершинный шейдер для обновления их положения над время. Это замечательно, если у вас есть простое движение, которое можно легко описать с помощью математической формулы, где x (t) и y (t) (то есть они зависят только от времени) .
Еще одна замечательная идея - использовать точечные спрайты вместо треугольников и четырехугольников. Это должно сократить требуемую пропускную способность конвейера до четверти.
В моем космическом симуляторе я реализовал самый тривиальный подход: частицы отправлялись в виде текстурированных четырехугольников с использованием glBegin () / glEnd () . Их сбрасывают в текущий «сектор» как отдельные объекты и полностью независимы от момента сброса. Это наиболее примитивный, глупый и идиотский поступок, который приводит к значительному снижению производительности, особенно с учетом того, что я перебираю объекты через итератор вектора STL и отправляю каждый из них последовательно.
Вам нужно чтобы определить, сколько частиц вы хотите и что вы хотите от них делать. * Вы хотите, чтобы они реагировали на окружение и сталкивались? Затем вам потребуется обновление, обрабатываемое ЦП, и данные, отправляемые снова и снова. * Они просто летают самым глупым образом? Тогда вам, возможно, удастся отправить все частицы как VBO и TBO и обновить их в шейдере.
Удачи!
Обновлено в соответствии с комментарием №1 от автора вопроса: -)
What I будет использовать принцип KISS . Это означает: класс с именем ParticleEmitter , содержащий массив вершин, массив скоростей и вектор STL с экземплярами простых коллайдеров, таких как плоскость, сфера, треугольник. Кроме того, имейте «глобальный» вектор * STL с коллайдерами. Затем обновите скорости в соответствии с коллайдерами.
То же самое можно сделать с аффекторами (гравитация, ветер и т. Д.): Еще один вектор STL в ParticleEmitter с аффекторами и еще один «глобальный» Вектор STL с аффекторами.
Аффекторы и коллайдеры будут классами, которые будут реализовывать ffectParticle (Particle_t *) . где struct particle_t {float x, y, z; float vx, vy, vz; } . Я бы сохранил его структуру POD и запустил обновление в ParticleEmitter :: update () .
Однако, если вы используете это на iPhone, может ли это быть чрезмерным усложнением? Возможно, вам сойдет с рук то, что вы уже реализовали? Я понятия не имею, как мой дизайн может повлиять на результаты тестов, но для меня это звучит достаточно разумно, если вы продолжите отсчет частиц, коллайдера и аффектора, потому что похоже, что он может масштабироваться приблизительно с n * c + n * a .
Это всего лишь мои специальные мысли и то, как я лично их воплощаю. Ваш дизайн или дизайн других людей,
Я реализовал такой же хороший дизайн для моего собственного движка на C ++. Вместо этого я не использовал ссылки и политики шаблонов (стратегии - прочтите «Современный дизайн C ++» Александреску). Статический полиморфизм дает лучшую производительность.