English Новый сайт

Расширенный поиск

[ Новые сообщения · Пользователи · Правила ]
Страница 9 из 10«1278910»
Форум » SpaceEngine » Состояние разработки » SpaceEngine изнутри (обуждение особенностей движка)
SpaceEngine изнутри
SpaceEngineerДата: Воскресенье, 13.12.2015, 01:43 | Сообщение # 121
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Всё там оптимально. Просто эффекты стали сложнее. Например, устранение тайлинга. Измените в шейдере tg_common.glsl макрос TILING_FIX_MODE на 1, и будет вам как в 0.971.
Кроме того, в текущей версии в настойках графики появился параметр Loadning speed - выставляйте как вам нравится.


1002ndДата: Вторник, 15.12.2015, 14:22 | Сообщение # 122
Нет аватара
Наблюдатель
Группа: Пользователи
Пират
Сообщений: 10
Награды: 0
Статус: Offline
Спасибо за разъяснения...) А ещё насчёт geforce....почему сейчас в этой версии надо убирать потоковую оптимизацию? Это исправится со временем?)
SpaceEngineerДата: Среда, 16.12.2015, 12:34 | Сообщение # 123
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Цитата 1002nd ()
А ещё насчёт geforce....почему сейчас в этой версии надо убирать потоковую оптимизацию? Это исправится со временем?)

Если б я знал. Скорее всего, потому что OpenGL не любит многопоточность, и NVidia эту нелюбовь таки добила. Попробую избавиться от неё вообще, посмотрим как будет работать.


RomFilДата: Пятница, 08.01.2016, 21:40 | Сообщение # 124
Нет аватара
Строитель Миров
Группа: Пользователи
Пират
Сообщений: 703
Награды: 2
Статус: Offline
а можно ли где небудь найдти рельефную карту высот (такого маштаба как карты в гугл планета) всей планеты? я искал как то заготовку для wip в spin tires но нашлась только для московской области
KludДата: Воскресенье, 10.01.2016, 14:51 | Сообщение # 125
Космический пилот
Группа: Пользователи
Российская Федерация
Сообщений: 117
Награды: 4
Статус: Offline
Цитата RomFil ()
а можно ли где небудь найдти рельефную карту высот (такого маштаба как карты в гугл планета) всей планеты?


Здесь можно взять по участкам: Link.
RomFilДата: Вторник, 12.01.2016, 11:31 | Сообщение # 126
Нет аватара
Строитель Миров
Группа: Пользователи
Пират
Сообщений: 703
Награды: 2
Статус: Offline
это я видел мне нужна в формате картинки

вот сейчас ещё раз вбил в поиск и нашёл некую программу OziExplorer3D, потом как нибудь попробую
markovalex95Дата: Вторник, 09.02.2016, 18:37 | Сообщение # 127
Нет аватара
Наблюдатель
Группа: Новички
Пират
Сообщений: 3
Награды: 0
Статус: Offline
Добрый день! Я поражен вашей работой, недавно узнал про Space Engine и я просто в восторге.
Я давно размышлял по поводу написания своего относительно "движка" для рендера космических пространств с целью самообразования и повышения скиллов. Я почитал этот форум, статью на хабре, пытаясь понять, как же эта магия работает. Что-то я понял, что-то не очень, надеюсь Вас не затруднит ответить на мои вопросы biggrin

1. Как я понял, вы храните все объекты иерархически в виде октодерева. Корень галактика (?), в них области, в областях области и так далее, до звезд, их планет и лун? Кстати, оффтоп: почему везде в 3D графике используют именно октодеревья, ведь куб делится не на 8, а на 9 меньших кубов?

