Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
ну и?
где подробности? где модель?
я думал, тут будет описание разработки модели или куски препринта хотя бы.
где подробности? где модель?
я думал, тут будет описание разработки модели или куски препринта хотя бы.
Добавил ссылку на научную работу, там есть все формулы и ссылки на исследования по этой теме. Очень полезный документик. Прошу прощения, что сразу не выложил.
— До чего техника дошла!
— Это не техника дошла, это я сама сюда дошла, на лыжах…
— Это не техника дошла, это я сама сюда дошла, на лыжах…
Если пописать не можешь, пригодится…
А если попробовать написать модель с использованием, например, CUDA? Может это позволит хотя бы ускорить процесс генерации?
CUDA, да еще как поможет
откуда вы знаете, если не знаете алгоритма? =))
вот попробуйте «ещё как ускорить» генерацию интегральных изображений, или каскадный любой алгоритм, или любого алгоритма не с изолированным от смежных вычислений ядром =)
вот попробуйте «ещё как ускорить» генерацию интегральных изображений, или каскадный любой алгоритм, или любого алгоритма не с изолированным от смежных вычислений ядром =)
Кстати, как человек который немного разбирается в CUDA (сидя в офисе NVIDIA, чтобы не быть голословным), утверждаю что построение интегрального изображения весьма неплохо параллелится.
Вообще, за много лет существования CPU было придумано множество алгоритмов с элементами рекурсии. Самые популярные причины возникновения рекурсии — это борьба за локальность доступа к памяти (кэш), переиспользование вычислений. Однако сейчас с появлением NVIDIA CUDA, ATI CTM (или как это у них называется теперь, увы не отслеживаю), стало модно переосмыслять алгоритмы в терминах неограниченного многоядерного масштабирования.
Впрочем, у Вас есть очень правильный посыл — можно выделить целый класс алгоритмов которые ни при каком переосмыслении не будут распараллелены.
Вообще, за много лет существования CPU было придумано множество алгоритмов с элементами рекурсии. Самые популярные причины возникновения рекурсии — это борьба за локальность доступа к памяти (кэш), переиспользование вычислений. Однако сейчас с появлением NVIDIA CUDA, ATI CTM (или как это у них называется теперь, увы не отслеживаю), стало модно переосмыслять алгоритмы в терминах неограниченного многоядерного масштабирования.
Впрочем, у Вас есть очень правильный посыл — можно выделить целый класс алгоритмов которые ни при каком переосмыслении не будут распараллелены.
Был бы очень признателен за пояснения в реализации вычисления интегрального изображения!!! так как это единственное, что из «тяжолого» осталось на cpu, при реализации детекции лиц методом ВиолоДжонса =(
Был бы ооочень благодарен!
а такими темами не увлекались? Software Configurable Processors
Был бы ооочень благодарен!
а такими темами не увлекались? Software Configurable Processors
К сожалению, что по ссылке я не понял. Поясните? Если что-то типа FPGA, то нет, я с этим знаком поверхностно.
На CUDA интегральное изображение считается из левого верхнего угла в правый нижний, весь процесс разбивается на стадии (слои матрицы вида i+j=C), внутри стадии пиксели считаются независимо. Соответственно, максимальное число тредов, которое можно задействовать, равно min(W,H). Возможно понадобятся атомарные операции для синхронизации стадий. Кстати, не исключаю что можно еще подумать и придумать как порвать барьер на число нитей в min(W,H).
На CUDA интегральное изображение считается из левого верхнего угла в правый нижний, весь процесс разбивается на стадии (слои матрицы вида i+j=C), внутри стадии пиксели считаются независимо. Соответственно, максимальное число тредов, которое можно задействовать, равно min(W,H). Возможно понадобятся атомарные операции для синхронизации стадий. Кстати, не исключаю что можно еще подумать и придумать как порвать барьер на число нитей в min(W,H).
Забыл спросить, а Вы для чего делаете фейсдетекшн на куде? Любопытство =)
это конечно очень интересно, но…
во первых: как мне кажется надо не усиливать клиентские машины, а оптимизировать данный алгоритм
во вторых: написание полноценного саундтрека требует знания в совершенно других областях, таких как, основы композиции и арранжировки) данный алгоритм будет имитировать звуки (например живых инструментов), но никак не писать саундтреки)
во первых: как мне кажется надо не усиливать клиентские машины, а оптимизировать данный алгоритм
во вторых: написание полноценного саундтрека требует знания в совершенно других областях, таких как, основы композиции и арранжировки) данный алгоритм будет имитировать звуки (например живых инструментов), но никак не писать саундтреки)
Интересно, следующим шагом будет генерация запахов?
Прикольно было бы играя в Farcry ощущать запах леса или моря…
Прикольно было бы играя в Farcry ощущать запах леса или моря…
Или запах зомби в L4D.
<a href=«www.3dnews.ru/news/uchshnie_reshili_dobavit_v_igri_zapah/>Вот здесь.
А вообще насколько я помню сделать плату с ограниченным набором запахов уже пробовали во времена riva tnt.
А вообще насколько я помню сделать плату с ограниченным набором запахов уже пробовали во времена riva tnt.
Вот здесь. (извиняюсь)
А вообще насколько я помню сделать плату с ограниченным набором запахов уже пробовали во времена riva tnt.
А вообще насколько я помню сделать плату с ограниченным набором запахов уже пробовали во времена riva tnt.
Работа полезна только с научной точки зрения. Для практического применения (например в игра) не подойдет.
Нужно делать по принципу 3D: вместо куба — полигоны и текстуры плюс простейшее описание физики.
Нужно делать по принципу 3D: вместо куба — полигоны и текстуры плюс простейшее описание физики.
а что, классная тема. А то, я уже думал что звуковым картам некуда рости. Скоро будут SPU в каждой )
Если кому интересно, ролик есть на YouTube: www.youtube.com/watch?v=l95tZCl7YlQ
Создание девяти секунд звука журчащей воды требует четырёх часов работы 20 четырёхядерных процессоров Xeon.
Как же все-таки у людей проще. Создание полутора минут звука журчащей воды требует всего пару литров пива.
Мне кажется что со звуком, в отличие от видео, действительно проще работать «в натуре». Чем испокон веков занимались и занимаются звукооператоры.
Можно ли вообразить э… такой случай, когда рассчет звука был бы дешевле прямой записи? Хотя конечно, можно возразить насчет качества записи, хотя современная аудиоаппаратура имхо уже подошла к фактическому рациональному пределу :-)
Можно ли вообразить э… такой случай, когда рассчет звука был бы дешевле прямой записи? Хотя конечно, можно возразить насчет качества записи, хотя современная аудиоаппаратура имхо уже подошла к фактическому рациональному пределу :-)
ИМХО, насколько я понимаю, дело не в дешевизне — так или иначе либо способ генерации звуков ускорят, либо компы в тысячу раз мощнее станут. Идея такова: в FarCry (просто как пример) при падении осколков от взорвавшейся в воде лодки, если использовать генерацию и расчёт звуков на-лету, а не ограниченное количество записанных сэмплов, то каждый из обломков с учётом его веса, формы и скорости падения будет падать в воду со своим звуком, что не может не добавить реалистичности.
«когда домашние компьютеры достигнут нормальной мощности (то есть станут хотя бы в тысячу раз производительнее, чем сейчас)»
хорошо сказано!
Подумал о применении таких алгоритмов.
Получается их можно использовать в программах, скажем, релаксации, это если с пользой!
А вот если для вреда — представьте соседа, у которого круглосуточно и громко капает вода! И звук не от болгарки, и придраться особо не к чему, а через сутки — трое, если захочется наказать людей, то они точно на стенку полезут…
У каждой новинки есть две стороны медали, и у этой тоже.
Получается их можно использовать в программах, скажем, релаксации, это если с пользой!
А вот если для вреда — представьте соседа, у которого круглосуточно и громко капает вода! И звук не от болгарки, и придраться особо не к чему, а через сутки — трое, если захочется наказать людей, то они точно на стенку полезут…
У каждой новинки есть две стороны медали, и у этой тоже.
Блин, а вот была же у меня мысль, что звуки надо генерить… Если написать толковый звуко-физический движок, то там и до речевых генераторов недалеко:)
Вы бы ещё расчёт ядерных взаимодействий предложили использовать для генерации речи. Гвозди микроскопом забивать, конечно, можно, но дорого и неудобно. Для генерации речи используются (и вполне успешно) совсем другие алгоритмы.
>>Теоретически, когда домашние компьютеры достигнут нормальной мощности
Сейчас Ray-tracing нигде не используется.
Во первых, алгоритмы можно переписать под технологии OpenCL (Cuda).
Во вторых, сами технологии можно упростить до состояния, в котором они будут тянуть на компах.
В третьих, появятся специализированные ускорители (а скорее всего, просто видеокарты смогут это делать).
Так что всё лишь в развитии технологии.
Сейчас Ray-tracing нигде не используется.
Во первых, алгоритмы можно переписать под технологии OpenCL (Cuda).
Во вторых, сами технологии можно упростить до состояния, в котором они будут тянуть на компах.
В третьих, появятся специализированные ускорители (а скорее всего, просто видеокарты смогут это делать).
Так что всё лишь в развитии технологии.
Спасибо. Отличная статья!
По поводу процедурного аудио — у всех существующих программ, которые позволяют реализовывать сложные звуковые модели (PD, CSound, SuperCollider, Max/Msp, NI Reactor и т.п.) есть один очень существенный недостаток — общая регидность и качество звучания модулей. Поэтому, несмотря на то, что можно создать очень детальную и реалистичную модель — звук получается значительно хуже чем ожидается.
В мире синтезаторов основной характер инструмента создаётся фильтрами. Это касается и программных и железных синтезаторов. Тот же Monark от NI, моделирующий звучание аналогового Mini-Moog, хоть и сделан на движке Реактора, но фильтры, переписывались и калибровались с нуля, т.к. со стандартными фильтрами Реактора получить такое звучание невозможно. А смоделировав аутентичные фильтры — получаем требовательный к ресурсам инструмент, который может воссоздавать звучание только одного конкретного синтезатора. А для того, чтобы получить, например, фирменный звук Roland TB-303, нам нужно заново создавать и калибровать модель фильтра.
Поэтому для эффективного развития процедурного аудио (в его текущем направлении) нужно создавать очень много качественных физ. моделей. Не только для фильтров, но для всего. Как например существующие уже физ. модели фортепиано, rhodes, некоторых типов перкуссии и струнных инструментов, где существует математически описанная физ. модель возбудителя (жесткий молоточек, мягкий молоточек, смычок...) и физ. модель тела (цилиндр, конус, пластина, струна...). Такие же модели должны быть созданы для всех вариантов взаимодействия в игре: модели поверхностей (песок, камень, дерево, ткань...), тел (деревянный дом, картонная коробка, металлическая контейнер, лиственный лес...) и т.п. А это уже серьёзное программирование, которое чуждо среднестатистическому звуковому дизайнеру. Равно как чужды понятия, «ламповая теплота», «мягкая сатурация», «реверберация лиственного леса» среднестатистическому программисту :)
По поводу процедурного аудио — у всех существующих программ, которые позволяют реализовывать сложные звуковые модели (PD, CSound, SuperCollider, Max/Msp, NI Reactor и т.п.) есть один очень существенный недостаток — общая регидность и качество звучания модулей. Поэтому, несмотря на то, что можно создать очень детальную и реалистичную модель — звук получается значительно хуже чем ожидается.
В мире синтезаторов основной характер инструмента создаётся фильтрами. Это касается и программных и железных синтезаторов. Тот же Monark от NI, моделирующий звучание аналогового Mini-Moog, хоть и сделан на движке Реактора, но фильтры, переписывались и калибровались с нуля, т.к. со стандартными фильтрами Реактора получить такое звучание невозможно. А смоделировав аутентичные фильтры — получаем требовательный к ресурсам инструмент, который может воссоздавать звучание только одного конкретного синтезатора. А для того, чтобы получить, например, фирменный звук Roland TB-303, нам нужно заново создавать и калибровать модель фильтра.
Поэтому для эффективного развития процедурного аудио (в его текущем направлении) нужно создавать очень много качественных физ. моделей. Не только для фильтров, но для всего. Как например существующие уже физ. модели фортепиано, rhodes, некоторых типов перкуссии и струнных инструментов, где существует математически описанная физ. модель возбудителя (жесткий молоточек, мягкий молоточек, смычок...) и физ. модель тела (цилиндр, конус, пластина, струна...). Такие же модели должны быть созданы для всех вариантов взаимодействия в игре: модели поверхностей (песок, камень, дерево, ткань...), тел (деревянный дом, картонная коробка, металлическая контейнер, лиственный лес...) и т.п. А это уже серьёзное программирование, которое чуждо среднестатистическому звуковому дизайнеру. Равно как чужды понятия, «ламповая теплота», «мягкая сатурация», «реверберация лиственного леса» среднестатистическому программисту :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Компьютерная симуляция звуков воды