![]() |
Ответ: Russian Sound System
Цитата:
Возможно имеет место дифракция... Может быть ее можно реализовать таким способом: сделать 2 бокса, один внутри другого, если луч будет идти через угол и проходить только через внешний бокс значит имеет место дифракция. Возможно автор уже читал, но вот пользователям движка может пригодиться http://www.ixbt.com/multimedia/sound...mes-2003.shtml. Несмотря на 2003 год видимо это до сих пор актуально ( может быть это из-за консолей ? ). Другое дело что в демке действительно странный звук: такое ощущение что сначала срабатывает обстакл, громкость и ВЧ звука снижаются, и только затем к ним применяется эхо или реверберация. Вобщем почему-то эхо заметно приглушается вместе с обстаклом, а не должно. Ведь я так понял движок не настолько сложный, что может к сначала отраженному звуку еще и обстакл применять, для этого слишком много трассировок нужно. По поводу зон: я правильно из контекста понимаю что тут именно AABB а не просто BB? Если это так, то данная реализация бесполезна. На открытых пространствах зоны применять негде, а вот для комнат они бы подошли - комнаты обычно действительно с прямыми углами, но далеко не всегда выровнены по мировым осям, так что однозначно нужны просто BB. Тоже самое относится к обстаклам, там даже можно сделать поддержку мешей. Разработчики игр могут использовать для обстакла теже упрощенные меши что делают для физики. Цитата:
|
Ответ: Russian Sound System
Чую я, что надо запиливать wavetracing\raycasting. Все эти выкрутасы с AABB и просто BB ни к чему не приведут.
На гамедеве.нет мне один чувак кинул ссыль на свой университетский проект. http://gamma.cs.unc.edu/GSOUND/ |
Ответ: Russian Sound System
В общем. Я начал пилить движок.
За недельку запилил простенький DSP( digital signal processing, цифровая обработка сигналов ). Что поддерживается? 1) Вывод звука через directsound - просто вывод во вторичный буфер, без использования фич directsound'a. 2) Программное микширование. 3) Изменение частоты воспроизведения( pitching ) 4) Загрузка ogg, wav. 5) Панорамирование ( баланс между левым и правым динамиком ) 6) Изменение громкости 7) Фильтрация - перестраиваемый ФНЧ ( фильтр низких частот ) - программно регулируем частоту отсечки - от 50 Гц до 21000 Гц Архитектура такова. Звуковой буфер с PCM -> Звук 1 -> Микшер -> DirectSound ________________________...... -> ______________________Звук n -> Кому интересно могу скинуть демку. |
Ответ: Russian Sound System
Цитата:
|
Ответ: Russian Sound System
http://rghost.ru/46109904
исходник "движка" в комплекте. выпилил пока поддержку ogg откомпиль сам, и сможешь поиграться с микшером и фильтрами и всем что есть кароч |
Ответ: Russian Sound System
Ну нормально работает, только я немного изменил чтобы на gcc скомпилировать. Хотя латентность большая, нажимаешь кнопку - ничего не происходит, а потом параметр сразу меняется на большое значение. А еще через некоторое время сбрасывается в дефолт.
Получается ты будешь все программно реализовывать? А нужно ли велосипед изобретать? Тем более аппаратное ускорение ( если оно доступно ) тоже важно. К тому же если будет привязка в dsound то как же переносимость? Мне кажется правильным решением будет работать поверх OpenAL, а специфические механизмы трассировки реализовать отдельным софтварным модулем ( с поддержкой simd можно ). |
Ответ: Russian Sound System
Цитата:
http://rghost.ru/46145531 Цитата:
Привязки к dsound не будет. Для линукса будет свой SoundOutputDevice. Если не сложно - кинь пару статей по звуку в линуксе. Я только начал изучать программную обработку звука и не хочу останавливаться. Насчет велосипеда. Такой велик очень большая редкость. Это не графический двиг, который пилит каждый кому не лень. Работа поверх OAL дикий оверхед. Так что нет спасибо. |
Ответ: Russian Sound System
Все проблемы с DSP подчищены.
Запилил объемный звук ( то бишь 3Д!!!!111адинадин). Появился соответственно класс - слушатель( listener ). Демку планирую сделать к выходным. Но обещать не могу ибо - СЕССИЯ БЛИЗКО! |
Ответ: Russian Sound System
Попробовал интегрировать коды звукового движка в одно 3д приложение - не особо здорово.
Во первых неудобно то что mixSound нужно вызывать непрерывно, в то время как логично его обновлять каждую итерацию (например каждый кадр). Во вторых через каждые полсекунды-секунду (видимо когда происходит обновление буфера) приложение застревает. Тоже не круто. В общем то оба неудобство можно исправить если вынести звук в отдельный поток, но имхо лучше сначала найти способ более плавного кода без усложнения многопоточностью. Есть кстати какие-нибудь наработки с последнего релиза? |
Ответ: Russian Sound System
Цитата:
|
Ответ: Russian Sound System
Цитата:
Мне вообще самому интересно насчет возможностей софтварного звука. Посмотрю чего тут можно сделать. Есть например идея насчёт HDR звука. |
Ответ: Russian Sound System
Короче удалось более менее настроить - рывков нету, работает довольно плавно 40fps на одном ядре (без звука приложение 45fps дает).
Значит что я сделал: * Размер вторичного буфера сократил до 100мс, то есть каждые 50мс он догружает новые данные. * Микшер я сделал так что он обрабатывает данные порционно, например при 60fps (17мс на каждый кадр) блок в 50мс проигрывается в течении 3 кадров. Для блока в 50мс нужно обработать ( 44100 * 2канала / 20 ) семплов и это кол-во делиться на 3 и в каждый кадр вызывается функция микшера которая обрабатывает 1/3 от этого блока, и на третий раз она вызывает запись в буфер устройства. * Таким образом теперь лучше заточено под вызов обработки микшера в каждом кадре. На что следует обратить внимание: * Во первых основная проблема - латентность. Возникает из-за того что микшер находится до самого устройства вывода. То есть мы не можем сначала загрузить звук в буферы, а затем в любое время смикшировать и вывести. И если например в случае музыки всё предсказуемо, то например нельзя наперёд знать когда игрок выстрелит или сделает другое действие требующее звукового сопровождения. С другой стороны создание слишком маленького буфера требует очень частого его обновления и получается что сама пересылка данных и потери в интервалах между вызовами функции обновления (в каждом кадре) занимает больше времени чем проигрывание этого мелкого буфера. Я примерно подобрал оптимальное значение - 100мс. При низком fps (< 30)всё равно начинаются проблемы, но это можно исправить вынеся звук в отдельный поток. * Второе это собственно многопоточность - как ни крути она должна здесь быть, потому что даже мелкомягкие так рекомендуют делать. Воспроизведение звука в отличии например от вывода графики рассматривается как внешнее действие, а значит должен существовать поток который должен его контролировать (также как это делают для сети или когда хотят сделать нелагающий курсор мыши). * Третье это собственно скорость микшера. Потому что имхо: раз у нас софтварный микшер значит нам доступен весь объем рамы, а это значит что мы не связаны ограниченным набором звуков которые можно воспроизвести без подгрузки в буфер, и как следствие преимущество должно быть в богатом и разнообразном звуковом сопровождении, но для этого нужен быстрый микшер. Вот. |
Ответ: Russian Sound System
Вложений: 1
В аттаче исходники последней версии с попыткой сделать реверберацию "в лоб" ( давно это было ). При воспроизведении звука создаются дополнительные источники. Из источника звука кидаются лучи в рандомном направлении. Вычисляется задержка для каждого дополнительного источника = расстояние_до_точки_пересечения / скорость_звука. Вот тут основной косяк как и с физикой в буллете( из-за него объекты как невесомые ) - нужно иметь меши с размерами в метрах - разумные размеры то есть. Метод "в лоб" работает - но довольно медленно естественно. Еще в движке косяк с амплитудой складываемых звуков - при куче вопроизводимых звуков появляется хрип - амплитуда завышена и обрезается.
|
Ответ: Russian Sound System
Ок.
Я в общем то на mingw собираю поэтому мне приходится код переписывать местами, но я заодно его подробно разбираю. Перенес микшер новый с потоками - намного лучше. fps по моему совсем не падает, и второй поток особо на нагружается. Цитата:
Так вот там в кодах инициализируется первичный буфер dsound - он вроде нигде не нужен. Есть код где не освобождены некоторые интерфейсы и кое-где пропущены delete на соответствующие new. ExitThread для С++ вроде не нужен - он для С. С 3д и реверберацией пока не разбирался - мне нужно своё приложение доделать чтобы была возможность получать доступ к мешам, чтобы было на чем проверять. |
Ответ: Russian Sound System
Цитата:
Но код слиииишком сложный и навороченный, хотя может ты и разберешься. К читабельному виду его можно привести только этой тулзой - AStyle |
Ответ: Russian Sound System
Я пока разбираю твои коды, ничего нового не добавлял - мне нужно понять то что уже есть. Я думаю еще 1-2 дня нужно.
Цитата:
А также ещё пачка репортов: * Макросы IS_SHORT_EVEN и IS_SHORT_NOT_EVEN по моему ты местами перепутал, ведь num & 1 даёт true для нечёта. * Также ты используешь abs в расчётах с float, но abs округляет до целого числа - нужно использовать fabs из cmath. * Еще я заметил что в Sound::getSamples теперь currentSample сначала преобразовывается к целому числу и затем определяется чёт/нечёт, это я так понял сделано специально для того чтобы плавающий pitch не сдвигал выборку на один семпл в противоположные каналы? В общем будет неплохо если поделишься статьями и материалами (кроме msdn), которыми ты руководствовался когда все это делал, чтобы у меня был примерно такой же ход мыслей для лучшего понимания. Цитата:
Коды глянул - как будто чел прогал на шарпе, эти методы размером больше экрана прямо инлайном вбивались. Оформление отвратительное. Тут конечно каждому свое, может кто то любит чтобы за него всякие AStyle'ы делали. Я же привык все сам форматировать. То что касается твоего двига: целесообразно уже С++11 использовать, а также std - в 11 там всё отлично. И поменьше юзать расширения msvs - ведь потом проблемы с переносом будут (но и не делать всё универсально - в msvs есть свои плюшки). Я взял за основу конвенцию кодирования idSoftware и доработал под свои требования - стараюсь её придерживаться - вот она (ru/en, en - обычно свежее). Посмотрим как дальше пойдет, если двиг будет перспективный (какие у тебя планы то? блиц3д в том числе?) то можно в репозиторий залить. |
Ответ: Russian Sound System
Цитата:
Цитата:
Цитата:
DSP for braindead Цитата:
|
Ответ: Russian Sound System
С твоими кодами более-менее разобрался.
Реверберация работает. Однако, мне кажется архитектура не удачна (видимо делалось в спешке) - например класс Sound я щитаю не должен отвечать за свои копии звуков в эхо, должен быть какой то общий класс (например сцена) который создает/управляет/перемещает звуки в зависимости от ситуации и событий в сцене. Надо определить что требуется звуковому движку, чтобы примерно понять как это разместить в архитектуре. Пока еще поразмышляю над архитектурой и попробую демки пособирать чтобы было понятно как лучше использовать. Ну я потом напишу когда реверберацию начну делать. DSP for braindead по ходу читаю. Кстати мелкомягкие уже забили на dsound - рекомендуется например xaudio2 - я думаю нужно посмотреть, может там тоже можно без оверхеда делать. |
Ответ: Russian Sound System
Цитата:
|
Ответ: Russian Sound System
Решил поискать литературу по обработке звука( в т.ч. реверберации ) и нашел довольно годный учебник
PHYSICAL AUDIO SIGNAL PROCESSING |
Ответ: Russian Sound System
Почти уверен, что чел, делающий GSound, понятия не имел обо всём этом что в книге.
Можно использовать как справочник. К тому же сначала нужно попробовать очевидные методы. Например как можно посчитать реверберацию: * кидаем лучи от источника звука, к каждому центру триса геометрии; * кидаем лучи от слушателя к каждому центру триса геометрии; * если лучи проходят и если оба луча не обратны нормали триса значит отражённый звук прошел; * чтобы посчитать его громкость нужно взять коэффициент отражения и умножить на площадь триса и на косинусы углов лучей к нормали; * чтобы посчитать задержку нужно сложить длины двух лучей; В целом такой алгоритм вроде должен работать, при условии что размеры трисов несколько меньше чем длины лучей и размеров препятствий; В случае больших трисов будут проблемы: * например препятствие загораживает только центр триса, однако он сам такой большой что звук должен проходить - тут нужно кидать дополнительные лучи (рэндомно или по краям триса); * если слушатель и источник находятся рядом друг к другу и близко к очень большому трису, например длинной стене, понятно что отражаться будет только от той части триса которая рядом, а не от всего триса; Так что в таких случаях придется искать другие алгоритмы или тесселировать геометрию. ЗЫЖ готовлю демку, пока в ней ничего нового по части звука нет - будет проверяться просто работоспособность моего игрового движка и интеграции звука в него (с игровым куда больше проблем чем со звуковым:-)). |
Ответ: Russian Sound System
Сдул пыль с движка и пофиксил те баги, которые ты указал + оптимизации мелкие. В общем продолжил его писать.
Если оставить расчет реверберации в движке как есть( именно принцип ), то сразу возникает вопрос - а не слишком ли накладно создавать копии источника звука в местах пересечения лучей с геометрией( именно так сейчас и сделано ). Сейчас в двиге на каждый пространственный источник приходится максимум 32 источника отраженного звука. Даже если сделать искусственное ограничение на количество звуков - например 256, то получается что в микшере будет находиться аж 32 * 256 = 8192 источника и если посмотреть на функцию GetSamples то ситуация кажется унылой - просто дохерища расчетов. Может это и лечится SIMD и распараллеливанием, но мне кажется такой подход слишком избыточным, хотя и правдивым с точки зрения физики. Так же сей метод позволит учитывать дифракцию( огибание препятствий ). В итоге ситуация либо либо. Насчет GSound. Таки этот двиг - дипломный проект этого чувака. |
Ответ: Russian Sound System
Еще один баг здесь:
Код:
ulong leftSampleIndex = IS_SHORT_NOT_EVEN( sampleNumber ) ? sampleNumber : sampleNumber + 1; Вот как у меня: Код:
const uint32_t leftSampleIndex = ( sampleNumber & 1 ) ? sampleNumber + 1 : sampleNumber; //==================================== 8192 звучит пугающе. Особенно если учесть что дискретизация 44кГц, а не 60fps как если бы графику считали. Однако 256 источников это чересчур, в игре в среднем 8-16 одновременно работающих в пространстве. Может быть в стратегиях или каких-нибудь arma их больше, но там нету такой качественной обработки. Получается 16 * 32 * 44100 = 22,579,200 вызовов микшера за секунду. Если бы обсчёт был на шейдерах то вполне потянуло бы, на цпу (без интегрированного гпу) скорей всего нет. Однако нужно прежде всего сделать демку чтобы было от чего отталкиваться и примерно понимать насколько надо ускорить вычисления. С другой стороны у меня же работал 1 источник с 32 кратным эхо и это грузило одно ядро меньше чем на половину, simd теоретически дает 4х в 32битном и 8х в 64битном приложении, на практике скорей будет в 3 и 6 раз быстрей. Так что вроде как в одно ядро может с десяток источников влезть. К тому же например можно применять всякие хитрости, например если взять игру, разных типов источников не так уж и много, но бывает много однотипных источников, например падающие гильзы звенят. Их можно обрабатывать группой, например проигрывать звук каждой без эхо, а эхо добавить общее для всей группы - там на слух не разберешь какая из них звенит. И так далее, можно группировать по типу звука, по локализации, по громкости и т. д. и т. п. |
Ответ: Russian Sound System
Очень хорошее подспорье - исходники OpenAL.
http://rghost.ru/53096581 - для винды http://rghost.ru/53096728 - софтварный рендеринг - там есть alcReverb.c - просто подарок там есть и функция микширования программного - alu.c |
Ответ: Russian Sound System
___rayine_sound_demo___ :sarcastic_hand:
//========================================== А внутри: build_echo - демо с одним 3д источником в центре комнаты и случайной реверберацией; build_music - демо со стерео музыкой; source - исходники rayine; //========================================== Короче ничего нового тут нет! :lol: У меня с игровым движком неисчерпаемые траблы - там надо делать, переделывать и доделывать. Это не быстро. Так что звук меня немного подождет - пока подумай как дальше. Например мы можем каждый свою версию делать обмениваясь логикой алгоритмов, а затем смотреть что у кого лучше и объединять, или мы можем сразу делать общий код, но тогда давай создавай репозиторий и конвенцию кодирования (можешь ту что я кидал раньше, если устраивает). Думаю когда зачищю баги то соберу тест с 32 источниками звука и реверберацией. |
Ответ: Russian Sound System
Суть такова. PHYSICAL AUDIO SIGNAL PROCESSING - потратил 5 дней на чтение. И получил очень хорошие результаты. Использовать в движке нужно обычный программный ревербератор + эхо. С ревербератором разобрался - благо есть STK, а там очень понятный код. STK опять же от той же конторы что и книга выше.
В EAX используется три вида ревербераторов - для ранних отражений, для поздних, и для эхо + модулятор выходного сигнала. У меня пока один - для ранних отражений. А вот raycasting нужен для определения параметров ревербераторов + генератора эхо. Кидаем лучи во все стороны от источника - определяем объем помещения, подкручиваем параметры ревербератора и вуаля, звук просто персик. В итоге материала по реверберации оказалось предостаточно - как обычно плохо искал :-D Код пока выкладывать не буду. И демку тоже. Нужно допилить интерфейсы ко всем компонентам и собрать технодемку. |
Ответ: Russian Sound System
А можно например разделить на два модуля: рейкастинг и ревербератор?
Например сначала рейкастинг считает всё что связано с помещением, затем если есть аппаратная поддержка EAX, EFX то пользуемся ей, если нет то используем программный аналог? Кстати есть же программные эмуляторы eax и нужно посмотреть чем самодельный аналог будет лучше. |
Ответ: Russian Sound System
Цитата:
Цитата:
Цитата:
|
Ответ: Russian Sound System
Вложений: 1
Цитата:
А так наконец-то сделал годный ревербератор с настройками и преферансом. Демка на файлообменнике, а исходники для особо страждущих в аттаче. Насчет реверберации методом рейкастинга тут написано что это дохлый номер - слишком много вычислений. Цитата:
|
Ответ: Russian Sound System
Когда попытался перенести спейсом звук в центр большого зала - звук пропал весь.
|
Ответ: Russian Sound System
Странно у меня ни разу такого не было. А с производительностью как? В демке 6 источников звука, у каждого по своему ревербератору. На моем процессоре( 4 ядра по 2.8 ГГц ) рывков в звуке не слышно.
Далее нужно для ревербератора сделать стерео выход - без него не особо хороший результат. + Добавить декореллятор между каждым фазовым фильтром - он будет обеспечивать вибрато. |
Ответ: Russian Sound System
У меня примерно такой же проц, c бустом 3 ггц, рывков не слышно.
У старого движка были проблемы когда источник звука быстро менял свое положение, например при быстром повороте камеры/головы - там был слышен резкий переход, похожий на лаг. Вот в новом вроде такого нет. Я еще коды буду смотреть. У тебя в старых были ошибки. Я их через dr.memory и checkcpp прогнал - там были проблемы с неинициализированными переменными и с утечками памяти. Но если ты в msvs делаешь там наверное свои средства есть. Я сейчас как раз 2013 осматриваю - особенно графическая отладка радует, пошаговая отладка шейдеров, где можно историю каждого пикселя посмотреть и реверсировать все его действия, реально мощная штука. Жалко что неработает с d3d9 - нужно переносить на api dx11, но например включить feature level 9.1 если железо не совместимо. |
Ответ: Russian Sound System
|
Ответ: Russian Sound System
Цитата:
|
Ответ: Russian Sound System
Решил потренироваться с SSE, пока отдыхаю от разработки игры. В общем перевел почти все критичные по скорости места на SSE1 - пока только SSE1 освоил, и нужды в инструкция с других версий не возникало.
В общем по ссылке демка, потестируйте. Напишите здесь результаты, сколько микросекунд занимает "рендер" в разных режимах. И конфиг компа. Особенно интересуют всякие говнопроцессоры типа Intel Atom и прочих. Например у меня при CPU 4 @ 2.8 ГГц и включенном одном звуке( музыка ) рендер занимает: SSE, Effects on = 485 mcs. SSE, Effects off = 54 mcs(!) Scalar, Effects on = 1602 mcs Scalar, Effects off = 1089 mcs Как видно, использование SSE дает минимум троекратный выигрыш в скорости. СКАЧАТЬ |
Ответ: Russian Sound System
Пропорции абсолютно такие же, только быстрее в 2-3 раза.
i5-4570 @ 3.20 |
Ответ: Russian Sound System
Покажешь примеры кода до и после SSE?
Я, в основном, с SSE2 интринсиками работал - векторную математику ускорял. Интересно, как у тебя применение SSE1 выглядит. |
Ответ: Russian Sound System
Вложений: 1
Я из <xmmintrin.h> интринсики брал. В <еmmintrin.h> интринсики для SSE2 насколько я знаю. Код в аттаче - С++11.
Там есть разные варианты функций\методов с приставкой SSE - это с SSE(sic!). Основное это RenderContext.cpp Не ручаюсь за 100% правильное использование SSE инструкций, но тесты говорят за себя. |
Ответ: Russian Sound System
"Unable to set graphics mode"
|
Ответ: Russian Sound System
хм, так я тоже юзал xmm и _m128 тип. что-то я уже запутался, где ссе1, а где 2 )
у меня тоже буст давало хороший. а в sse4 есть дот продукт за 1 инструкцию, в ссе2 он немного неуклюже делается. |
Ответ: Russian Sound System
Вложений: 1
Цитата:
Цитата:
|
Ответ: Russian Sound System
В тесте есть где-то ошибка,
сначала при SSE и эффектах время - 300 без SSE уже - 8000 обратно включаем SSE - 9000 переключаем несколько раз туда-сюда - ошибка и программа закрывается. Похоже повторное включение SSE не работает. Или ещё что-то. |
Ответ: Russian Sound System
Видимо ошибка где-то в синхронизации потоков, у меня рендер работает в одном потоке, а блиц в другом. Странно все это, буду искать проблему в общем.
|
Ответ: Russian Sound System
Еще немного поколдовал над кодом, и ускорил рендер в 7(!) раз. Играет только один звук - SSE - 235 мкс, Scalar - 1680 мкс. Демку скину когда стабильной работы добьюсь. Каждый звук добавляет 34 мкс на моем процессоре. Впринципе очень шустро работает.
32 звука отжирают 1292 мкс. Это около 773 "кадров в секунду" |
Часовой пояс GMT +4, время: 18:43. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Перевод: zCarot