UGN>Может и подробно. Но я не все понял.
Перечитайте еще раз и так до тех пор пока не станет понятно. Там ведь нет никаких сверхсложных вычислений, математических формул или алгоритмов.

UGN>Не совсем понятно как.
Не понимаю, что тут может быть непонятного. Допустим мы (игрок, то есть) находится сейчас в координате (x, z) и можем двигаться только в четырех направлениях. Также мы используем цилиндр в качестве фигуры которая описывает нас. То есть мы знаем наш радиус. При нажатии на стрелки мы инкрементируем или декриментируем значения x или z и проверяем не выходим ли мы за пределы комнаты. Если выходим, то восстанавливаем старое значение. Теперь допустим в комнате есть колона с центром (x1, z1) и радиусом r1. В случае перемещения по комнате, можем мы определить натолкнулись ли мы на колону или нет?

UGN>Может:
UGN>* Где-то заранее загружаем модели, высчитываем (в DX вроде есть? или сами реализуем?) и запоминаем описывающие их простые тела
Загружаем. Устанавливаем их начальные координаты. Находим сами радиус описывающего нас цилиндра или сферы. Наш мир, наши модели. При чем тут ДХ? Все делаем сами. ДХ рисует только то что нам нужно и когда нам нужно.

UGN>* В движке при перемещении объекта меняем его математический центр.
Меняем.
UGN>* Для проверки коллизий используем заранее подготовленные тела ( сферы, боксы и прочее -- для требуемой детализации )
Используем. Как в примере выше.

UGN> Пересечения определяем сами: своя матричная библиотчка или 3dParty.
Забудьте о матрицах. Они нужны только для того, чтобы изменить размер обьекта, перемеместить или повернуть его в 3Д. Collision detection определяем сами.

UGN>* Потом, на основании перемещения координат объектов, готовим некие матрицы трансформации и скармливаем графической части.
Не надо думать о матрицах. Просто вызываете нужный метод Translate(x, y, z) который переместит обьект на указанные значения (не координаты). Он сам подготовит нужную матрицу. Матрицы сами создают для создания каких-нибудь спец-эффектов.

UGN>Так?
Так.

Здравствуйте, UGN, Вы писали:

Вобще физику и коллизии принято считать в движке ибо разработчик как ни кто другой знает какие мструктуры данных он использовал, как устроен мир и тп... соответственно может выбрать оптимальный алгоритм.
Также не смотря на то что DX может отсекать то что не видно обычно стараются отсеч на уровне движка то что точно не видно. Например зачем гонять лишние сотню тысяч треугольников кторые находятся у тебя за спиной или в соседней комнате?
Однако если трудно определить лежит ли данный треугольник в кадре или нет то это как правило отдают на совесть DX. Например пол модели попало в кадр, а вторая нет. На уровне движки разбиратся довольно накладно, а ДХ сделает это легко.
Что касается положения объектов то это тоже считет движок, но преобразование вертексов модели из ее координат в координаты мира и вывод на экран делает ДХ. Те скармливаешь ему модель и матрицу которая задает положение модели в пространстве, а ДХ уже производит все преобразования причем если видюха может то это будет делать видюха, а не проц. Также получается экономия за счет того что как правило выводятся несколько одинаковых моделий... воспользовавшись этим модель можно загрузить один раз и сказать чтобы она была выведена несколько раз передавая лишь матрици положения в которых какието 16 float'ов.

Вопрос (теоретический): как такой подход (отделение логики от представления) применяют в 3D графике.

Допустим, я хочу сделать бродилку.
На уровне логики у меня описаны все соответствующие классы, расчитывается их поведение, взаимодействие с окружающим миром.
Потом, по рассчитанным данным графическая библиотека ( напр. DX ) рисует картинку.

