DQS1 : многопоточность против 100 кроллегов

Попробовал Bullet в многопоточном режиме (очень хочется физику пошустрее в другом проекте на консоли). Мой любимый стресс-тест — 100 кроллегов; каждый кроллег это rigid-body и капсула коллижна, ну и там ещё на земле несколько десятков кирпичей валяется . 

Вся физика в много-поточном варианте стала занимать ~4ms вместо ~13ms (на P8400@2.4GHz dual-core), притом что parallel solver я включить не рискнул (он в Bullet экспериментальный и, судя по форумным постам, иногда крашится) — пользовал параллельный broad-phase/narrow-phase collision.

Как говориться "халява, сэр" Smile


Последняя правка: сб, 29/10/2011 - 04:58
Submitted by BLK Dragon on

Комментарии

Увеличение производительности - это очень гут Smile 4 миллисекунды - это в статическом состоянии (все стоят, никто ни на кого не натыкается, все упираются "в землю"), или когда кролики отрабатывают коллизии движущимися объектами (летящими в них кирпичами или другими кроликами)?

И в чём, собственно, "халява" ?

P.S.

Кстати, а чем Bullet лучше/хуже тех же Newton Dynamics и ODE ?

Submitted by alkemist on

Если всё будет двигаться, конечно будет побольше 4мс. "Статическое состояние" редко когда бывает, broad-phase всегда отнимает время, плюс ray-test'ы всегда выполняются (по одному на персонажа как минимум).

Халява в том, что (почти) никаких усилий не прилагалось; плюс процы нынче как минимум dual-core, так что оно "само" будет быстрее.

Bullet лучше ODE и Newton тем что он работает. В смысле ODE это просто глючево (из двух предыдущих проектов), Newton тоже не развивается насколько помню.

Submitted by BLK Dragon on

В "само" быстрее чувствуется подвох Lol

