Войти
ПроектыФорумСобираю команду

Life is Feudal Sandbox MMORPG. Ищем тестировщика. (39 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 138 39 40 4143 Следующая »
#570
16:35, 10 окт. 2014

> Да ландшафт загенерил огромным + стандартный character controller + коллайдер капсула.
TrashCoder, можно всё же какие-то конкретные цифры? Сколько чаров, они стоят на месте или движутся, сколько объектов, какой полигональности и размеров они, какого размера и сколько поликов ландшафт, есть ли НПЦ, коллайдятся ли он с персами, сколько тиков в сек считает сервер?
Если это был просто тест - можно ли посмотреть проект (код)?

У меня интерес не праздный вовсе - мы сейчас занимаемся в своём проекте реализацией как раз в т.ч. физики на сервере и было бы очень интересно получить эту информацию, т.к. у нас пока всё далеко не так утешительно...


#571
16:46, 10 окт. 2014

Suslik

Правило - это, конечно, хорошо, но я вот персонально думаю, что людей, которые нарочно создают
некомфортные условия для существования других форумчан, надо банить безо всяких обращений.
Вот пример.
Dmitry10 вышел из бани только вчера, а уже сколько успел громких слов сказать, притом безо всяких провокаций.
Я пытался нормально общаться, но он в каждый ответ вставлял что-то вроде:
> Тут люди ещё даже близко не доросли до того, чтобы использовать GPGPU вычисления
> на расчёты вероятностей, хотя вряд ли, если ты понимаешь вообще, что это такое.
> а зачем игрокам АИ, или предполагается, что у тех, кто играет в LiF своего нет?
> Это же всё, что я пишу, стандартный комплект по раскрутке всякого мусора.
> Это здесь Бобик и ко строят из себя белых и пушистых, что типа они свою игру не раскручивают, что от этого мусора все сами собой балдеют.
короче я запарился искать и писать, итак всё больмень видно.

Я не ТС, но мне интересен этот топик, и хочется, чтобы людям, которые туда заходят по делу поговорить, не приходилось
пробираться через гору мусора, которую джимник создаёт.
Я считаю, что в случае откровенного абьюза обыкновенных правил морали можно и не ждать жалобы ТСа.
Но это просто моё мнение.

slava_mib
Извиняюсь, если уже говорил, но я пропустил - тут несложно потеряться.
Какой физический модуль юзаете? Какие результаты?

#572
16:59, 10 окт. 2014

> Какой физический модуль юзаете? Какие результаты?
Mephisto std, наверное это уже оффтоп будет, мы же тут LiF обсуждаем, а не все прочие проекты, начиная с шахмат и далее )))

Используем Havok. О результатах говорить рано - прям обширных масс-тестов ещё не делали. Но, в принципе, есть понимание того, что с текущей реализацией даже 5к игроков онлайн на одном сервере - это где-то уже ЗА пределом мечтаний. Правда, у нас довольно короткий "тик" на сервере (соответственно, куча тиков в секунду) - т.к. игра фактически с элементами FPS, достаточно много объектов энвайронмента (даже на некоторых небольших уровнях - десятки тысяч) и, на этапах тестирования по крайней мере, толпы МОБов. Причём, АИ даёт довольно большую нагрузку т.к. у него и зрение "реальное" и логика не совсем тупая (да ещё и местами скриптованная), используются всякие ковер-поинты и прочее.

#573
17:10, 10 окт. 2014

slava_mib
> Используем Havok. О результатах говорить рано - прям обширных масс-тестов ещё
> не делали.
А не было идеи сделать полностью GPU физику хотя-бы для твёрдых тел?

#574
17:13, 10 окт. 2014

Mephisto std
согласен, оффтоп зашёл достаточно далеко. если кто-то из представителей проекта даёт отмашку, мы прекращаем безумие и начинаем банить нарушителей.

bazhenovc
> А не было идеи сделать полностью GPU физику хотя-бы для твёрдых тел?
если что, "хотя бы для твёрдых тел" как раз очень плохо ложится на архитектуру GPU. физику частиц или мягких тел гораздо удобнее считать на GPU.

#575
17:19, 10 окт. 2014

> А не было идеи сделать полностью GPU физику хотя-бы для твёрдых тел?
bazhenovc, была, но по куче разных причин в итоге отказались - тут и время разработки роляет, и то, что данные (кости те же самые) всё равно гонять по шине придётся и то, что сервак делаем мультиплатформенным (написание и отладка под виндой, а работа предполагается на никсах), и то, что надо было бы ОГЛ/ОЦЛ поддерживать (не выношу его) и куча всего ещё. По факту выбор в итоге стоял только между буллетом (в котором уже 3 года как обещают что "скоро" будет поддержка GPGPU) и хавоком. Но против буллета сыграла его глючность и бажность при работе чарактер-контроллера, а в пользу хавока то, что помимо физики там есть ещё много чего.

В принципе, от идеи GPGPU мы не отказались и, возможно, когда будет время и желание, мы всё же перетащим на него работу коллизий для выстрелов и систему зрения МОБов. Но пока у нас ни то, ни другое особых нареканий не вызывают и нас вполне устраивают.

#576
17:30, 10 окт. 2014

Suslik
> если что, "хотя бы для твёрдых тел" как раз очень плохо ложится на архитектуру
> GPU. физику частиц или мягких тел гораздо удобнее считать на GPU.
Я знаю, поэтому и спрашиваю :) там есть ряд проблем, которые у меня не получилось решить, и я хотел развить разговор в этом русле.
Меня в первую очередь твёрдые тела и интересовали, потому что реализовывать что-то кроме твёрдых тел я ещё не пробовал.

