Тёмная тема
- Mephisto std
- Постоялец
Suslik
> если что, "хотя бы для твёрдых тел" как раз очень плохо ложится на архитектуру
> GPU. физику частиц или мягких тел гораздо удобнее считать на GPU.
Я знаю, поэтому и спрашиваю :) там есть ряд проблем, которые у меня не получилось решить, и я хотел развить разговор в этом русле.
Меня в первую очередь твёрдые тела и интересовали, потому что реализовывать что-то кроме твёрдых тел я ещё не пробовал.
Я по твоим статьям (кстати, отдельное спасибо за них!) сделал простую физику на CPU и отталкиваясь от этого пытался сделать на GPU, но по скорости работы получилось хуже, чем CPU.
Suslik
> согласен, оффтоп зашёл достаточно далеко. если кто-то из представителей проекта
> даёт отмашку, мы прекращаем безумие и начинаем банить нарушителей.
Мефисто как раз и есть представитель проекта. И я тоже представитель. Пруф. И мы оба просим тебя тут всё зачистить :)
Десяток-другой страниц назад было весело, сейчас же это просто поливание друг-друга грязью.
slava_mib
Понял, спасибо :)
bazhenovc
> GPU физику хотя-бы для твёрдых тел?
Я не думаю что у них есть мягкие тела на сервере =)
почистил немного тред от личных выпадов(в основном моих и жимника, лол). дальнейшие нарушения порядка оффтопом будут караться.
bazhenovc
> Я знаю, поэтому и спрашиваю :) там есть ряд проблем, которые у меня не
> получилось решить, и я хотел развить разговор в этом русле.
> Меня в первую очередь твёрдые тела и интересовали, потому что реализовывать
> что-то кроме твёрдых тел я ещё не пробовал.
в физике можно выделить три самых важных и самых вычислительно сложных направления:
- collisions detection
- contact/joint solver
- soft body/particle solver
первый реализовать на видеокарте для обычных данных - практически бесполезное занятие, просто потому что алгоритмы collision detection в narrow phase(последняя стадия, где ищется разделяющая ось, контактные точки итп) по сути своей последовательные. существуют особые случаи, например, физика частиц, где можно особыми ухищрениями распараллелить этот процесс, например, в каждом фрагменте считать коллижны тех частиц, что в него попали, но это скорее исключение, чем правило, потому что подходит далеко не для любой геометрии.
второй реализовать тоже проблематично, потому что большинство солверов используют информацию либо сразу обо всех, либо по крайней мере о нескольких телах и для записи и для чтения одновременно, поэтому как ни выкручивайся, на GPU особо эффективно это реализовать пока сложно.
а вот последнее - уже ближе к делу. все частицы простые, если соединены регулярным образом(в сетку) или взаимодействуют только с соседями, при желании такую схему можно эффективно распараллелить.
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 партиклы успешно применяются в играх уже пару лет.
Вопрос специалистам по C++
Что это:
class S{};
void main()
{
int S::*ptm;
slava_mib
> Правда, у нас довольно короткий "тик" на сервере
А сколько, если не секрет?
> что сервак делаем мультиплатформенным
А вот это очень и очень зря. Сервак это как раз там вещь, которую можно не то что под ОС, даже под железо точить и тюнить.
San4es
> Что это:
> class S{};
>
> void main()
> {
> int S::*ptm;
Ээм, пустой класс и попытка обращения к необъявленной переменной внутри него как к статической?
SuperArmor
Понятие не имею. увидел на msdn http://msdn.microsoft.com/ru-ru/library/3967w96f.aspx и сам выпал в осадок.
Скажу сразу - конструкция компилируется.
дальше я попробовал
auto p = ptm;
и тоже скомпилилось
при наведении на ptm IntelliSense показывает int S::*ptm
при наведении на p IntelliSense показывает int S::*p
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; }
Раньше любил подобное на собеседованиях спрашивать, сейчас понимаю, что смысла такие вопросы не имеют:)
bazhenovc
Спасибо большое!
Я сам много чего на плюсах знаю, но с этим еще никогда не сталкивался.)
Имеет практическое применение, так что смысл есть:
Можно привязать какой-нибудь член класса к этому указателю и получить доступ к члену извне. (Возможно можно даже мониторить и изменять приватные члены)
San4es
От подобных вещей практическая польза только одна - демонстрировать свои заоблачные навыки впечатлительным блондинкам:)
На практике за использование подобных "фичей" надо отрывать руки - потому что оно нечитаемо для 99% программистов.
bazhenovc
> На практике за использование подобных "фичей" надо отрывать руки
Я уж сижу молчу, что про статику подумал, чтобы еще бОльшим дурачком не показаться. Оказывается всё ок :)
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'е, да еще плюс всякие лямбды с замыканиями, например.
San4es
Странное понимание статического полиморфизма. Я всегда думал, что это контракты, compile-time metadata и прочие кошерные вещи:)
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
Тема в архиве.