Тобто у кеші треба зберігати тали розміром Nx текселей, які на геометрії у світовому просторі мають різну площу. Наприклад якщо тайл нульового Клода має площа 1метр Х 1метр, те тали Клода lod буде мати площа (2^lod) метрів Х (2^lod) метрів.

Так само необхідна ще одна текстура, що покриває всю геометрію як й основна текстура, indirectional texture, її ще називають текстура індексів, що несе інформацію про розташування тайлів у кеші і їх лод. Ця текстура має дозвіл (M/N) x (M/N), тобто кожен піксель це один тайл. Доступ до цієї текстури здійснюється по текстурних координатах геометрії.

У такий спосіб при відрисовці геометрії, спочатку читається піксель із текстури індексів, і по його значенню розраховується координати для читання з текстури кеша, відповідно читаємо піксель із тала в кеші.

Основна текстура (повний набір тайлів) може бути дуже більших розмірів, тому має сенс зберігати її на диску, запакованої алгоритмами такими як JPEG2000 або подібні, які при бажанні можна розпаковувати прямо в піксельнім шейдері. Використати двух-рівневий кеш і т.д. Оптимізувати можна нескінченно.

4.2 Попередні підходи до текстурування великих ландшафтів

Попередні підходи до текстурування великих ландшафтів здійснювалися за принципами:

- заливання областей однією текстурою - тайлінг і тайслет;

- альфа-змішування текстур;

- вивід на екран щодо невеликої частини ландшафту біля гравця.

Плюси:

- невелика кількість текстур (невеликий об'єм даних);

- відносна простота текстурування.

Мінуси:

- обмежена кількість текстур (тайлів) приводить до складностей в одержанні потрібного малюнка, можливі комбінації завжди обмежені;

- багато повторюваного малюнка на ландшафті;

- обмеження в геометрії (наприклад, тільки регулярна сітка) або навпаки, необхідність розбивки геометрії для формування тайлсетів з різними тайлами.

Що буде, якщо задумати використати одну текстуру на весь ландшафт?

Плюси:

- не буде тайлінгу й тайлсетів;

- не буде необхідності робити альфа змішування різних текстур для формування кінцевого малюнка в рантаймі;

- художник зможе просто малювати будь-яку частину ландшафту;

- візуально реалізм створюваного ландшафту може бути збільшений у рази;

- геометрія ландшафту може бути представлене як регулярною сіткою, так і будь-яким мешем;

- не буде необхідності бити геометрію для цілей текстурування.

Мінуси:

- об'єм текстури для всього ландшафту буде займати не мало місця;

- для її підготовки знадобляться спеціальні інструменти й потужні комп'ютери.

Спробуємо вивести ландшафт із унікальним малюнком.

Для цього необхідно завантажити в GPU текстуру високого розрішення всього ландшафту, зрозуміло, з усіма її рівнями деталізації (mipmaps або лодами) і вивести всю геометрію ландшафту. GPU сам вибере потрібний лод для растеризації конкретного пікселя на екрані (або кілька лодів, залежно від установок). Наприклад, для ближнього до камери пікселя буде обраний піксель із деталізованого лоду, для дальнього - навпаки.

Все це зрозуміло, але ось приклади і підрахунки необхідних об'ємів відеопам'яті.

4.3 Підрахунок необхідного об’єму відеопам'яті для растеризації

Нехай текстура ландшафту буде мати розмір 4096 на 4096 пікселів. Перше обмеження – це максимально підтримуваний розрішення текстури, що може обробляти GPU. Далеко не всі GPU можуть працювати з розрішенням 4096 на 4096 пікселів (справа навіть не 4096, тому що завжди можна підібрати таке розрішення, що не буде підтримуватися навіть найсучаснішою відеокартою). Ця проблема може бути вирішена шляхом розрізування вихідної текстури на частині. Розрізування може привести до необхідності поділу геометрії в місцях стику різних текстур, щоб уникнути спроби накладення на різні частини одного трикутника двох і більше текстур (безсумнівно, це ускладнить геометрію, або внесе додаткові правила текстурування). Друга проблема - це об'єм пам'яті займаний текстурою. Для незжатої текстури в даному випадку це:

4096 * 4096 * 4 = 64 Мб (при 32 бітах на піксель)

З лодами текстура займе більше 85 Мб. А що робити, якщо розмір вихідної текстури не 4096, а 8192 на 8192 пікселів? Це вже 341 Мб із усіма лодами. А якщо більше? Наприклад, 1 квадратний км із розрішенням 1 піксель на 10 см. буде покривати мегатекстура з розрішенням 10000 на 10000 пікселів. Але ж 1 піксель на 10 см. - це далеко не сама бажана якість!

Само-собою зрозуміло, що при таких об'ємах GPU не справиться із задачею. Використання стиску текстури не вирішить проблему кардинально, а лише змінить максимально можливе розрішення.

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

GPU для растеризації далекого пікселя візьме лод текстури більше простий, чим для растеризації ближнього пікселя, але в пам'яті GPU будуть перебувати всі лоди.

А навіщо тоді вантажити лод високої деталізації в GPU при растеризації далекого пікселя? Як зробити так, щоб зайві лоди не вантажилися?

4.4 Реалізація мегатекстури

При растеризації далеких пікселів в GPU бажано не завантажувати деталізовані лоди (вони не використаються для растеризації), а для растеризації ближніх пікселів усе з точністю навпаки.

Наприклад, гравець перебуває в центрі ландшафту, тоді рівні деталізації текстури ландшафту, необхідні й використовувані GPU для растеризації, будуть виглядати приблизно так:

Рисунок 4.4.1 – Рівні деталізації текстури.

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

Рисунок 4.4.2 - Рівні