Я по твоим статьям (кстати, отдельное спасибо за них!) сделал простую физику на CPU и отталкиваясь от этого пытался сделать на GPU, но по скорости работы получилось хуже, чем CPU.

Suslik
> согласен, оффтоп зашёл достаточно далеко. если кто-то из представителей проекта
> даёт отмашку, мы прекращаем безумие и начинаем банить нарушителей.
Мефисто как раз и есть представитель проекта. И я тоже представитель. Пруф. И мы оба просим тебя тут всё зачистить :)
Десяток-другой страниц назад было весело, сейчас же это просто поливание друг-друга грязью.

slava_mib
Понял, спасибо :)

#577
17:32, 10 окт. 2014

bazhenovc
> GPU физику хотя-бы для твёрдых тел?
Я не думаю что у них есть мягкие тела на сервере =)

#578
18:21, 10 окт. 2014

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

bazhenovc
> Я знаю, поэтому и спрашиваю :) там есть ряд проблем, которые у меня не
> получилось решить, и я хотел развить разговор в этом русле.
> Меня в первую очередь твёрдые тела и интересовали, потому что реализовывать
> что-то кроме твёрдых тел я ещё не пробовал.
в физике можно выделить три самых важных и самых вычислительно сложных направления:
- collisions detection
- contact/joint solver
- soft body/particle solver

первый реализовать на видеокарте для обычных данных - практически бесполезное занятие, просто потому что алгоритмы collision detection в narrow phase(последняя стадия, где ищется разделяющая ось, контактные точки итп) по сути своей последовательные. существуют особые случаи, например, физика частиц, где можно особыми ухищрениями распараллелить этот процесс, например, в каждом фрагменте считать коллижны тех частиц, что в него попали, но это скорее исключение, чем правило, потому что подходит далеко не для любой геометрии.

второй реализовать тоже проблематично, потому что большинство солверов используют информацию либо сразу обо всех, либо по крайней мере о нескольких телах и для записи и для чтения одновременно, поэтому как ни выкручивайся, на GPU особо эффективно это реализовать пока сложно.

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

#579
18:53, 10 окт. 2014

Suslik
> первый реализовать на видеокарте для обычных данных - практически бесполезное
> занятие, просто потому что алгоритмы collision detection в narrow
> phase(последняя стадия, где ищется разделяющая ось, контактные точки итп) по
> сути своей последовательные.
На GPU можно параллельно обрабатывать группы объектов, которые были получены после broad phase. Причём нормальную broad phase на GPU сделали уже давно.
Касательно narrow phase - каждое следующее поколение GPU должно справлятся с этим всё лучше и лучше, потому что вендоры идут в сторону уменьшения granularity и унификации архитектуры - т.е. GPU всё лучше и лучше справляется с последовательными задачами. От идеала ещё очень и очень далеко, но прогресс довольно заметный.

Проблемы начинаются тогда, когда:
1. Физика имеет геймплейное значение и результаты физических вычислений нужны на CPU.
2. Когда остаётся мало групп объектов после broad phase (т.е. когда в одной группе очень много объектов).

Оба этих недостатка в принципе невозможно ничем компенсировать, поэтому в современной игровой индустрии GPU физику для твёрдых тел используют ограниченно и в основном для eye-candy эффектов, типа больших куч мелкого мусора, который рассыпан по уровню, но никак на игру не влияет.
Но в целом эта идея имеет право на жизнь, потому что в последнее время всё больше и больше применяется в играх - достаточно посмотреть видео NVIDIA, где они пиарят PhysX :)

>второй реализовать тоже проблематично, потому что большинство солверов используют информацию либо сразу обо всех, либо по крайней мере о нескольких телах и для записи и для чтения одновременно, поэтому как ни выкручивайся, на GPU особо эффективно это реализовать пока сложно.
Безусловно.

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

#580
19:24, 10 окт. 2014

Вопрос специалистам по C++
Что это:

class S{};

void main()
{
  int S::*ptm;

#581
19:32, 10 окт. 2014

slava_mib
> Правда, у нас довольно короткий "тик" на сервере
А сколько, если не секрет?

> что сервак делаем мультиплатформенным
А вот это очень и очень зря. Сервак это как раз там вещь, которую можно не то что под ОС, даже под железо точить и тюнить.

#582
20:11, 10 окт. 2014

San4es
> Что это:
> class S{};
>
> void main()
> {
>   int S::*ptm;


Ээм, пустой класс и попытка обращения к необъявленной переменной внутри него как к статической?

#583
20:23, 10 окт. 2014

SuperArmor
Понятие не имею. увидел на msdn http://msdn.microsoft.com/ru-ru/library/3967w96f.aspx и сам выпал в осадок.
Скажу сразу - конструкция компилируется.
дальше я попробовал
auto p = ptm;
и тоже скомпилилось
при наведении на ptm IntelliSense показывает int S::*ptm
при наведении на p IntelliSense показывает int S::*p

#584
20:34, 10 окт. 2014

San4es
> class S{};
>
> void main()
> {
>   int S::*ptm;
Это обьявление пустого указателя на член класса. Ему можно присваивать значение указателя на любой член класса, который имеет тип int.
Использовать надо так:

struct S
{
  int member;
  float memberFloat;
};

struct B
{
  int member;
};

int main() 
{ 
  int S::*ptm;
  
  ptm = &S::member;
  ptm = &S::memberFloat; // Error: assigning to 'int S::*' from incompatible type 'float S::*';
  ptm = &B::member; // Error: assigning to 'int S::*' from incompatible type 'int B::*';
  
  return 0;
}

Раньше любил подобное на собеседованиях спрашивать, сейчас понимаю, что смысла такие вопросы не имеют:)

Страницы: 138 39 40 4143 Следующая »
ПроектыФорумСобираю команду

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