2. В вершинах дерева находятся объекты (галактики, звезды) с рядом параметров для генерации потомков, я правильно понимаю? Вблизи вершина рендрится моделью (хотя это отдельная сложность, пусть это пока "модель"), на больших расстояниях - спрайтами, а совсем далеко - не отображается вовсе? (Яркость спрайта зависит от расстояния и начальной яркости объекта? А яркость - от уровня вложенности узла?). И вот с рендером мои главные непонятки, при переходе от неких общих рассуждений к конкретным.
Выбираются видимые объекты на основе яркости и дальности. Яркость берется из данных узлов деревва? А как узнать, какие узлы рассматривать? К примеру, мы находимся в какой-то области галактики, какой-то узел. Надо взять на определенную глубину вложенности дочерние узлы? Или родительские тоже как-то рассматриваются?
Ну, допустим, объекты определены. Но как же их отрендрить? Их координаты заданы относительно родительских узлов. Как получить приемлемые float координаты, с которыми уже может работать OpenGL, если они огромны? Делить на какие-то константые значения, зависящие от уровня узла? Кстати, вы же храните координаты в виде 128 битных чисел с фиксированной запятой? Тогда получается деление (если оно все же имеет место быть), можно делать быстрым сдвигом.

3. В продолжение вопроса про координаты - как реализуется буфер глубины, если в кадре объекты с расстояними отличающимися на многие порядки? Как-то в несколько проходов рисуете?

3. По поводу планет. Ну, на эту тему в интернете есть много литературы, она не такая неизученная, но все же пару вопросов задам. Вы генерируете поверхность чисто с использованием вершинного шейдера? Целиком на ГПУ? Там используете всяческие шумы Перлина и подобное? А как работает ЛОД? На разных уровнях применяете (точнее, накладываете? ) разные шейдеры?
Для крупномасштабных структур, для средних, мелких. А как делается разное разбиение поверхности? Какие-то заранее имеющиеся базовые поверхности с разным разбиением? Тесселяция?

Кстати, а возможно ли использовать воксели для целей рисования планет? Или это слишком ресурсоемко?

Надеюсь, вас не затруднит ответить на мои вопросы, очень интересно узнать больше технических подробностей о необычном движке.
RattusДата: Вторник, 09.02.2016, 19:34 | Сообщение # 128
Строитель Миров
Группа: Модераторы
Российская Федерация
Сообщений: 663
Награды: 4
Статус: Offline
Цитата markovalex95 ()
ведь куб делится не на 8, а на 9 меньших кубов?
Мы, конечно, не специалистЪ в геометрии и теории графов, но на 8 кубов куб вроде как делится несколько более равномерно... rolleyes


"Ннапыльн%х тpапинкахъ далиокихъ плонеттъ астануцца нашшы погадкиъ!" (ЙожЪ)
markovalex95Дата: Среда, 10.02.2016, 11:55 | Сообщение # 129
Нет аватара
Наблюдатель
Группа: Новички
Пират
Сообщений: 3
Награды: 0
Статус: Offline
Цитата Rattus ()
Мы, конечно, не специалистЪ в геометрии и теории графов, но на 8 кубов куб вроде как делится несколько более равномерно...


Точно, я немного затупил wacko
SpaceEngineerДата: Четверг, 11.02.2016, 16:02 | Сообщение # 130
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Цитата markovalex95 ()
1. Как я понял, вы храните все объекты иерархически в виде октодерева. Корень галактика (?), в них области, в областях области и так далее, до звезд, их планет и лун?

Не все. Для каждого объекта свое собственное дерево. Вселенная (10 уровней) - в листьях находятся галактики. Галактика (3-5 уровней) - в листьях туманности, звёздные скопления и октодеревья звёзд. Октодеревья звёзд - 10 уровней, в листьях звёздные системы. В звёздных системах уже деревья не используются, т.к. там всё движется по орбитам.

Цитата markovalex95 ()
Кстати, оффтоп: почему везде в 3D графике используют именно октодеревья, ведь куб делится не на 8, а на 9 меньших кубов?

Не везде, чаще юзают бинарные деревья, их проще сделать динамически перестраиваемыми.

Цитата markovalex95 ()
2. В вершинах дерева находятся объекты (галактики, звезды) с рядом параметров для генерации потомков, я правильно понимаю? Вблизи вершина рендрится моделью (хотя это отдельная сложность, пусть это пока "модель"), на больших расстояниях - спрайтами, а совсем далеко - не отображается вовсе? (Яркость спрайта зависит от расстояния и начальной яркости объекта? А яркость - от уровня вложенности узла?). И вот с рендером мои главные непонятки, при переходе от неких общих рассуждений к конкретным.
Выбираются видимые объекты на основе ярк

