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

Screenspace Raymarching (2 стр)

Страницы: 1 2
#15
19:38, 14 июля 2018

MrShoor
> SSGI поди какой нибудь
И SS Bent Normal

#16
12:26, 15 июля 2018

Suslik
> нашёл ништяк: http://www.tevs.eu/project_i3d08.html
http://gamedevs.org/uploads/quadtree-displacement-mapping-with-he… -blending.pdf ???

#17
21:37, 15 июля 2018

Suslik
> посчитал, за сколько итераций оно сходится. получается что-то около 100-500. не
> больно ли это дофига?
Я сначала тоже подумал что это дофига, но поскольку я пока еще не написал имплементацию, то не могу сказать наверняка.
Но вот MAMOHT-92 привел презентацию, и там это:

И теперь я думаю что 100-500 - очень дофига. Подозреваю у тебя там ошибки в имплементации.

#18
(Правка: 0:17) 0:16, 18 сен. 2018

сорян за некрофилию, но вот этот пейпер при прочтении вызвал вопросы
> Самый базовый алгоритм с трассировкой с постоянным шагом в мировых или view-координатах не рассматриваем за очевидностью. Также логичным
> улучшением алгоритма является трассировка в экранных координатах для сохранения плотности выборок:
> http://jcgt.org/published/0003/04/04/paper-lowres.pdf

я возможно (даже скорее всего) туплю, но там

bool traceScreenSpaceRay##numLayers(point3 csOrig, vec3 csDir, mat4x4 proj,
6 sampler2D csZBuffer, vec2 csZBufferSize, float zThickness,
7 const bool csZBufferIsHyperbolic, vec3 clipInfo, float nearPlaneZ,
8 float stride, float jitter, const float maxSteps, float maxDistance,
9 out point2 hitPixel, out int hitLayer, out point3 csHitPoint) {
10
11 // Clip to the near plane
12 float rayLength = ((csOrig.z + csDir.z * maxDistance) > nearPlaneZ) ?
13 (nearPlaneZ - csOrig.z) / csDir.z : maxDistance;
14 point3 csEndPoint = csOrig + csDir * rayLength;
15 hitPixel = point2(-1, -1);
16
17 // Project into screen space
18 vec4 H0 = proj * vec4(csOrig, 1.0), H1 = proj * vec4(csEndPoint, 1.0);
19 float k0 = 1.0 / H0.w, k1 = 1.0 / H1.w;
20 point3 Q0 = csOrig * k0, Q1 = csEndPoint * k1
сначала берутся две точки в вью-спейсе, потом проджектятся (в .w координатах после этого - расстояние до камеры),
а потом берется оригинальная точка и умножается на 1/w. Но в оригинальной точке .z - расстояние до камеры, а в проекционной -
.w - расстояние до камеры, и потому Q0.z == 1 и Q1.z == 1 и далее там dQ.z == 0 и вообще дальше всё ломается.

Это я чего-то не понимаю, или в пейпере ошибка?

#19
(Правка: 17:34) 17:31, 18 сен. 2018

Mephisto std
я просто делал примерно так:

vec3 startPoint = ...;
vec3 endPoint = ...;
vec4 startPoint4 = vec4(startPoint, 1.0f);
vec4 endPoint4 = vec4(endPoint, 1.0f);
startPoint4 /= startPoint4.z;
endPoint4 /= endPoint4.z; //то же самое получится, если после умножения на перспективную матрицу не делать perspective division

vec4 interpPoint4 = lerp(startPoint, endPoint, 0.42f); //интерполяция будет линейной в экранных координатах
vec3 midPoint = (interpPoint4 / interpPoint4.w).xyz;
пейпер не читал, просто пролистал, чтобы использовать идею.
#20
17:55, 18 сен. 2018

Suslik
т.е. если, условно, мы получили точки до перспективного деления - xyzw - то можно интерполировать между ними
и потом уже делить на .w
Да, я так и понял, меня потому и смутил код Маквайра - там довольно странная математика происходит

#21
18:02, 18 сен. 2018

Mephisto std
> т.е. если, условно, мы получили точки до перспективного деления - xyzw - то можно интерполировать между ними и потом уже делить на .w
собственно, в растеризаторе это именно так и делается

> Да, я так и понял, меня потому и смутил код Маквайра - там довольно странная математика происходит
меня как-то последнее, что волнует — это их говнокод и как там они в своих прекрасных однобуквенных переменных разбираются.

#22
(Правка: 19:44) 19:44, 8 ноя. 2018

Mephisto std
Почему такой гавно код, Нельзя написать маленькие функции наподобие ComputeViewPositionFrom, ComputeTexcoordFromViewPosition ну и т.д написали однобукванных переменных, аж голова болит

Страницы: 1 2
ПрограммированиеФорумГрафика