Войти
ПрограммированиеФорумГрафика

Создание гибкой системы частиц на основе стратегий. (комментарии)

Страницы: 1 2 Следующая »
#0
16:56, 12 дек. 2010

Создание гибкой системы частиц на основе стратегий. (комментарии)

Это сообщение сгенерировано автоматически.


#1
16:56, 12 дек. 2010

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

#2
22:23, 12 дек. 2010

xmonad
аффекторы желательно иметь

#3
22:27, 12 дек. 2010

xmonad
> Не хочется быть некропостером, однако хочется спросить, является ли данный
> подход к разработке актуальным и в наши дни?
Жуть какая-то. Почти все эффекты частиц нужно делать в соответствующем редакторе, поэтому ни о каких шаблонах речи идти не может. Художник, что, будет просить программистов "а спрограмьте мне дождик"?

#4
0:25, 13 дек. 2010

2Went:
Т.е. такой подход вообще не имеет права на жизнь?
Хорошо, а что на счет скорости? Я так понимаю, Вы за динамический полиморфизм, виртуальные функции и тд?

#5
1:11, 13 дек. 2010

xmonad
> Т.е. такой подход вообще не имеет права на жизнь?
Только в очень узких случаях. Например там, где подобными системами частиц описываются некие фундаментальные среды, типа свободно льющейся воды, или пыли в воздухе по всему уровню. Да даже тот же дождь, если он не просто система частиц, а многомерная сущность, взаимодействующая и с физикой, и с логикой, и специальным образом рисуемая. А если говорить о элементе графа сцены - я против.

> Хорошо, а что на счет скорости? Я так понимаю, Вы за динамический полиморфизм,
> виртуальные функции и тд?
Говоря просто - да, я предпочитаю динамический полиморфизм статическому. Какие бы крышерсывающие возможности не давали бы шаблоны, плата за них всегда очень велика (время компиляции, размер кода, требования к подготовке специалистов и т.п.). Но самое главное - динамический полиморфизм позволяет  собирать "из кирпичиков" сцену непосредственно художником, без привлечения программистов.
А насчет скорости - "Premature optimization is root of all evil in programming". Нужен эффект на стомильенов частиц в реальном времени? Значит, у вас просто художники неправильные :)

#6
1:29, 13 дек. 2010

Went
Большое спасибо за исчерпывающий ответ!
Теперь буду искать информацию по созданию системы частиц, используя динамический полиморфизм. Кое-что, конечно, уже прочитано и изучено, но, тем не менее, хочется спроектировать систему частиц с учётом современных наработок в этой области (изготовляю велосипеды для саморазвития).
Может быть у кого-либо есть интересные ссылки по теме?
Единственное на данный момент, что прочитано и осознано, это "Building Advanced Particle System" by John van der Burg.
Спасибо.

#7
18:14, 13 дек. 2010

В дополнение, появился такой вопрос: как лучше организовать хранение данных о частицах, если я планирую использовать VBO?
Будет ли класс ParticleSystem хранить данные о частицах в нескольких массивах ( float position[maxParticles][3]; float color[maxParticles][4]; ), которые сразу будут привязываться к VBO, или же лучше работать с std::vector <particle>, и при обновлении каждой частицы (до рендеринга), заполнять эти массивы данными из структуры particle?
Я думаю что быстрее работать будет первый вариант, но он, конечно, менее удобный, нежели второй вариант.
Хотелось бы услышать мысли по этому поводу, вдруг я ошибаюсь?

#8
15:40, 14 дек. 2010

Реализовал и первый и второй вариант. Использовал VBO и Point Sprites. 20000 частиц при использовании статических массивов показывают 970 фпс, а при использовании std::vector - 560 фпс.
Однако, всё же склоняюсь к использованию std::vector, так как впоследствии будет намного удобнее работать с непосредственно vec3f и vec4f (математическая библиотека cml), нежели писать огромные конструкции руками с использованием определенных элементов массивов.

#9
17:23, 14 дек. 2010

Лучше списки из мелких статичнъх массивов, которъе въделяются из пула. Новъе партиклс всегда алокируем на новом массивчике, пока он не переполнится. Для каждого массивчика держим масочку, какие партикли в нем еще живъ и когда масочка станет равна нулю, возвращяем массивчик для реюза.

#10
17:27, 14 дек. 2010

помнится, один товарищь страшно желал иметь интрузивные списочки для частичек

#11
17:44, 14 дек. 2010

вектор нафиг, держать в списке патиклы. в анриленжыне забавные патиклы, у нас было примерно также сделано, можно скачать удк поглядеть

#12
15:41, 16 дек. 2010

kas
Исследования в этом документе говорят о тормознутости списков.
Z
Хотелось бы услышать, в чем плюсы такого подхода?
innuendo
Элементы интрузивных списков раскиданы по разным участкам памяти, я так понимаю, что ведет к промахам кеша и в целом более низкой работоспособности, разве не так? Ведь лучше когда данные лежат в одном цельном блоке памяти.

#13
15:51, 16 дек. 2010

xmonad
> Элементы интрузивных списков раскиданы по разным участкам памяти, я так
> понимаю, что ведет к промахам кеша и в целом более низкой работоспособности,
> разве не так? Ведь лучше когда данные лежат в одном цельном блоке памяти.

я делаю частички на статик массивчике

#14
16:37, 16 дек. 2010

innuendo
> помнится, один товарищь страшно желал иметь интрузивные списочки для частичек
это ты что-ле? )

Страницы: 1 2 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.