Войти
ПрограммированиеФорумГрафика

Extended PSM (комментарии) (3 стр)

Страницы: 1 2 3 4 Следующая »
#30
0:46, 16 авг 2007

chiaroscuro
английский ужасен, с этим трудно поспорить )) но ты лучше пальцем покажи, я постараюсь пофиксить )

#31
20:56, 16 авг 2007

xmvlad
>но ты лучше пальцем покажи, я постараюсь пофиксить )
без проблем =)

1-я колонка в моей редакции. багфиксы приветствуются :)

The presence of shadows is one of the most
important effects to convey realism in computer-generated
image. Shadow mapping [1] is the most popular and
efficient approach to real-time shadow rendering. Image-based
nature of the algorithm is extensively exploited in real-time
applications, despite the perspective aliasing problems.
Shadow mapping creates a depth buffer from the point of
view of a light source (this depth buffer is called a shadow map
and is stored as a depth texture). A pixel in image is
said to be shadowed if its depth value, transformed to
light coordinate system, is greater than the corresponding
depth value in the shadow map.
The well-known drawback of shadow mapping is perspective
aliasing, which typically occurs when user zooms into a shadow
boundary so that individual pixels of shadow map become perceptible.
A number of researchers have tried to solve the perspective
aliasing problem. The most promising approaches for real-time
applications are TSM [2], LiSPSM [3], PSM[4], and Plane optimal
shadows[6]. Nonetheless, these approaches have their own
issues and don't provide a practical drop-in solution for high-quality
shadow rendering. TSM provides high-quality rendering, but is patented,
difficult to implement and suffers from z-acne (???what's this?).
LiSPSM provides moderate quality, but suffers from significant
degradation in worst cases. PSM is very diffucult to implement, but
it provides good quality. Plane-optimal shadows give decent
shadow quality in special cases.
The main source of artifacts -- non-linear Z bias in post-perspective
space -- is not addressed by academic researchers in practical manner,
with the only notable exception of Kozlov S. [5].

правка: исправил грмтк :)

#32
10:39, 17 авг 2007

chiaroscuro
спасибо, постараюсь поправить. )

#33
11:36, 17 авг 2007

Дык раз уж такие проблемы с англ, то может стоит выложить еще и русскую версию :)

#34
13:20, 17 авг 2007

True
С русской версией было бы гораздо удобнее.

#35
15:19, 17 авг 2007

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

#36
20:14, 17 авг 2007

приятнее то оно приятнее -- но вот как переводить термины и прочие специфические выражения? аналогов в русском-то нету

#37
21:56, 17 авг 2007

А никак, термины типа Shadow Map так и писать. Например: "Обычный Shadow Map в силу дискретности растеризации имеет проблему Depth Bias..." ну и т.д.

#38
19:53, 21 авг 2007

4 chiaroscuro и Bishop
http://www.graphicon.ru/2004/Proceedings/Technical_ru/4%5B1%5D.pdf
Там все термины и прочие специфические выражения давольно адекватно переведены. Затрунений у автора писать по русски терминалогия не вызывает.

#39
18:46, 22 авг 2007

MO
спасибо за ссылку :)

Прошло более 9 месяцев
#40
22:04, 25 мая 2008

Не понятно как рисует автор. Он находит персп. матрицу для лайта и когда приходит время рисовать он почему то рисует лайт в позиции меша!

#41
13:23, 7 июня 2008

Понятно. Новая проблема.

Делаю под OPENGL. Рисую - вроде что то рисуется. Но все верно до следующего этапа алгоритма:

      // transform from a unit cube into d3d normalized space
  D3DXMATRIX normalizedSpaceD3D( 2.0f, 0.0f, 0.0f, 0.0f,
                                                    0.0f, 2.0f, 0.0f, 0.0f,
                                                    0.0f, 0.0f, 1.0f, 0.0f,
                                                    -1.0f,-1.0f, 0.0f, 1.0f);

      D3DXMatrixMultiply(&m_LightViewProj, &m_LightViewProj, &normalizedSpaceD3D);

Переправляю под опенгл - в соответствии с докой

        // transform from a unit cube into OPENGL normalized space
  float normalizedSpace_ogl[16]={  2.0f, 0.0f, 0.0f, 0.0f,
                                                    0.0f, 2.0f, 0.0f, 0.0f,
                                                  0.0f, 0.0f, 2.0f, 0.0f,
                                                    -1.0f,-1.0f, -1.0f, 1.0f
                                                            };

      MatrixMultiply(m_LightViewProj, m_LightViewProj, normalizedSpace_ogl);

И ничего не рисуется. Что не так??? - Матрица перехода 100 пудово такая должна быть???

#42
21:20, 7 июня 2008

up

#43
23:09, 7 июня 2008

Уже сам разобрался

Прошло более 1 года
#44
10:49, 31 мая 2010

Метод годный... Использую в проекте...
Есть конечно косячки с near/far, чтото там както не так считается, излишне большой диапазон получается, но сам подшаманил в некоторых местах и вроде норм стало...

Заинтересовало кое чего из блога
http://zeuxcg.blogspot.com/2007/09/robust-unit-cube-clipping-for-shadow.html

I am not going to describe algorithm and clipping problems in details, as they are well summarized in the original paper. The only mention I will make is that at the step 11 of the algorithm, all points with w < epsilonW are clipped. This sometimes causes clipping of shadows. The solution is to modify the extents building procedure as follows: instead of throwing away points with w < epsilonW completely, just don’t compute Z bounds for them. This is a hack, and it works only because we’re doing 2D rectangle intersection while doing unit cube clipping.

The author of the algorithm knows about the problem. We discussed several approaches that lead to fixing it, and this was the best one we could come up with for now.

Фиксы были гденить? А то так не очень понятно где какая проблема и как её фиксить...

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.