Под "вершиной" вы понимаете лист или нод (узел)? Лист - это самый маленький кубик, содержит только сами объекты, нод же содержит 8 вложенных нодов-потомков, либо 8 листов. Звёздные и вселенские октодеревья у меня немного другие - там каждый нод содержит звёзды, а листьев нет.
Вблизи объект (галактика, туманность, звёздная система) рендерится моделью, да, вдали - спрайтом, на большом расстоянии не рендерится уже сам узел/лист дерева, и все его потомки.

Цитата markovalex95 ()
Выбираются видимые объекты на основе яркости и дальности. Яркость берется из данных узлов деревва? А как узнать, какие узлы рассматривать? К примеру, мы находимся в какой-то области галактики, какой-то узел. Надо взять на определенную глубину вложенности дочерние узлы? Или родительские тоже как-то рассматриваются?

Обход дерева начинается с корня естественно. В каждый момент камера находится во всех 10 вложенных друг в друга узлах (они ведь рекурсивно разбиваются, без промежутков). Каждый потомок проверятся на пересечение с фрустумом камеры и на видимость по расстоянию. Видимость по расстоянию рассчитывается исходя из условия, что самый яркий объект узла должен иметь видимую яркость больше минимальной (1/255 например, если цветовое пространство линейно). Тогда весь узел добавляется в рендер-лист и рендерятся все его объекты спрайтами (это быстро, даже если их 10 тысяч). Узлы в галактическом и звёздном октри организованы так, что потомки (меньшие кубики) содержат объекты, светимость которых меньше, чем светимость объектов узла-предка. Достаточно при старте программы построить табличку из 10 значений светимости (или абсолютной звёздной величины), и далее её использовать для генерации объектов в узлах. Например, узлы звёздного окти 9 уровня содержат звёзды с M от +20 до +14.9999, 8 уровня от +15 до +7.9999, и т.д. Надо, используя функцию светимости (зависимость количества звёзд от светимости), так разбить весь интервал светимостей на 10 частей, чтобы в каждом узле дерева было примерно одинаковое количество звёзд (не забыв учесть, что объём каждого следующего уровня в 8 раз меньше). Такое разбиение по светимостям позволяет, отбросив какой-то узел по расстоянию, отбросить и все его потомки, т.к. объекты в них гарантированно не будут видны, т.к. они тусклее родителя.

Цитата markovalex95 ()
Ну, допустим, объекты определены. Но как же их отрендрить? Их координаты заданы относительно родительских узлов. Как получить приемлемые float координаты, с которыми уже может работать OpenGL, если они огромны? Делить на какие-то константые значения, зависящие от уровня узла? Кстати, вы же храните координаты в виде 128 битных чисел с фиксированной запятой? Тогда получается деление (если оно все же имеет место быть), можно делать быстрым сдвигом.

Координаты заданы относительно узлов, хранятся в float для обработки на ЦПУ, а вершинные буферы для OpenGL естественно тоже float. Этого достаточно, камера же считается в относительных координатах, используя преобразования в fp64.64. Т.е. при рендере галактики выичтаем из глобальных координат камеры (которые fp64.64) рассчитанные глобальные координаты центра галактики (fp64.64), переводим в double, рассчитываем матрицу трансформации OpenGL, и только потом переводим её во float и передаём в шейдер, рендерящий спрайты. Почему координаты галактики хранятся в float и не fp64.64? Gjnjve что это на самом деле не нужно. Галактика стоит на месте, поэтому перевод из float в fp64.64 даёт всегда один и то же результат. То же самое для звёзд. Для увеличения точности координаты звёзд (float) хранятся относительно центра звёздного нода, координаты нода - относительно центра галактики (float), координаты галактики (float) - относительно центра галактического нода, а его координаты - относительно "центра Вселенной" (опять float). На каждом уровне считается глобальная координата текущего объекта (нода , галактики и т.п.) относительно центра Вселенной в fp64.64. Потом координаты камеры вычитаются их этого, и получается небольшое double/float число, которое тем не менее имеет точность порядка 3 мм, где бы камера не находилась. От fp64.64 математики по сути нужно только преобразование в double/float и обратно, и сложение/вычитание.

Цитата markovalex95 ()
3. В продолжение вопроса про координаты - как реализуется буфер глубины, если в кадре объекты с расстояними отличающимися на многие порядки? Как-то в несколько проходов рисуете?