А Newton более чем живой и развивается (http://newtondynamics.com/forum/index.php) - и последний релиз за 2011 год. + на нём коммерческие проекты делались (обе пенумбры, если не путаю).

Ode уже да... Smile старый и безнадёжный таки.

Submitted by alkemist on

Bullet вообще-то во многих играх использовался, на консолях особенно (что меня больше волнует). Плюс куча разных физических плагинов под DCC на нём сделано (Maya/XSI/Modo). 

Т.е. конкурировать с Bullet может, по факту,  только Havok (если не брать в расчёт цену).

Submitted by BLK Dragon on

Newton по сравнению с другими физическими движками самый реалистичный, связано с другим способ реализацыи моделирования физ. процессов. Но и соответственно у него меньше производительность из-за этого. В западных лабораториях этот движок очень часто используется для обкатки разного рода моделей на компе, прежде чем изготовлять опытные образцы. ОДЕ не особо и глючный, но в нем надо много писать ручками, чтобы добиться нормальных результатов. А Bullet я слышл в ГТА 4 вроде использовался. Все хотелось им побаловаться, но руки так и не дошли.

Submitted by Otinagi on
Quote:

ОДЕ не особо и глючный

Seriously? Я вот года два назад на PSP игру с ним делал — после этого никакого желания это глючево пользовать нету.

А в GTA IV юзали Havok/Euphoria. На самом деле в "настоящих" играх, статистичеки, юзают или Havok (если нужно чтоб работало без лишних приключений) или PhysX (по каким-то непонятным мне приичинах); ну или Bullet если нету мега-бюджета.

Submitted by BLK Dragon on

Ну, у меня глюки возникали с ОДЕ только из-за моих кривых рук. Когда все толково сделал - все нормально шло. Но чтобы это все толково сделать - времени надо прилично (:

В ГТА 4 точно юзали этот двиг: http://ru.wikipedia.org/wiki/Bullet. А Эйфория вродее вообще не физ. движок. Это просто метод смешения анимацый. Ну, по крайней мере в ГТА 4 Эйфорию использовали только для этих целей.

А что касается ФизИкс, то лично я думаю, что его используют только из-за того, что он в свое время был единственным движком, обрабатывающым физику на видеокарте, что есть очень круто. Сейчас не знаю - может уже и др. движки так же делают. Я говорю про ПС версии, а не для приставок. В приставках вообще не знаю что на чем обрабатывается (=

Submitted by Otinagi on

Bullet в GTA используется частично, т.е. какие-то части самописной физики в какой-то момент времени Rockstar заменили на Bullet плюс кое-что своё дописали (как раз с утра общался на тему).

У тебя особых глюков с ODE не было, потому что не нужно было шипить консольную игру Smile А так у ODE всю дорогу проблемы со стабильностью (вычислений), особенно на низком FPS (15-20); joint'ы ragdoll'ов, например, рвёт только в путь (т.н. абсолютно жёсткие джоинты которые по идее не должны рваться в принципе).

Вопрос про PhysX был риторический — с год назад там были не только тормоза на PS3/X360 а ещё и crash-bug'и, что никак не радовало. Про "Эйфория просто метод смешения анимаций" не смешно — это и не просто и не метод смешения анимаций. Читай википедии (или что там) внимательнее Smile

Обрабатывать физику на видеокарте нифига не круто — видеокарта бедная чуть успевает отрисовать картинку. Это ещё в первых демках PhysX (ну тех где "физический ускоритель" рекламировался) веселило, типа ну насимулировали вы кучу мусора, так это всё ещё и нарендерить нужно а мощи нет Smile

Submitted by BLK Dragon on

"это и не просто и не метод смешения анимаций" - поясните. Суть эйфории была в том, чтобы достраивать перемещения костей между двумя созданными заранее анимацыями. Типичная процедурная анимацыя. Чем не смешение? Ну, я опять же говорю про ГТА4. А Буллет там да, использовался частично. Разрабы говорили, что он там использовался для просчета выстрелов.

Не совсем согласен про обработку физики на видео карте. Видео карты достаточно производительные, и именно поэтому на них стали перелажывать огромное количество функцый, чтобы разгрузить процессор, который вот, кстати, уже и не посвепает за всем, учытывая как много надо проделать действий для фонового мира (чтобы птички правильно летали, чтобы НПС пошел покакать в нужный момент и т.д. и т.п.). Это не мое личное мнение, а мнение разработчыков игрушек. Но я с ним полностью согласен.

С ОДЕ согласен. Я писал только под ПС и наверное поэтому там не было особых глюков. Хотя опять же повторю, изначально, пока не разобрался, было оооооогромное количество проблем, за что и невзлюбил этот движок.

Submitted by Otinagi on

Про Euphoria лучше почитать на сайте разработчика, слишком долго объяснять.

Про физику на GPU ты можешь быть сколько угодно не согласен, но реальность такова что оно больше всего нужно производителям видеокарт -- чтобы побольше этих карт продать. Marketing bullshit, короче.

Submitted by BLK Dragon on

2 BLK Dragon

А CUDA Вам на что? Специально же архитектура разрабатывалась для доп. вычислений на видеокартах. А идёт всё просто к наращению мощности адаптеров и увеличению производительности. Противиться этому - всё равно что говорить "многоядерные CPU - marketing bullshit", в то время как make -j3 (для двуядерных) в больших проектах говорит обратное Wink

Раз это относительно новая технология (5 лет, ага), использовать её надо чуть осторожнее и бить по рукам быдлокодеров, которые делают non-renderable графику и non-computable физику Smile

Параллельные вычисления must have. И не только в сфере разработки игр.

Да, и кстати, при чём тут вообще физика? Smile Ведь "реальность такова", что у нас есть технология, позволяющая получать доступ к вычислениям на GPU, а как это использовать - это уже наше дело (тот же PhysX может лезть с вычислениями в GPU, а может и не лезть).

То, что это даёт прирост выч. мощности - факт. И от этого никуда не денешься.

Submitted by alkemist on
Quote:

А CUDA Вам на что?

Мне лично она нахрен не сдалась, разве что для тулзов на пейси (да и то я бы предпочёл обычный multi-core CPU или SPU — во избежание потенциальных странных глюков).

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

 

Submitted by BLK Dragon on

Это все, конечно, круто, но у меня возник вопрос (не сочтите за троллинг): а надо ли вообще в вашей игре какой-либо физический движок?! Не знаю, конечно, пролноты вашых планов, но вспоминая некогда выложыную демку с уверенностью могу сказать, что никаких физических движков абсолютно не надо. Все куда быстрее будет работать, если делать ручками. Расчытывать столкновения с шариками/кубиками - это намного менее ресурсоемко, чем любой из физ движков. Тем более, что не так уж и сложно с точки зрения реализацыи. Сам лично делал подобные проверки в игре. 20 домиков, с физ моделью куба, 11 танков с физ моделями двух кубов и каждый из них стреляет и катается - это конечно не сто юнитов, но на селероне 733 шло без каких-либо педалей и в одном потоке. А учытывая многоядерность современных комповых и приставочных процессоров - гонять свою физику в другом потоке - не такая уж и сложная затея. Ну, или как вариант, использовать физ. движок только для проверки столкновений (хотя, наверное, вы это и делаете). Но это если уже использовать какие-либо сложные коллижн-модели, а не шарики-кубики.

Просто, физика раельно нужна там, где нужна физика.

Submitted by Otinagi on
Quote:

Это все, конечно, круто, но у меня возник вопрос (не сочтите за троллинг): а надо ли вообще в вашей игре какой-либо физический движок?! Не знаю, конечно, пролноты вашых планов, но вспоминая некогда выложыную демку с уверенностью могу сказать, что никаких физических движков абсолютно не надо.

Эта уверенность ровно до того момента как сам начнёшь это реализовывать. А тогда высниться, что быстрый коллижн с trimesh'ем на коленке не напишешь, ray-cast'ы точно так же на коленке не напишещь, locomotion персонажа выглядит гораздо приятнее когда всё на силах/импульсах и т.д. и т.п.

И потом обычно в мире не 20 танчиков, а 200 — без broad-phase и прочих ухищрений всё уже не так быстро и просто.

Submitted by BLK Dragon on

Ну, я сам это впринцыпе и реализовывал. Но с многополигональными модельками согласен, там все сложно это самому прописать. Просто я так понял, что здесь вы использовали шарики (капсулы, собственно, можно заменить теми же самыми шариками) в качестве для физической модели объекта. На счет приятности - не знаю. Я всегда старался избегать физических движков там, где это можно сделать. В том же самом шутере я использовал физ. двиг только когда мир был полон динамических объектов (ящыки, бочки, ..). А когда мир вцелом был статический, то всю жывность обрабатывал без всяких движков, используя только коллижаны. Но это так, к размышлению. Для меня всегда были интересны все эти физические модели, так как это достаточно серьезная вещь в 3Д играх, и очень сложная. Собственно, в данный момент пишу игру, и все думаю какую физику и в какой мере её использовать. Правда, выбор у меня не столь большой: ручки, ОДЕ или Ньютон. И пока что в каждом методе вижу свои плюсы и минусы, и в сумме они все равнозначные )=

Submitted by Otinagi on
Quote:

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

Персонажи почти всегда почти везде задаются цилиндром или капсулой, это просто удобно по многим причинам. Всякие штуки посложнее (топоры и дубины выпадающие из лап поверженных врагов) задаются несколькими shape'ами — обычно комбинация бокса и капсулы, так натуральнее выглядит в движении.

Вообще достаточно наивно считать что самописная физика/колижн равнозначна даже ODE. Например, банальный триггер можно конечно и вручную считать колижн со всеми кто в него может зайти, но в реальности нужно использовать phantom (ghost-object), иначе на настоящих уровнях (где триггеров и акторов десятки и сотни) будут нехилые тормоза.

И опять же, меня не интересуют подходы для "писать", интересны решения для "написать" — это две большие разницы Smile

Submitted by BLK Dragon on

Ну, вот проверки с шариками кубиками у меня работают вручную быстрее чем я буду проверять столкновение шариков-кубиков с помощью движков. Проверено. С другой стороны на совеременых компах такой прирост проиводительности не заметен, а вот на старом добром селероне ОДЕ выдывал абсолютно неиграбельный ФПС. Думаю, для мобилок это тоже актуально.

А что касается настоящых уровней, то не думаю, что сувать сразу всю сотню тригеров - это правильный тон. По крайней мере я разбиваю карту на логические участки в которых обрабатывается не такое уж и большое количество объектов/тригеров и пр. Точно так же, как и карту целиком не гружу для отображения и для просчета физики. Если сразу все грузить - тут точно никаких ресурсов не хватит (:

Собственно, такими ухищерениями я и добивался нормального ФПС. Хотя, играя в те мои проекты на современном 4ехядерном процессоре, половину кода точно можно выкинуть (((=

Submitted by Otinagi on
Quote:

Ну, вот проверки с шариками кубиками у меня работают вручную быстрее чем я буду проверять столкновение шариков-кубиков с помощью движков. Проверено.

Чисто из вредности, пруфлинк? Ну т.е. сотня боксов, брошенная на плоскость (лучше на тримеш) — время коллижна на кадр в миллисекундах "вручную" против ОДЕ (или чего-то более вменяемого).  Причём именно сотня-другая — это чтоб даже на современном CPU перебор всех объектов без broad-phase убил всё насмерть.

Понятно что сотня триггеров вряд ли будет активна сразу, но если на уровне лежит 1000 объектов "мусора", то десятка три из них всегда активна (и на самом деле нужно что-то делать с теми, что сейчас далеко/не-видны). И, очевидно, никто не считает весь физический мир целиком а только то что рядом с игроком.

Submitted by BLK Dragon on

Пруфлинк, босюсь, не подкину. Чысто из вредности он не находит ОпенГЛ 1.1 + не работает на ATI-видюхах, а перекомпиляцыя проекта под новый движок (я на GLScene писал) - с этим надо повозиться. Насчет кидания боксов на поверхность я согласен - физ двиг быстрее сработает. Но это немного отстраненный пример. Я ведь говорил не про реализацыю физики, а про банальную проверку столкновения с последующым решением куда идти персонажу. Как это в обычных аркадках делается, где не надо рискидывать в стороны кубики, шарики и все такое. Где мир представляет из себя статику, а по нему двигаются ГГ и монстрики. Ну, собственно такую модель представляли и те мои танчыки, и нечто подобное я видел в вашей демке про этого милого дракончыка. Просто вот посудите сами - перебрать все обекты и проверить, к примеру, не пересекается ли радиусы сфер объектов куда быстрее, чем это сделано в физ движках, где такая же банальная проверка радиусов, но с доп навеской всяких масс, инерцый, трений, бла-бла-бла (не исконно моя мысль, а совет одного из текущых разрабов GLScene). И, конечно, если мир там жудко сложный, то тут никакие руки не помогут нормально все сделать без физ движка. И это ж так, просто, мысли вслух, я ж ни в коем разе не отговариваю вас от использования выбранного движка (: Это классно, когда человек действительно осознанно выбрал то, что использует, осмысленно откинув все другие методы.

Submitted by Otinagi on
Quote:

Просто вот посудите сами - перебрать все обекты и проверить, к примеру, не пересекается ли радиусы сфер объектов куда быстрее, чем это сделано в физ движках, где такая же банальная проверка радиусов, но с доп навеской всяких масс, инерцый, трений, бла-бла-бла 

Весьма неправильное представление о том, как работает collision и физика. "Просто перебрать" будет НЕ быстрее, ключевые слова для поиска "broad phase collision".

Пример с боксами ни разу не отстранённый — на уровнях с руинами у нас как раз будут раскиданы всякие кирпичи и камни, много.

Submitted by BLK Dragon on

GameDev.by