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

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

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

Отже, що було б найкращим способом завантажувати деталі землі (рельєф та заземлені об'єкти) навколо точної точки?
Я вже хоч і на два рішення, але в обох є слабка сторона:

1. Розрізання сфери квадратними шматками.

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

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

2. Починаючи з ікосаедра.

Тут я міг би просто збільшити трикутну tessellation навколо позиції гравця, коли він / вона наближається.

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

Я використовую для цього C ++ / OpenGL, тому головне для створення та завантаження тут - вершини, що представляють рельєф поверхні та колір / текстуру.

Гаразд, тому я написав це тут:

http://www.maths.kisogo.com/index.php?title=Notes:Spherical_coordinate

(Мені була потрібна математична оцінка, а також вона дуже довга)

Застосування документа

Документ починається з введення поняття багатозначного, багатозначне - це ця річ, де шматки його "гомеоморфні" (в основному: те саме, що) шматки R ^ n (R ^ 2 - х / у площині, як ви могли б знаю)

Діаграма охоплює деякі (можливо, всі, хоча у випадку сфери вона НЕ МОЖЕ охоплювати всіх) колектора.

У статті я розробив 4 діаграми для сфери, що зберігає кути, тобто вони тримають регулярну відстань.

Як ви дізналися, давати координати точкам на кулі насправді досить складно! Ми робимо натомість (хоча на колі в прикладі) - даємо кожній точці координату вигляду (i, x, y), де i є число між 1 і 6 для сфери, 1 і 4 для кола. Це номер діаграми.

X і y посилаються на кути на цій діаграмі (або просто x, якщо це коло).

6 діаграм сфери - це верхня / нижня півкулі, ліва / права і передня / задня півкулі.

Координати

Тепер ви можете надати кожній точці «приємну» координату, яка добре поводиться. У математичному плані домени діаграм - це "відкриті" карти, це означає, що існує якесь додатне число, таке, що куля навколо кожної точки також є у множині. Наприклад діапазон (0,1) (множина, що містить x, якщо 0 <x <1) відкрита, візьміть будь-який p в (0,1) (наприклад 0,001), тоді є число (наприклад, 0,0005) таке що будь-яка точка в межах 0,0005 0,001 також знаходиться в (0,1).

Це означає, що ви можете передавати вказівки через діаграми.

Зараз у графіках, які ми розробляємо, є 45 градусів перекриття. Це означає , що якщо у вас є функція в точці з координатами (я, х, у) можна БЕЗПЕЧНО вказати точки виду (я, х + а, у + б) до тих пір, aі bзнаходяться між -45 і +45 (в градусах)

Будь-яку точку форми (i, x + a, y + b) можна без проблем перетворити на точку в "нормальному" 3-мірному просторі.

Впровадження

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

Ви також можете повністю відкинути відповіді "як створити звичайну сферу", тому що все, що вам потрібно зробити, це зробити 6 площин і переконатися, що краї їх вирівнюються (що тривіально), і результат:

У вас буде приємна сфера з простими у використанні координатами

Будь-які питання, будь ласка, прокоментуйте, я намагався припустити незначні попередні знання. Я також новачок у навчанні людей

Як ви вже показали, існує ряд рішень цієї проблеми, але жоден на 100% ідеальний. Сфери хитрі.

На основі куба

Один розповсюджений маршрут, використовуваний Spore та цілком ймовірними іншими іграми (хоча важко сказати напевно, не заглядаючи під кришку), - спроектувати сферу на куб та використати квадратну сітку на кожній грані куба.

(Про це розповідають у коментарях вище Alec Teal та dnk drone.vs.drones)

( Зображення з цієї публікації, де описано використання кубічного зображення для LoD )

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

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

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

На основі ікосаедра

Моїм улюбленим підходом була б ікосаедральна версія, яку ви описали, оскільки це робить пікове кутове викривлення якомога меншим. Якщо трикутна сітка зазвичай має шість трикутників, що зустрічаються під кутом 60 градусів, вершини ікосаедра мають 5 трикутників, що зустрічаються під кутом 72 градуса. Отже, кожен має менше спотворень, ніж квадрати на прикладі куба.

Це не настільки звична територія, як квадрати кубової версії, імовірно, тому вона не настільки популярна. Для роботи потрібно трохи більше математики.

Визначення сусідніх точок не так вже й складно, як може здатися. Будь-яка геодезична сфера на основі ікосаедра може бути сплющена на звичайну трикутну сітку:

І звичайною трикутною сіткою можна вважати квадратну сітку, про яку йдеться тут .

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

Редагувати:

Якщо ви використовуєте геодезичний клас I класу, ви можете розмотати свої планети у п’ять прямокутних діаграм для ефективного зберігання фрагментів / текстур / висот, подібних до шести квадратних діаграм, які ви б використали для зберігання на кубі версії:

(Це може допомогти вирішити проблему, яку викликає нечітка логіка в іншій відповіді. Це теж можливо, але трохи складніше для геодезики II класу. Я не досліджував клас III)

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

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

Ікосасфера забезпечує більш рівномірну сітку та її легко піддавати tessellate, але створює проблеми при спробі скласти текстури та карти висоти, які вам потрібно буде кешувати, і не буде дуже компактним чи простим таким чином.

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

Дивіться статті Шона О'Ніла про створення процесуальної всесвіту на Гамасутра:
- Частина 1 Шум Перліна та фрактальний броунівський рух для мап висоти та текстур.
- Частина 2 Алгоритм ROAM для процедурної сітки з DLOD для генерування планети. Страждає від продуктивних проблем. Не рекомендується, але корисно для навчальної цінності.
- Частина 3 Розглядає проблеми з масовими масштабами, оптимізацією та проблемами з плаваючою точкою. В основному стосується масштабу Всесвіту, але також застосовно до планет при переході від масштабів світлових років до сантиметрів, якщо ви хочете. <- див. статтю зокрема
- Частина 4 Обговорюють реалізацію Quad-сфери з відрізним (квадровим деревом) DLOD для генерування планети

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