Comments 27
Ожидал лампового скриншота
Вечер воспоминаний объявляется открытым!
Z-buffer ответа не даст. Про нелинейность читать тут. А вообще лучше читать с самого начала. Кстати, рейтрейсинг — это совсем не z-buffer, за этим сюда.
P.S. Реальные текстурные координаты изменяются нелинейно, для скорости их заменяют линейными. Но что происходит с Z-координатой и зачем при преобразовании Z переворачивают? Ответ на этот вопрос и дает Z-буфер
Z-buffer ответа не даст. Про нелинейность читать тут. А вообще лучше читать с самого начала. Кстати, рейтрейсинг — это совсем не z-buffer, за этим сюда.
1) совет запоздал на 21 год, сейчас мне все понятно и про нелинейность и про Z-буфер. Да и читать про нелинейность не надо, ее видно в любой комнате — достаточно подойти к стене и взглянуть вдоль нее.
2) зачаточный рейтрейсинг тут есть — выпускание луча из камеры через экранный пиксель. полноценный бы получился, если бы он отразился от грани
2) зачаточный рейтрейсинг тут есть — выпускание луча из камеры через экранный пиксель. полноценный бы получился, если бы он отразился от грани
А, вы про нелинейности, вызванные неидеальностью вашей оптики? Ну так z-buffer тоже в этом не поможет.
нет, нелинейность вызвана тем банальным фактом, что перспективная проекция нелинейна
Уф. Вы уж больно туманны в ваших определениях.
Perspective projection is a linear projection where three dimensional objects are projected on a picture plane.
в математике понятие линейность определено достаточно строго. перспективная проекция не является линейным преобразованием (любое линейное преобразование равные отрезки на одной прямой всегда преобразует в равные отрезки на одной прямой)
первая же формула в википедии нам намекает:
en.wikipedia.org/wiki/Camera_matrix
первая же формула в википедии нам намекает:
en.wikipedia.org/wiki/Camera_matrix
Не является линейным преобразованием координат точек (кстати, в однородных координатах-таки является), зато переводит прямые в прямые и является линейной проекцией. Потому и говорю, что вы туманны в определениях.
ну если буквоедствовать, то линейные преобразования возможны только над векторным пространством, а однородные координаты им не являются :)
я очень последователен в определениях, и линейность понимаю так, как ее определяет математика (хотя внутри тусовки может использоваться самый лютый фольклор). применительно к рендерингду это имеет самй прострой смылс — если некая величина U вычисленная для текущего пикселя, то в следующем пикселе строки ее значении будет U+deltaU, причем deltaU постоянно для всей грани. Для исходной геометрической координаты Z это неверно в силу приведенной формулы. Для 1/z — верно
я очень последователен в определениях, и линейность понимаю так, как ее определяет математика (хотя внутри тусовки может использоваться самый лютый фольклор). применительно к рендерингду это имеет самй прострой смылс — если некая величина U вычисленная для текущего пикселя, то в следующем пикселе строки ее значении будет U+deltaU, причем deltaU постоянно для всей грани. Для исходной геометрической координаты Z это неверно в силу приведенной формулы. Для 1/z — верно
я почитал текст, вы Z-буфер зачем-то дали до перспективного преобразования, это как бы очень странно, гораздо лучше объяснять наоборот
напишите про обработку звука
P.S. Реальные текстурные координаты изменяются нелинейно, для скорости их заменяют линейными. Но что происходит с Z-координатой и зачем при преобразовании Z переворачивают? Ответ на этот вопрос и дает Z-буфер
Что вы имеете в виду? Реальные текстурные координаты изменяются линейно в плоскости экрана как 1/z. Поэтому z-буфер надо делать буфером 1/z, а не z.
Реальные текстурные координаты изменяются в грани совершенно нелинейно, из приведенной формулы это видно. Можно представить себе очень длинную стену, с челнобелыми полосами равной ширины, смотрите вдоль нее. При линейном изменении текстурных координат мы видели бы полосы равной ширины, в реальности — ближние полосы широкие, дальние — узкие.
Для ускорения расчетов реальные текстурные координаты никто не считает, считают их линейную интерполяцию, а ошибку легко контролировать, разбивая большие грани на маленькие. С 1/z координатой ситуация другая, она реально линейна, потому «1/z» буфер работает железобетонно и никакой коррекции не требует
Для ускорения расчетов реальные текстурные координаты никто не считает, считают их линейную интерполяцию, а ошибку легко контролировать, разбивая большие грани на маленькие. С 1/z координатой ситуация другая, она реально линейна, потому «1/z» буфер работает железобетонно и никакой коррекции не требует
Для ускорения расчетов реальные текстурные координаты никто не считает, считают их линейную интерполяцию,
Считают линейную интерполяцию U/Z и V/Z. И получают значение текстуры совершенно точно в любой точке экрана. Для ускорения же линейно или квадратично интерполируют через ряд точек, как это сделано в Quake. Но в узлах вычисляют точно.
не может линейная интерполяция быть совершенно точная в любой точке экрана, иначе бы она не называлась «интерполяция». Она может быть достаточно точна, достаточность обеспечивается разбиением грани на маленькие части (или как вы пишете — узлы). С 1/z ситуация проще — она линейная, потому точна и ничего разбивать не надо
Интерполяция не означает, что значения функции в промежутке отличаются от реальных. Попробуйте линейную интерполяцию для линейной же функции. А так как 1/z меняется линейно, то все точки получаются точно.
Когда вы сделали проекцию грани, вы получили координаты (x,y) для экрана. Для концов этой грани известны точно значения z и (u,v). Дальше вы линейно интерполируете по экрану 1/z, u/z и v/z и вычисляете для любой точки экрана в промежутке значения u и v из этой троицы. Получаете точное значение (u,v) для любой точки экрана в промежутке. Точное. Но так как делить на 1/z долго, часто точные значения вычисляют с некоторым экранным шагом, а между ними делают интерполяцию. Но никто так делать не заставляет.
Вот пример моей работающей библиотеки (ещё, правда, не доделанной до вида библиотеки) с элементами OpenGL:
Когда вы сделали проекцию грани, вы получили координаты (x,y) для экрана. Для концов этой грани известны точно значения z и (u,v). Дальше вы линейно интерполируете по экрану 1/z, u/z и v/z и вычисляете для любой точки экрана в промежутке значения u и v из этой троицы. Получаете точное значение (u,v) для любой точки экрана в промежутке. Точное. Но так как делить на 1/z долго, часто точные значения вычисляют с некоторым экранным шагом, а между ними делают интерполяцию. Но никто так делать не заставляет.
Вот пример моей работающей библиотеки (ещё, правда, не доделанной до вида библиотеки) с элементами OpenGL:
«Интерполяция не означает, что значения функции в промежутке отличаются от реальных. » по определению — означает. вопрос — насколько сильно. все ухищрения с линеаризацией — чтобы не сильно. впрочем, ошибку довольно легко контролировать
если Z — это геометрическая величина координата, которую не перевернули матрицей проективного преобразования, то:
потому я совершенно не понимаю, зачем вам u/Z линейно-интерполировать, когда можно это сделать с u. Точное значение u и v там не вычисляется, они очевидно линейны по точке пересечения экранного луча с гранью и не линейны относительно экранных координат.
если Z — это геометрическая величина координата, которую не перевернули матрицей проективного преобразования, то:
- 1/Z
- u, v
- u/Z
потому я совершенно не понимаю, зачем вам u/Z линейно-интерполировать, когда можно это сделать с u. Точное значение u и v там не вычисляется, они очевидно линейны по точке пересечения экранного луча с гранью и не линейны относительно экранных координат.
потому я совершенно не понимаю, зачем вам u/Z линейно-интерполировать
Потому что это простой и естественный способ текстурирования в пространстве экрана.
а чем оно лучше, чем u?
А тем, что нет искажений. Этот метод стандартный.
Посмотрите Шикин, Боресов «Компьютерная графика. Полигональные модели».
Посмотрите Шикин, Боресов «Компьютерная графика. Полигональные модели».
я не могу понять ваш текст.
«Дальше вы линейно интерполируете по экрану 1/z, u/z и v/z и вычисляете для любой точки экрана в промежутке значения u и v из этой троицы. Получаете точное значение (u,v) для любой точки экрана в промежутке. Точное.»
Допустим у меня 1/z точное, u/z я линейно интерполировал, как мне без деления получить u?
«Дальше вы линейно интерполируете по экрану 1/z, u/z и v/z и вычисляете для любой точки экрана в промежутке значения u и v из этой троицы. Получаете точное значение (u,v) для любой точки экрана в промежутке. Точное.»
Допустим у меня 1/z точное, u/z я линейно интерполировал, как мне без деления получить u?
Без деления — никак. Если у вас скорости хватает, то вы можете делить для каждой точки и получать точную текстуру. Если не хватает (как в Quake), тогда вы вычисляете точные значения текстуры, например, для каждых 16 точек экрана, а в промежутке делаете линейную интерполяцию (как вы в своём проекте и делали, разбивая грани, и как делает моя программа выше без разбиения граней). Кстати, с цветом так не заморачиваются и интерполируют линейно в плоскости экрана — в отличие от текстуры там такая точность не нужна.
Вот тут я ещё писал немного про текстурирование в Doom.
Вот тут я ещё писал немного про текстурирование в Doom.
1/z, кстати, вы тоже интерполируете линейно в плоскости экрана.
Sign up to leave a comment.
Как я почти рейтрейсил в реальном времени в 1997 году