До текущей версии (0.974) перед рендером каждой планеты (если их несколько в кадре) буфер глубины очищался. Точности хватает, если плоскости отсечки ставить вплотную к дальнему и ближнему краю планеты. Правда когда камера уже "в планете" (в атмосфере, ниже гор и т.п.) приходилось ближнюю плоскость ставить на минимальное расстояние 10 метров, меньше - уже горы начинали z-файтить. Отсюда такое ограничение высоты коллизии с рельефом, и внезапно появляющийся z-файтинг воды на бреговой линии (когда камера пересекала границу модели планеты и ближняя плоскость перескакивала на 10 метров).
Разбиение z-буфера на части делало невозможным глобальные z-эффекты, такие как туман между планетами (протопланетный и аккреционный диск), простой способ правильного рендера линий орбит и т.п. Поэтому всё это не было до сих пор реализовано.
Потом я реализовал логарифмический z-буфер, но производительность с ним не радовала, поэтому он был по умолчанию отключен в настройках.
А теперь я реализовал обратный float z-буфер, и всё стало замечательно (правда на интеле он всё ещё не поддерживается). Теперь дорога всем z-эффектам открыта (в т.ч. deferred-шейдингу), например я сразу сделал коррекное пересечение планет с линиями их орбит.

Цитата markovalex95 ()
3. По поводу планет. Ну, на эту тему в интернете есть много литературы, она не такая неизученная, но все же пару вопросов задам. Вы генерируете поверхность чисто с использованием вершинного шейдера? Целиком на ГПУ? Там используете всяческие шумы Перлина и подобное?

Да, только не в вершинном, а в пиксельном. Тайлы квадродерева планет - это меш, построенный по текстуре (карте) высот, с приложенной к нему текстурой нормалей (построенной по той же карте высот) и текстурой цвета. Текстуры могут грузиться с диска (Земля, Луна и другие реальные планеты), или генерироваться процедурно, чем и занимается специальный пиксельный шейдер. Шумы всякие разные используются, да.

Цитата markovalex95 ()
А как работает ЛОД? На разных уровнях применяете (точнее, накладываете? ) разные шейдеры?
Для крупномасштабных структур, для средних, мелких.

Нет, шейдер один и тот же, ему пофиг какого размера текстуру генерировать. Он принимает индексы узла квадродерева, рассчитывает по ним 3D координаты каждого пикселя, и рендерит шумы в текстуру. Разрешение текстуры задаётся вне шейдера естественно, а при создании самой текстуры OpenGL.

Цитата markovalex95 ()
А как делается разное разбиение поверхности? Какие-то заранее имеющиеся базовые поверхности с разным разбиением? Тесселяция?

Нет, никакой теселляции, обычный Continuous LOD на "надутом в шарик" кубе. Теселляция, или, ещё лучше, реймарчинг - это следующий шаг, дандшафтный движок 2.0.

Цитата markovalex95 ()
Кстати, а возможно ли использовать воксели для целей рисования планет? Или это слишком ресурсоемко?

Можно и даже нужно. Без вокселей не сделать например пещеры. Но воксели - это сокрее способ генерации, для рендера их превращают в обычные треeгольники. Хотя со всё возрастающими возможностями реймарчинга уже вполне можно рендерить воксели непосредственно (и даже не хранить их нигде, а генерировать 3D шумы на лету). См. shadertoy.com


yahorizon2011Дата: Четверг, 11.02.2016, 16:42 | Сообщение # 131
Строитель Миров
Группа: Пользователи
Пират
Сообщений: 793
Награды: 2
Статус: Offline
Цитата SpaceEngineer ()
это следующий шаг, дандшафтный движок 2.0.

И какие красивые фичи принесет нам этот усовершенствованный движок?


Phenom IIx6 3870 МГц; Radeon HD 7870 OC 2048 Мб; RAM 6 Гб; Win 7 64, видеодрайвер Radeon 16.4.1

"И страшным, страшным креном
к другим каким-нибудь
неведомым вселенным
повернут Млечный Путь."
markovalex95Дата: Четверг, 11.02.2016, 17:30 | Сообщение # 132
Нет аватара
Наблюдатель
Группа: Новички
Пират
Сообщений: 3
Награды: 0
Статус: Offline
Огромное вам спасибо за столь подробный ответ! Многое стало на свои места.
Цитата SpaceEngineer ()
Надо, используя функцию светимости (зависимость количества звёзд от светимости), так разбить весь интервал светимостей на 10 частей, чтобы в каждом узле дерева было примерно одинаковое количество звёзд (не забыв учесть, что объём каждого следующего уровня в 8 раз меньше)