Вопрос: где считаются размеры объектов, их столкновения и проч?
Насколько я знаю, DX сам преобразует координаты (перемещения, повороты), сам и коллизии может посчитать. А зачем?
Ведь это неправильно? Разве это не должно считаться на уровне логики?
Разве не на уровне логики я должен определять, уперся ли мой герой лбом стену, может ли он пойти вперед?
Это будет слишком медленно? Графический процессор оптимизирован под выполнение таких задач?
Как быть, если я хочу отделить код рисования от остального? Если вдруг захочу DX поменять на GL?

И вообще не понятно, как тогда все должно работать.
Может кто-нибудь просветить?

Здравствуйте, UGN, Вы писали:

UGN>Вопрос (теоретический): как такой подход (отделение логики от представления) применяют в 3D графике.

UGN>Допустим, я хочу сделать бродилку.
//*************************\\
Похвально
//*************************//
UGN>На уровне логики у меня описаны все соответствующие классы, расчитывается их поведение, взаимодействие с окружающим миром.
UGN>Потом, по рассчитанным данным графическая библиотека ( напр. DX ) рисует картинку.

UGN>Вопрос: где считаются размеры объектов, их столкновения и проч?
//*************************\\
А где хочешь!!
//*************************//
UGN>Насколько я знаю, DX сам преобразует координаты (перемещения, повороты), сам и коллизии может посчитать. А зачем?
//*************************\\
А затем чтоб облегчить и ускорить расзаботку приложения.. Если хочешь писать это сам — все в твоих руках! Никто не запрещает тебе самому рассчитывать и повороты, и перемещения и коллизии.
//*************************//
UGN>Ведь это неправильно? Разве это не должно считаться на уровне логики?
Это не должно, это по желанию разработчика...
UGN>Разве не на уровне логики я должен определять, уперся ли мой герой лбом стену, может ли он пойти вперед?
//*************************\\
Опять неверных подход Ты не должен!!! Ты можешь делать все, чего пожелаешь. )))
//*************************//
UGN>Это будет слишком медленно? Графический процессор оптимизирован под выполнение таких задач?
//*************************\\
Это будет зависеть от того, как ты напишешь логику. А вообще ты прав.. Графический акселератор как раз и акселерирует ))) эти задачи. Т.е. в т.ч. рассчитывает действия с 3Д объектами.
//*************************//
UGN>Как быть, если я хочу отделить код рисования от остального? Если вдруг захочу DX поменять на GL?
//*************************\\
Если хочешь — делай.
//*************************//
UGN>И вообще не понятно, как тогда все должно работать.
UGN>Может кто-нибудь просветить?
//*************************\\
Как работать... Да как придумаешь!! Можешь отдельно писать процедуру ПоворотОбъекта(Object* Obj, INT Angle, char XYZ) и на него ссылаться во всех местах своего движка. А уже в этой процедуре выбирать под какую библиотеку работаешь и соответственные телодвижения делать...
//*************************//

Здравствуйте, UGN, Вы писали:

UGN>Насколько я знаю, DX сам преобразует координаты (перемещения, повороты), сам и коллизии может посчитать. А зачем?
первый раз слышу, чтоб DX коллизии счтал (Если речь идет об DirectX, конечно).

Здравствуйте, Went, Вы писали:

UGN>>Насколько я знаю, DX сам преобразует координаты (перемещения, повороты), сам и коллизии может посчитать. А зачем?
W>первый раз слышу, чтоб DX коллизии счтал (Если речь идет об DirectX, конечно).

Он самый. Я имел в виду, что DX, AFAIR, может посчитать что-то типа минимальной сферы или коробки, в которую, влезает мой объект.
Кажется, он же может и пересечения отловить.

Я пытаюсь понять, в чем мое заблуждение. Я полагаю, что рассчитывать координаты нужно совсем не там, где это рисуется. Однако, насколько я видел примеры из DX SDK, там все свалено в одну кучу. Наверное, для упрощения примера. Так вот как на самом деле нужно? Действительно ли приходится считать координаты с помощью DX из-за того, что он это делает эффективнее, с помощью GPU. Или здесь какая-то ошибка? Конечно, можно инкапсулировать расчет координат так, чтобы было все равно где они считаются, но как это делается в реальных проетах?

