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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

#573
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 партиклы успешно применяются в играх уже пару лет.

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

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

class S{};

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

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

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

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

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

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


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

#577
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

#578
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;
}

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

#579
20:39, 10 окт. 2014

bazhenovc
Спасибо большое!

Я сам много чего на плюсах знаю, но с этим еще никогда не сталкивался.)

Имеет практическое применение, так что смысл есть:

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

#580
21:07, 10 окт. 2014

San4es
От подобных вещей практическая польза только одна - демонстрировать свои заоблачные навыки впечатлительным блондинкам:)

На практике за использование подобных "фичей" надо отрывать руки - потому что оно нечитаемо для 99% программистов.

#581
21:11, 10 окт. 2014

bazhenovc
> На практике за использование подобных "фичей" надо отрывать руки
Я уж сижу молчу, что про статику подумал, чтобы еще бОльшим дурачком не показаться. Оказывается всё ок :)

#582
21:44, 10 окт. 2014

bazhenovc
Погоди есть прикольное применение.
Ты ведь знаешь про статический полиморфизм?
Еще одно проявление статического полиморфизма можно сотворить:

"передача в функцию указания"
void EditData(DATA *edata, unsigned char DATA::*field)
{
    for(int i = 0; i < NUM; i++)
    {
        edata.*field = 255;
    }
}

//.....
EditData(data, &DATA::x1);
EditData(data, &DATA::x2);

ссылка  http://www.cyberforum.ru/cpp-beginners/thread1272129.html#post6700795

а нечитаемых штук в C++ и так больше 100500 в бусте и STL'е, да еще плюс всякие лямбды с замыканиями, например.

#583
21:49, 10 окт. 2014

San4es
Странное понимание статического полиморфизма. Я всегда думал, что это контракты, compile-time metadata и прочие кошерные вещи:)

#584
22:13, 10 окт. 2014

bazhenovc
в эту функцию можно любое поле типа int засунуть.
А если сделать функцию шаблонной о двух параметрах, то и любой агрегирующий объект любого типа и любое поле любого типа можно передать. Чем не контракт?

А вот контрактная функция, принимающая указание

template<class T, class U>
void EditData( T *edata, U T::*field, const U& value )
{
for(int i = 0; i < NUM; i++)
{
edata.*field = value;
}
}

Инициализирует поля всех экземпляров типа T в массиве значением value

Применение:
DATA *datas = new DATA[NUM];
EditData< DATA, string >( datas, &DATA::x1, string("1234") );

Контракт заключается в том, что T содержит поле типа U

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

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