Size: a a a

pro.graphon (and gamedev)

2020 April 25

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
Можно и в пиксельном шейдере считать плотность тумана, чтобы было точнее, если она нелинейная (например, экспоненциальная)
источник

Уд

Умственно дебильный in pro.graphon (and gamedev)
Vitaliy ◀️TriΔng3l▶️ Kuzmin
А vertex fog — это когда для вершин рассчитывается плотность тумана, и просто интерполируется по полигону, как, например, текстурные координаты, а потом в конце пиксельного шейдера делается lerp итогового цвета и цвета тумана по этой плотности
а как в анриале сделать vertex fog? или их atmospheric fog и так вертексный?
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
Умственно дебильный
а как в анриале сделать vertex fog? или их atmospheric fog и так вертексный?
Вершинный это вообще 90-е годы, но можешь в материале рассчитать из расстояния до камеры по какой-нибудь формуле из https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glFog.xml
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
В UE4 насчёт atmospheric не знаю, но либо достаточно непростая формула из расстояния и разницы высот в пиксельном шейдере, либо вообще в шейдере лучи пускаются, в разных точках считается плотность тумана и освещение, и интегрируется это всё (так volumetric fog делают)
источник

Уд

Умственно дебильный in pro.graphon (and gamedev)
vertex fog почти бесплатный. для окулус квэст может быть в тему
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
Умственно дебильный
vertex fog почти бесплатный. для окулус квэст может быть в тему
Лучше в пиксельном шейдере считай (в вершинном шейдере точно получится только линейный туман), и точнее будет, и даже не исключено, что быстрее
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
Но тебе надо просто в конце шейдера сделать lerp(color, fogColor, fogFactor)
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
Где fogFactor это, например, f из какой-нибудь формулы (которая на глаз приятнее) со страницы https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glFog.xml
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
c это расстояние от пикселя в мире до камеры в мире
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
Только насчёт c тут два варианта есть
источник

S.

Slava . in pro.graphon (and gamedev)
Оффтоп:
Складывается ощущение, что раньше программы зависали чаще (на неопределённый срок). Т.е. сейчас тоже зависают, то повисят-повисят и их отпустят. Интересно, это субьективное восприятие или  изменилось что-то фундаментальное, что позволяет избежать зацикливания? Пока что две догадки:

1. Раньше постоянно использовали потоки в прикладном ПО, но не особо умело их синхронизировали.

2. Мб использовали какие-нибудь компактные переменные-счётчики в циклах, которые могли переполняться и бегать по кругу.
источник

AM

Aleksey Muravev in pro.graphon (and gamedev)
Vitaliy ◀️TriΔng3l▶️ Kuzmin
Лучше в пиксельном шейдере считай (в вершинном шейдере точно получится только линейный туман), и точнее будет, и даже не исключено, что быстрее
Или фулскрин квадом, как вариант
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
До плоскости вида (как раньше, когда прямая граница тумана крутится, когда ты поворачиваешься влево-вправо, это убого), или до позиции камеры (это чуть менее убого)
источник

AM

Aleksey Muravev in pro.graphon (and gamedev)
Slava .
Оффтоп:
Складывается ощущение, что раньше программы зависали чаще (на неопределённый срок). Т.е. сейчас тоже зависают, то повисят-повисят и их отпустят. Интересно, это субьективное восприятие или  изменилось что-то фундаментальное, что позволяет избежать зацикливания? Пока что две догадки:

1. Раньше постоянно использовали потоки в прикладном ПО, но не особо умело их синхронизировали.

2. Мб использовали какие-нибудь компактные переменные-счётчики в циклах, которые могли переполняться и бегать по кругу.
Всё немного сложнее, но сейчас труднее намертво подвесить систему
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
Aleksey Muravev
Или фулскрин квадом, как вариант
Барьер, чтение из Z-буфера, с MSAA придётся включать sample-rate shading для этого квада (либо резолвить на месте, что не очень хорошо с HDR, и это тоже будет почти sample-rate shading), жирно же
источник

AM

Aleksey Muravev in pro.graphon (and gamedev)
Vitaliy ◀️TriΔng3l▶️ Kuzmin
Барьер, чтение из Z-буфера, с MSAA придётся включать sample-rate shading для этого квада (либо резолвить на месте, что не очень хорошо с HDR, и это тоже будет почти sample-rate shading), жирно же
От ситуации зависит. Да и туман очень расплывчатое понятие
источник

S.

Slava . in pro.graphon (and gamedev)
Aleksey Muravev
Всё немного сложнее, но сейчас труднее намертво подвесить систему
Не, я не про времена < 95-98, когда одно приложение могло подвесить всю систему. Я, скорее, про XP уже. В XP, емнип, одно приложение не могло подвесить всю систему, но приложухи висели
источник

S.

Slava . in pro.graphon (and gamedev)
Хотя, вот, странно, смотрю: вытесняющую многозадачность в вики и написано:
> Вытесняющая многозадачность используется в большинстве современных операционных систем общего назначения[4], к примеру: Windows 9x и NT[5], Linux

Т.е. даже в 95+ винде была поддержка. Но висела та - только повод дай (по моим детским воспоминаниям)
источник

MS

Mikola Summer Duck in pro.graphon (and gamedev)
Сейчас тоже висит все, просто у винды теперь есть всплывающий диалог "это приложение не отвечает, хотите закрыть?"
источник

VK

Vitaliy ◀️TriΔng3l▶️ Kuzmin in pro.graphon (and gamedev)
А висели именно приложения, и именно виндовые, а не дрова или досовские проги?
источник