Здравствуйте, VolT, Вы писали:

UGN>>Вопрос (теоретический): как такой подход (отделение логики от представления) применяют в 3D графике.
UGN>>Допустим, я хочу сделать бродилку.
VT> Похвально
Что похвально?

VT>//*************************//

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

UGN>>Вопрос: где считаются размеры объектов, их столкновения и проч?
VT> А где хочешь!!

А где правильно?

UGN>>Насколько я знаю, DX сам преобразует координаты (перемещения, повороты), сам и коллизии может посчитать. А зачем?
VT> А затем чтоб облегчить и ускорить расзаботку приложения.. Если хочешь писать это сам — все в твоих руках! Никто не запрещает тебе самому рассчитывать и повороты, и перемещения и коллизии.

А как лучше? DX испоьзует какие-то специфические возможности GPU или также как и я грузит CPU?


UGN>>Как быть, если я хочу отделить код рисования от остального? Если вдруг захочу DX поменять на GL?
VT> Если хочешь — делай.

Интерфейс GL тоже позволяет рассчитывать координаты? Или только рисует?

Можно ли сказать, что подобные 3D библиотеки осуществляют рассчет координат самостоятельно и более эффективно, имея фору в виде доступа к неким ресурсам GPU?

Здравствуйте, WolfHound, Вы писали:


WH>Вобще физику и коллизии принято считать в движке ибо разработчик как ни кто другой знает какие мструктуры данных он использовал, как устроен мир и тп... соответственно может выбрать оптимальный алгоритм.

Т.е. все правильно делают, логика отдельно, отрисовка отдельно.

WH>Что касается положения объектов то это тоже считет движок, но преобразование вертексов модели из ее координат в координаты мира и вывод на экран делает ДХ. Те скармливаешь ему модель и матрицу которая задает положение модели в пространстве, а ДХ уже производит все преобразования <...>

Я не очень хорошо знаком с этой областью, просто когда-то смотрел примеры из SDK. Мне почему-то помнится, что там задается какой-то массив точек (вертексов?), представляющий объект. Если я хочу его (объект) повернуть или переместить, то средствами самого DX накладываю какую-то трансформирующую матрицу, после чего и вывожу на экран. Тут же вроде бы можно и проверить какие объекты пересекаются. Я правильно помню?

Так вот если, положим, мне нужно сделать следующее:
Обработка события <шаг влево> (условно)
1. Если влево сдвинуться нельзя ( где-то здесь проверяем, есть ли слева препятствие -- сдвигаем объект, проверяем пересечения? )
2. Выпучить у персонажа левый глаз. ( как? самому изменить координаты вертексов глаза? )
3. Иначе сдвинуться влево на delta (изменить матрицу положения модели? )
4. Нарисовать

Как и где правильные разработчики реализуют пункты 1, 2 и 3?
Скрыто вызывают соответсвующие методы DX? или всю математику реализуют сами?

UGN>Т.е. все правильно делают, логика отдельно, отрисовка отдельно.
Да.

UGN>Я не очень хорошо знаком с этой областью, просто когда-то смотрел примеры из SDK. Мне почему-то помнится, что там задается какой-то массив точек (вертексов?), представляющий объект. Если я хочу его (объект) повернуть или переместить, то средствами самого DX накладываю какую-то трансформирующую матрицу, после чего и вывожу на экран.
Опять да. Насколько повернуть и переместить обьект считаешь в части кода ответственного за логику, а используешь эти данные (ака накладываешь матрицу) уже в рендерере.

UGN>Тут же вроде бы можно и проверить какие объекты пересекаются. Я правильно помню?
По-моему Вы что-то путаете тут. Wolfhound все подробно уже обьяснил. Какие обьекты пересекаются просчитывается в "логике игры." Графическая библиотека может только удалять невидимые грани (aka hidden surface removal) и обратные стороны полигонов (back-face culling, вроде).

UGN>Так вот если, положим, мне нужно сделать следующее:
Я в SDK не заглядывал но сделал бы так:

