Я нашел этот пост, потому что искал способ преобразования строки SQLAlchemy в dict. Я использую SqlSoup ... но ответ был построен сам, поэтому, если он может помочь кому-то, вот мои два цента:
a = db.execute('select * from acquisizioni_motes')
b = a.fetchall()
c = b[0]
# and now, finally...
dict(zip(c.keys(), c.values()))
Шейдеры и проекции в Vulkan ведут себя точно так же, как и в OpenGL. Существуют небольшие различия в диапазонах глубин ([-1, 1] в OpenGL, [0, 1] в Вулкане) или в начале системы координат (нижний левый в OpenGL, верхний левый в Вулкане), но принципы точно такие же. Аппаратное обеспечение по-прежнему остается неизменным и выполняет вычисления таким же образом как в OpenGL, так и в Vulkan.
4-компонентные векторы служат для нескольких целей:
.w
, который вы упомянули, используется во время проекции в перспективе. Все это мы можем сделать с 4x4 матрицами и, следовательно, нам нужны 4-компонентные векторы (так их можно умножить на 4x4 матрицы). Опять же, я пишу об этом, потому что вышеприведенные правила применяются как к OpenGL, так и к Vulkan.
Итак, для цели .w
компонента переменной gl_Position
- это точно так же в Vulkan. Он используется для масштабирования вектора положения - при перспективных вычислениях (умножение проекционной матрицы) исходная глубина изменяется исходной компонентой .w
и сохраняется в .z
компоненте переменной gl_Position
. Кроме того, оригинальная глубина также сохраняется в компоненте .w
. После этого (как шаг фиксированной функции) аппаратное обеспечение выполняет разделение перспективы и делит положение, хранящееся в переменной gl_Position
его компонентом .w
.
В шагах орфографической проекции, выполняемых аппаратным обеспечением, точно такие же , но значения, используемые для расчетов, различны. Таким образом, этап разделения перспективы все еще выполняется аппаратным обеспечением, но он ничего не делает (положение погружено на 1.0).
В компьютерной графике преобразования представлены матрицами. Если вы хотите что-то вращаться, вы умножаете все его вершины (вектор) на матрицу вращения. Хотите, чтобы он переместился? Умножить на матрицу перевода и т. Д.
tl; dr: Вы не можете описать перевод по оси z с помощью 3D-матриц и векторов. Вам нужно как минимум еще 1 размер, поэтому они просто добавили фиктивный размер w
. Но вещи ломаются, если это не 1, поэтому держите его в 1: P.
. В любом случае, теперь мы начнем с быстрого обзора по умножению матрицы:
Вы в основном положили x
выше a
, y
выше b
, z
выше c
. Умножьте весь столбец на переменную, которую вы только что переместили, и суммируйте все в строке.
Итак, если вам нужно перевести вектор, вам нужно что-то вроде:
Посмотрите, как x
и y
теперь переведены на az
и bz
? Это довольно неудобно:
z
, когда вы перемещаете вещи (что, если z
было отрицательным? Вам пришлось бы двигаться в противоположных направлениях Это тяжело, если вы просто хотите переместить что-то на дюйм ...) z
. Вы никогда не сможете летать или уходить в подполье Но если вы всегда можете убедиться, что z = 1
:
Теперь гораздо яснее, что эта матрица позволяет вам перемещаться по плоскости xy значениями a
и b
. Только проблема в том, что вы концептуально левитируете все время, и вы все равно не можете идти вверх или вниз. Вы можете перемещаться только в 2D.
Но вы видите рисунок здесь? С 3D-матрицами и 3D-векторами вы можете описать все основные движения в 2D. Итак, что, если бы мы добавили 4-мерное измерение?
Выглядит хорошо. Если мы постоянно сохраняем w = 1
:
Там мы идем, теперь вы получаете перевод по всей оси 3. Это то, что называется однородными координатами.
Но что, если бы вы делали большие и большие; сложная трансформация, приводящая к w != 1
, и нет никакого способа обойти это? OpenGL (и в основном любая другая система CG, я думаю) будет выполнять так называемую нормализацию: разделите результирующий вектор на компонент w
. Я не знаю достаточно, чтобы точно сказать, почему (потому что масштабирование является линейным преобразованием?), Но оно имеет благоприятные последствия (может использоваться в перспективных преобразованиях). В любом случае, матрица перевода будет выглядеть так:
И вот вы посмотрите, как каждый компонент скроется w
, то это переводится? Вот почему w
управляет масштабированием.
gl_Position
является однородными координатами . Компонент w
играет роль в перспективной проекции.
Матрица проецирования описывает отображение из трехмерных точек зрения на сцену в 2D-точки на окне просмотра. Он преобразуется из пространства глаз в пространство клипа, а координаты в пространстве клипа преобразуются в нормализованные координаты устройства (NDC) путем деления на компонент w
координат клипа ( Перспективное разделение ) .
В Перспективной проекции матрица проекции описывает отображение из трехмерных точек в мире, как они видны из камеры с отверстиями, в двумерные точки окна просмотра. Координаты глазного пространства в усечении камеры (усеченной пирамиды) отображаются в куб (координаты нормализованного устройства).
Матрица перспективных проекций:
r = right, l = left, b = bottom, t = top, n = near, f = far
2*n/(r-l) 0 0 0
0 2*n/(t-b) 0 0
(r+l)/(r-l) (t+b)/(t-b) -(f+n)/(f-n) -1
0 0 -2*f*n/(f-n) 0
Когда декартова координата в пространстве зрения преобразованный матрицей перспективной проекции, то результатом является однородные координаты . Компонент w
растет с расстоянием до точки зрения. Это приводит к уменьшению объектов после разрыва перспективы Perspective , если они находятся дальше.