- Digan
- Постоялец
Digan
> > 1. Mouse picking.
> в другую сторону же все делаю обычно: из места клика пускают луч и проверяют
> его пересечение с объектом.
Тут тоже иногда лучше использовать экранные координаты. Например:
По сцене развешаны отрезки. В моём случае это были абстрактные линейки/рулетки, показывающие расстояния между двумя точками. Нужно дать игроку возможность тыком мышки выбрать существующий отрезок, чтобы его удалить. Решение: считать расстояние от курсора до отрезков в экранных координатах. Решается сразу две проблемы:
1. Объекту не требуется физическая форма/коллайдер, чтобы пустить рейкаст и проверить, во что он воткнулся. Можно просто перевести координаты отрезков в экранные, посчитать расстояние от точки курсора до каждого отрезка и выбрать ближайший. Иначе нужно было бы или делать объектам коллайдеры, или считать расстояния в пространстве от луча до отрезков.
2. Если работать в мировых координатах, то на точность выбора объекта мышкой будет влиять расстояние от камеры до объекта. При допустимой погрешности в 5 см легко выбрать объект у себя перед носом, но очень трудно, если до него 100 метров. Если считать в экранных координатах, то можно задавать погрешность в пикселах или в % от ширины экрана. Для пользователя это намного удобнее.
Кстати, пример системы автоматического управления камерами: http://www.youtube.com/watch?v=QNR9Nvjsv9Y&feature=player_det… fhy5hIp#t=783 Там Unity, но принципы универсальны.
alexzzzz
>Игрок смотрит через оптический прицел, белочка у него на пол экрана и
> поэтому должна быть нарисована в полной детализации.
Мне кажется в этом случае камера будет перемещена ближе к белочке. Игрок до сих пор на 200 м, а между камерой и белочкой расстояние сократилось - рисуем белочку с полной детализацией. Поэтому не вижу в этом случае делать зависимость детализации белки от её размера на экране.
Digan
> Мне кажется в этом случае камера будет перемещена ближе к белочке.
Тебе кажется.
Digan
> Мне кажется в этом случае камера будет перемещена ближе к белочке.
С хрена бы? Оптика не умеет в телепортацию.
Digan
> Мне кажется в этом случае камера будет перемещена ближе к белочке.
Приплыли. Бред бредовый. Ты когда-нибудь в бинокль смотрел? А с матрицей перспективы работал? При взгляде в оптику уменьшается угол обзора. Чем больше увеличение (т.е. чем уже угол), тем больше все кажется плоским, потому что с увеличением расстояния уменьшается эффект параллакса.
Нафлудили...
Первые три комментатора решили блеснуть остроумием.
ENgine
> Эм, если перемножение 3-х матриц это сложно,
Ахренеть... Во-первых, перемножив 3 матрицы никогда не получишь экранные координаты.
Во-вторых, если я хочу узнать экранные координаты всех вершин, что отображаются на экране, то мне каждую вершину перемножать на 3 матрицы, переводить результат с учетом того, что экран имеет высоту и ширину от -1 до 1, округлять, инвертировать Y. Это я и так знаю. Я же и спросил, нет ли другого способа? А мне предлагают вычислять все вершины повторно.
vakula
> DirectX ими же пользуется?
И можно как-нибудь выудить их из вершинного буфера или откуда-то еще? Именно, они же все-все уже и так найдены. На кой черт мне их опять искать?
Ramm
> И можно как-нибудь выудить их из вершинного буфера или откуда-то еще? Именно,
> они же все-все уже и так найдены. На кой черт мне их опять искать?
Теоретически можно писать в другой буфер, а потом читать из него, но так делать не надо. Это уродливо в коде и совсем не быстро.
> Во-вторых, если я хочу узнать экранные координаты всех вершин, что отображаются
> на экране, то мне каждую вершину перемножать на 3 матрицы, переводить результат
> с учетом того, что экран имеет высоту и ширину от -1 до 1, округлять,
> инвертировать Y. Это я и так знаю. Я же и спросил, нет ли другого способа? А
> мне предлагают вычислять все вершины повторно.
Другого это какого? У тебя есть координата и матрица.
Нет волшебного способа, который хоп - и выполнит необходимые преобразования без умножения на матрицу.
Зачем тебе вообще сдались экранные координаты? Во всех мыслимых применениях могут потребоваться как максимум координаты центра или AABB.
-Eugene-
> Зачем тебе вообще сдались экранные координаты?
Например, подписать каждую вершину, добавить возможность кликать по этим подписям для вывода дополнительной информации.
Я написал именно такой вариант, как в моем сообщении выше. Работает. Других вариантов точно нет?
Ramm
> Во-вторых, если я хочу узнать экранные координаты всех вершин, что отображаются
> на экране, то мне каждую вершину перемножать на 3 матрицы, переводить результат
> с учетом того, что экран имеет высоту и ширину от -1 до 1, округлять,
> инвертировать Y. Это я и так знаю. Я же и спросил, нет ли другого способа?
Другой способ, который правильный, - умножить матрицы модели, вида и проекции друг на друга, получить итоговую матрицу, потом все вершины умножать на эту одну матрицу.
Все описанные дополнительные действия, кроме округления, если они нужны, можно также описать матрицами. В результате должна получиться одна общая матрица, которая будет переводить координаты вершин из локальных в нужные.
Ramm
> Например, подписать каждую вершину, добавить возможность кликать по этим
> подписям для вывода дополнительной информации.
Можно рисовать подписи в пространстве мира. Но это шило на мыло... Обрабатывать клики станет сложнее.
У тебя действительно так много вершин, что расчет их на ЦПУ становится накладным?
-Eugene-
> У тебя действительно так много вершин, что расчет их на ЦПУ становится
> накладным?
Пока нет. Я же просто спросил как правильно и быстро все сделать. Я сначала буфером вершин пользовался только перед выводом координат, каждый раз копируя в него новые координаты. И тоже до определенного момента это не накладно. Но это не правильно.
alexzzzz
> В результате должна получиться одна общая матрица
Для одного объекта - одна, для другого - уже другая. У него уже другие углы поворота, другое смещение.
Ramm
> Для одного объекта - одна, для другого - уже другая. У него уже другие углы
> поворота, другое смещение.
Ну да, так оно всё и работает. Если счёт на наносекунды, заранее перемножаешь друг на друга все матрицы (допустим, V, P, ...), кроме матрицы модели (M):
X = V*P*... Эта матрица одинаковая для всех объектов.
Потом для каждого объекта берёшь его матрицу модели M и умножаешь на получившуюся матрицу X, получаешь итоговую матрицу Y. Все вершины этого объекта потом умножаешь на матрицу Y.
Ramm
> Пока нет. Я же просто спросил как правильно и быстро все сделать
Динамическое построение надписей в каждой вершине тяжелее одного умножения на матрицу.
alexzzzz
Мне почему то кажется, что он это знает.
Ramm
> И можно как-нибудь выудить их из вершинного буфера или откуда-то еще? Именно,
> они же все-все уже и так найдены.
Насколько я понимаю процесс, нет никакого буфера с преобразованными вершинами. Вершинный шейдер занимается не совсем вершинами - он вычисляет положение точки на экране (+ глубина для z-буфера) и отсылает результат в пиксельный шейдер для последующего раскрашивания. И так для каждого пикселя/текселя на экране.
Тема в архиве.