Получается, что в узлах ... хм... меньшей вложенности меньше звезд, а в потомках больше?

Цитата SpaceEngineer ()
На каждом уровне считается глобальная координата текущего объекта (нода , галактики и т.п.) относительно центра Вселенной в fp64.64. Потом координаты камеры вычитаются их этого, и получается небольшое double/float число, которое тем не менее имеет точность порядка 3 мм, где бы камера не находилась.


Вот тут немного непонятно. Вы, получается, получаете координату текущего объекта относительно камеры? Я тут прикинул, получил не очень хорошие вещи. Допустим, галактические масштабы. Если рассотяние от камеры до объекта сравнимо с размерами Млечного Пути 100 000 св. лет, что примерно 9*10^17м, то это уже совсем не небольшие числа. Для double точность примерно 128м, а во float это число вообще выглядит как 900000020235812864 (вместо 900000000000000000). Понятно, что на таких расстояниях нам и не нужна точность (для рендера), но все же интересно, как вы получили точность порядка 3мм. Скорее всего, я Вас не так понял.

Тут еще один вопрос возник когда рендрите спрайтами объекты, чем дальше, тем визуально спрайт (при перспективной проекции), разумеется меньше. И на очень больших расстояниях... Поэтому увеличивать надо размер спрайта, чтобы визуально размер сохранять? Кстати, какое у вас дальнее расстояние отсечения у камеры?
SpaceEngineerДата: Пятница, 12.02.2016, 13:53 | Сообщение # 133
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Цитата markovalex95 ()
Получается, что в узлах ... хм... меньшей вложенности меньше звезд, а в потомках больше?

Наоборот, цель как раз сделать так, чтобы было примерно одинаково.

Цитата markovalex95 ()
Для double точность примерно 128м, а во float это число вообще выглядит как 900000020235812864 (вместо 900000000000000000). Понятно, что на таких расстояниях нам и не нужна точность (для рендера), но все же интересно, как вы получили точность порядка 3мм. Скорее всего, я Вас не так понял.

Ну да, для далёких от камеры объектов точность не нужна. На расстоянии диаметра галактики будут видны только туманности да самые яркие звёзды, но их же не надо рендерить с точностью позиционирования на экране 0.000001 пикселя. Точности float вполне хватает.

Цитата markovalex95 ()
Тут еще один вопрос возник когда рендрите спрайтами объекты, чем дальше, тем визуально спрайт (при перспективной проекции), разумеется меньше. И на очень больших расстояниях... Поэтому увеличивать надо размер спрайта, чтобы визуально размер сохранять?

Размер спрайта вычисляется в шейдере, просто по видимой яркости объекта. Яркость на экране пропорциональна площади спрайта, т.е. квадрату радиуса, а с расстоянием до объекта убывает как 1/r2. Поэтому радиус просто обратно пропорционален расстоянию. Всё просто.

Цитата markovalex95 ()
Кстати, какое у вас дальнее расстояние отсечения у камеры?

Бесконечное. Дальняя плоскость не используется.


equeimДата: Суббота, 30.07.2016, 15:48 | Сообщение # 134
Космический пилот
Группа: Пользователи
Российская Федерация
Сообщений: 94
Награды: 1
Статус: Offline
SpaceEngineer, что ты думаешь по поводу Vulkan? И вообще, насколько сильно архитектура SE завязана на OpenGL, сложно ли добавить поддержку других графических API (если предположить, что ты уже с ними знаком)?
SpaceEngineerДата: Суббота, 30.07.2016, 18:04 | Сообщение # 135
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
На OpenGL - целиком и полностью. А как иначе?
Vulkan - надо подождать еще пару лет, пока всё утрясётся и он станет стандартом наравне с OpenGL и DirectX.


Форум » SpaceEngine » Состояние разработки » SpaceEngine изнутри (обуждение особенностей движка)
Страница 9 из 10«1278910»
Поиск:

>