Освітлення у світі Мікракрафтів

Minecraft - це гра, яка багато в чому заснована на мапі висоти і використовує цю інформацію про heigtmap, щоб залити світлом світло. З мого розуміння, найвищою точкою карти висоти є кінець області, на яку впливає сонячне світло. Все вище, що висвітлюється сонячним промінням, усе нижче, ніж щойно, впливає світло поблизу в радіусі 8 блоків.

Таким чином, якщо у вас є плаваючий острів на вершині вашого світу, все нижче, що буде розглядатися по суті, є печерою. Коли два вогні впливають на одну і ту ж точку, яскравіше світло виграє (не впевнений у цьому).

Так чи інакше, існує декілька проблем із моделлю освітлення шахтних кораблів: насамперед, якщо у вашому світі немає карти висоти, стає складніше зрозуміти, що саме повинно випромінювати сонячне світло, а що ні. Простим способом було б припустити, що світ є (в моєму випадку) плаваючою скелею, а потім проїжджати кожну вісь з обох напрямків і з'ясовувати, де починається і закінчується скеля. Але це не повністю усуває проблему, оскільки вм'ятини в скелі не повинні знаходитися в темряві.

Сам Minecraft кешуватиме світлу інформацію у своїх шматках разом із інформацією про матеріал блоку. Таким чином, лише якщо світ модифікований, освітлення доводиться оновлювати. На жаль, процес оновлень все ще досить повільний і при швидких змінах світла видно відставання освітлення. Це особливо вірно, якщо багато блоків змінюється (TNT, захід сонця тощо), і ви не працюєте з найшвидшим комп'ютером (або Java на Mac).

З мого ще обмеженого розуміння 3D-графіки, що освітлює такий світ, як Minecraft, не повинно бути найбільшою проблемою. Як би ви вирішили цю проблему?

Я думаю, що основні вимоги до освітлення у світі вокселів були б

1. оновлення досить швидко, щоб це могло статися в одному кадрі. Можливо, можна зробити освітлення в графічному пристрої та завантажити змінену інформацію про світло в основну оперативну пам'ять.
2. інформація про світло повинна бути швидко доступною для основної логіки гри, тому не повністю заснована на графічному пристрої: міркування: світло впливає на ріст трави, нерест монстрів тощо.
3. світлові оновлення повинні бути локальними для шматка або мати якийсь інший ліміт, щоб не потрібно було світити весь світ, який може бути дуже великих розмірів.

Основна ідея полягала б у тому, щоб зробити оновлення світла швидким, не обов'язково красивішим. Для загальних поліпшень продуктивності легкого відображення можна легко додати SSAO поверх того, що має спричинити набагато приємніші світи.

Освітлення в Minecraft обчислюється асинхронно і викладається в геометрію. Це не робиться в режимі реального часу.

Кожен воксель зберігає освітлення для цього вокселя, ймовірно, як один байт (або 2, виїмка використовує шаруватий підхід, щоб зробити можливим цикл денного та нічного). Є лише 16 рівнів світла. Щоб запалити світ, Minecraft робить 2 проходи. Один для сонячного світла, а інший для розповсюдження або переливання світла в печери тощо. Освітлення локалізується тому, що будь-яке джерело світла може поширювати своє світло не більше 16 блоків. Вода та лава працюють майже однаково.

Більше інформації розміщено на його блозі: http://notch.tumblr.com/post/434902871/per-request-this-how-the-new-lighting-will-work

Ви не можете використовувати GPU Render для текстурування та подвійного буферування результатів, щоб у вас завжди була доступна обчислена інформація освітлення для повторного зчитування кожного кадру?

Як ви б організували ці дані для освітлення, залежить тільки від вас, але я не розумію, чому це не має бути першим варіантом розслідування, якщо все, що ви хочете зробити, - це покращити швидкість роботи вашого алгоритму освітлення ..?

Візуалізація в реальному часі, здається, має трохи любовного зв’язку з Minecraft. Був коментар щось про те, як вони ще не з'ясували освітлення .., але ви, можливо, хочете бути в курсі подальших розробок / посилань.

http://www.realtimerendering.com/blog/?s=minecraft