Comments 16
Прошу прощения, вношу небольшие правки в репозиторий, код будет доступен в течении пары часов
Залил код, так же подготовлю инструкцию по реинтеграции графических ассетов. Но если кому-то очень хочется весь исходный проект - пишите в личку, может залью его на облачное хранилище
Выложил так же WebGL билд, что бы можно было повертеть планеты не закрывая браузера
Под каждый слой создаем (точнее - активируем из пула) новую камеру, и вешаем на нее коллбек, чтобы перед началом ее рендеринга выставить объектам слоя нужные позиции и масштабы
А это происходит каждый кадр? Двигание туда-сюда? Это как то можно оптимизировать, если ничего не происходит, или почти ничего не происходит? Eсли ничего не поменялось, можно как то кешировать картинку с камеры и не перерендеривать?
А как слои с камер объединяются?
Да, в коде проекта рендер-системы всех четырех методов выставляют все объекты каждый кадр. Более того, многослойная рендер-система одним и тем же объектам выставляет разные параметры, когда они рендерятся разными камерами, если они попадают сразу в несколько слоев. Разумеется здесь есть огромный потенциал для оптимизации, но что бы она была эффективна нужно знать специфику проекта. Обратной стороной таких оптимизаций является резкое повышение сложности. Тут уже нужно следить за объектами, что поменялось а что нет. Или ничего не поменялось, но камера уехала или повернулась.
Что касается объединения слоев, то можно промежуточные камеры рендерит объекты на прозрачную пленку - она закрашивается, если в область видимости камеры попал объект, но остальной фон остается прозрачным, и только в камере дальнего слоя фон всегда закрашивается скайбоксом. Мне этот процесс напоминает наложение целлулоидов из фильма "Как снимали Незнайку на Луне"
я потерял статью, в которой разработчики из рф пилили какую-то игру про космос с упором на реалистичные расстояния.у них были те же проблемы. становится понятно, зачем нужны карты с двойной точностью для вычислений в программах типа ansys
становится понятно, зачем нужны карты с двойной точностью для вычислений в программах типа ansys
Не для вычислений, а для тех же целей, показывать нормально любую геометрию в общем случае.
Первые версии программ входящих в пакет Ansys были написаны довольно давно: 70-е 80-е годы прошлого века, тогда делали всё довольно грамотно и качественно. Иногда отрисовка в движении поверхностной сетки или чего-нибудь другого с бликами в CFX в 1..5 млн элементов происходит лучше и красивее чем в современных САПР с 1000 фасетами.
Но насколько мне известно, там рендер написан либо нативно, либо через openGL.
По умолчанию в том же пакете вычислительной газодинамики CFX используется просто float, но иногда приходится использовать опцию двойной точности из-за мелких элементов сетки.
Речь не про SpaceEngine?
А почему не воспользоваться стандартными свойствами движка для таких манипуляций? Использовать LoD, кастомный рендеринг из коробки. В первом приближении - рендерить удалённые объекты на отдельной сцене с простым освещением, и спрайты желаемого разрешения вешать в основную сцену на скайбокс.
Кеширововать по угловому размеру, и когда тригеррится анимация или сдвиг предсказуемо даст новый 1 пиксель (легко посчитать от абсолютных координат, расстояния и размера ) - чистить кеш и рендерить заново.
На ближней дистанции, конечно, придётся более дорогими способами обрабатывать, но на дальних - идеально избавиться от проблем с вершинами, маппингом текстур в полигоны размером 1,5 квадратных пикселя, и прочих артефактов.
Да, возможны разные оптимизации, в зависимости от специфики проекта. Запекать есть смысл тогда, когда например камера тусит вокруг медленно движущегося объекта и окружение не меняется. Рендерить дальние объекты с уменьшением качества так же можно, не обязательно даже в другой сцене, можно просто вынести в другой слой.
Жалко что вы не прошли чуть дальше по методу "Метод конического масштабирования". Кажется что математически такое пересечение и расположение камеры можно рассчитать, но только если объекты это сферы, а это как раз ваш случай. Может быть дело просто в сортировке, сортировать нужно по точкам-основаниям перпендикуляра от центральной линии камеры до центра сферы. А после того как порядок известен, опять же для сфер, можно рассчитать их масштаб так, чтобы сферы объектов не пересекались, но были максимально близко к Near Clipping Plane.
Но есть другая потенциальная проблема с "Методом конического масштабирования" в том что когда сферический объект очень близко к камере и находится сбоку, то перспективное искажение будет иметь разную силу, в зависимости от масштаба. По этому находясь камерой на очень низкой орбите небесного тела, это тело должно иметь фактические размеры из физического мира, чтобы картинка была реалистичной. Для небесных тел в нашей системе это подойдёт, но всё же имеет ограничения тоже.
UPD: Дополню что многослойный рендеринг очень дорогое занятие, и в случае с Deferred рендерингом ситуация будет еще хуже. На мобильных устройствах, да и на консолях иметь больше чем одну камеру расточительно, и из промежуточных буферов читать тоже очень дорого.
Я пробовал сортировать по магнитуде проекции локальной позиции объекта от камеры на ее вектор направления, но такое простое решение тоже не работает. Над более сложным, я как уже писал не стал думать, потому что нельзя в такую методику запихнуть всякие инфографики, которые все же неотъемлемая часть конкретно моего ТЗ, если бы их не было я бы наверно действовал иначе. Я хоть все объекты в сферы запихал, для удобства расчета попадания в камеру, инфографики остались инфографиками. К примеру та же плоскость эклиптики, которая по сути квад со скейлом на все пространство. У нее контейнер - сфера в нуле координат и с радиусом под радиус пространства, по этому мы по сути всегда в ней. Этот метод может подойти, если у нас есть отдельные друг от друга сферы, например космические корабли и планеты. Даже если корабли сталкиваются, можно их слить в один контейнер-пузырь внутри которого их z-буфер будет сортировать, но если в проекте все корабли перевязаны длинными канатами то этот метод не годится.
С перспективным искажением думаю вы правы, спасибо.
Что касается производительности - конечно многослойный рендеринг тяжелее однослойного, но могу сказать что по моему опыту на реальном проекте в прошлом, что древний айпад вполне тянул 2-3 камеры в аналогичной сцене. Все это кончено еще зависит от наполнения сцены и материалов. Я вот для теста собрал этот проект на бюджетный Samsung A05, который лагает даже в меню, и он худо-бедно тянет 4 камеры в сцене с 30 FPS. Так же возможно ощутимая часть производительности тратится на не-оптимизированные расчеты и GC.
Фото
Использовать метод камера в камере чтобы избежать абсолютных величин? Геометрия у вас и так квадратно-треугольная. Анимация наплыва на спутник(спрайт на который выводится изображение с второй камеры. Вы ведь не предлагаете до него лететь? И весь млечный путь рендерить заодно) FPS упадёт, но мне кажется любителей юняши это никогда не останавливало.
Даблы это топорное решение. Что будете делать если придется выстроить галактику, или детализировать планету до миллиметра? Так же разделять на слои рендеринга и делать спрайты из дальних объектов, это правильное направление, но подходить только для звезд и планет.
Начните изучение этой темы с проекта outerra. С того как они пересчитали глубину, чтобы позволить дальним и ближним объектам не отсекаться плоскостями камеры, и решить проблему их перекрытия. Необходимость перегонять объекты в отдельные слои рендеринга и спрайты может отчасти отпасть, поскольку они просто сожмутся в точку, когда появятся проблемы с их отображением.
Следующее решение деревья. Начать можно с простого - чанков, и тут же избавиться от double. Каждый чанк должен быть достаточного объема, чтобы внутри него хватило точности float. Их также можно объединять в более крупные чанки объектов, которые внутри будут также позиционироваться float-ами. Мне хватило трех ступеней чтобы закатать туда галактику. Это также позволяет избавиться от сортировки объектов.
Float-ы сами по себе самодостаточны и позволяют легко их расширить используя длинную математику. В unity в этом нет необходимости поскольку сама сцена строиться как дерево и таким образом решает часть проблемы с реализацией чанков. То есть, не городя лишних расчетов, а используя уже то, что есть в дивжке. Конечно вам понадобятся некоторые расчеты, но база уже будет готова. Две вложенности дают вам возможность сделать позиционирование из трех float, что покрывает миллиметровую точность для объема галактики. Тут же можно решить и идею с плавающей координатной сеткой - как переход камеры между мелкими чанками.
Было когда-то дело https://www.youtube.com/watch?v=ptiE9u-bf38
Тоже сталкивался с подобными проблемами, когда делал свой движок для визуализации объектов Солнечной системы. Только Unity я не использую, у меня чистый WebGL. Если интересно, можете посмотреть примеры моих визуализаций. Хотя на протяжении большей части своих видео я показываю небесные тела не в масштабе относительно расстояний между ними, иногда приходится показывать объекты с соблюдением масштабов, например, когда астероид сближается с планетой. Вот тогда и возникали тряски, и "дробление" сфер. Тоже пришёл к тому, что надо начало координат располагать в точке расположения камеры. Далёкие объекты (например, звёзды) приближаю к камере, чтобы они не отсекались. На самом деле, все проблемы удалось решить не прибегая к слоям.
Система рендеринга для космического симулятора в Unity