while (true) {
      GetInput();
      if (input == EXIT)
           Exit();
      DoLogic();
      DrawWorld();
}

UGN>Обработка события <шаг влево> (условно)
Получаем координаты куда двигаться.
UGN>1. Если влево сдвинуться нельзя ( где-то здесь проверяем, есть ли слева препятствие -- сдвигаем объект, проверяем пересечения? )
Делаем это в DoLogic().

UGN>2. Выпучить у персонажа левый глаз. ( как? самому изменить координаты вертексов глаза? )
Ничего менять не надо (в смысле вертексов). Опять-таки в DoLogic() устанавливаем текущее состояние модели (ну или текущий кадр — это индекс в массив кадров, например) в состояние _выпученный_левый_глаз_.

UGN>3. Иначе сдвинуться влево на delta (изменить матрицу положения модели? )
Матрицу не меняем. Мы все еще в DoLogic(). Мы только высчитываем координаты куда двигаться (проверяя столкновения и т.д.)
UGN>4. Нарисовать
Теперь мы уже в DrawWorld(). Только здесь мы устанавливаем нужную (нужные) матрицу (матрицы) и рисуем _нужную_часть мира. В DoLogic() мы решаем (и устанавливаем соответстующий переменные, флаги и т.д.) какую из комнат, например, рисовать а в DrawWorld() рисуем. Графической библиотеке даются уже _подготовленные_ полигоны, а она уже в свою очередь отсекает части полигонов (или некоторые полигоны) которые не попадают в кадр, как уже Wolfhound верно заметил.

UGN>Как и где правильные разработчики реализуют пункты 1, 2 и 3?
См. мой ответ .

UGN>Скрыто вызывают соответсвующие методы DX? или всю математику реализуют сами?
Перечитай ответ Wolfhound'a. Там все написано.

P.S. Тут уже да и на любом форуме для гейм девелоперов неоднократно обсуждался game loop.

Здравствуйте, Аноним, Вы писали:

А>По-моему Вы что-то путаете тут. Wolfhound все подробно уже обьяснил. Какие обьекты пересекаются просчитывается в "логике игры." Графическая библиотека может только удалять невидимые грани (aka hidden surface removal) и обратные стороны полигонов (back-face culling, вроде).

Может и подробно. Но я не все понял.

UGN>>1. Если влево сдвинуться нельзя ( где-то здесь проверяем, есть ли слева препятствие -- сдвигаем объект, проверяем пересечения? )
А>Делаем это в DoLogic().
UGN>>3. Иначе сдвинуться влево на delta (изменить матрицу положения модели? )
А>Матрицу не меняем. Мы все еще в DoLogic(). Мы только высчитываем координаты куда двигаться (проверяя столкновения и т.д.)

Не совсем понятно как.
Может:
* Где-то заранее загружаем модели, высчитываем (в DX вроде есть? или сами реализуем?) и запоминаем описывающие их простые тела
* В движке при перемещении объекта меняем его математический центр.
* Для проверки коллизий используем заранее подготовленные тела ( сферы, боксы и прочее -- для требуемой детализации )
Пересечения определяем сами: своя матричная библиотчка или 3dParty.
* Потом, на основании перемещения координат объектов, готовим некие матрицы трансформации и скармливаем графической части.
Так?

Здравствуйте, UGN, Вы писали:

UGN>Не совсем понятно как.
UGN>Может:
UGN>* Где-то заранее загружаем модели, высчитываем (в DX вроде есть? или сами реализуем?) и запоминаем описывающие их простые тела
UGN>* В движке при перемещении объекта меняем его математический центр.
UGN>* Для проверки коллизий используем заранее подготовленные тела ( сферы, боксы и прочее -- для требуемой детализации )
UGN> Пересечения определяем сами: своя матричная библиотчка или 3dParty.
UGN>* Потом, на основании перемещения координат объектов, готовим некие матрицы трансформации и скармливаем графической части.
UGN>Так?

Да. Вполне так.