Xtreme3D

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

• Функция Update теперь называется EngineUpdate

• Функция TrisRendered удалена

• Функция ViewerRenderEx удалена

• Изменился смысл функции EngineSetMaxLights. Теперь она задает максимальное количество источников света, которые учитываются основной системой освещения и системой LightFX. По умолчанию это количество равно 8 (максимум для основной системы освещения). Если вы хотите использовать больше источников света для системы LightFX, нужно использовать эту функцию

• Функция ViewerGetPickedObjectsList теперь работает с объектами-списками PickList, которые нужно создавать вручную

• Функция ViewerRenderToFilePNG удалена - сохранение в PNG теперь поддерживается в ViewerRenderToFile

• Функция CameraZoomAll теперь требует указания Viewer во втором параметре

• Функция SpriteNoZWrite удалена, используйте вместо нее MaterialSetDepthWrite

• Функция MaterialCullFrontFaces удалена

• Функция MaterialSetZWrite теперь MaterialSetDepthWrite

• Переделана система TextureEx у материалов. Удалены функции MaterialLoadTextureEx, MaterialSetTextureEx, MaterialSetTextureExFromLibrary, MaterialGenTextureEx, MaterialEnableTextureEx

• Удалены функции ObjectGetCollisionPosition, ObjectGetCollisionNormal - вместо них теперь EngineGetLastRaycastPosition, EngineGetLastRaycastNormal, которые делают то же самое

• Функции Polygon удалены

• Функции TTFontSetEncoding, TTFontLoadCodePage удалены. Все строки в движке принимаются только в UTF-8.

• Для поддержки TTF пришлось добавить в движок SDL+SDL_ttf, т.к. я не нашел рабочий биндинг Freetype к свежим версиям Delphi. Весь Гитхаб перерыл, нету

• Функции TextRead, TextConvertANSIToUTF8 удалены

• Функция OdeAddCone удалена

• Переделана система FBO. Удалены функции FBOSetViewer, FBORenderObject, FBORenderObjectEx, FBOSetOverrideMaterial, FBOSetColorTextureFormat. FBO теперь лучше интегрирован в граф сцены

• Переделаны тени ShadowMap. Удалены функции ShadowMapSetCaster, ShadowMapSetProjectionSize, ShadowMapSetZScale, ShadowMapSetZClippingPlanes, ShadowMapRender. Добавлен новый объект ShadowCamera

• Функция PtrToReal теперь называется PointerToReal

В исходнике есть пример, рассчитанный на GM рантайм 2024.4.1.201 или новее.

Разница не в том, металлический объект или нет. Эти две модели по сути одно и то же, просто они выносят в текстуры разные компоненты формулы освещенности. Насколько я понимаю, модель metallic+roughness придумана для того, чтобы соблюдался закон сохранения энергии (diffuse + specular < 1.0), то есть, грубо говоря,

specular = baseColor * metallic
diffuse = baseColor * (1 - metallic)

Roughness же - это просто 1-gloss.

Я сторонник metallic+roughness модели, во всех своих шейдерах использую ее) Если хранить сразу specular и diffuse, то есть вероятность, что получится "нефизичная" комбинация, где совокупная отраженная энергия больше падающей, а это уже не PBR . Для сохранения энергии нужно делать дополнительные телодвижения: текстуры должны быть взаимосвязанными - чем больше gloss, тем ярче specular (и, соответственно, тусклее diffuse). У metallic+roughness такой связи между текстурами нет, что довольно удобно.

Также разница в экономии по весу:

Specular+gloss - 24-bit (diffuse) + 24-bit (specular) + 8-bit (gloss)
Metallic+roughness - 24-bit (baseColor) + 8-bit (metallic) + 8-bit (roughness)

Но у specular-модели есть то преимущество, что цвет поверхности может быть разный для рассеянной и бликовой составляющих, и это дает больше дизайнерской гибкости в некоторых случаях.

В общем случае, если текстуры создавались под рендер specular+gloss, то их уже не сконвертировать в metallic+roughness, и нужно переписывать рендер. А вот обратный процесс возможен.

Не знал об этом движке раньше. К сожалению, демка из коробки не запустилась, выдает ошибку "Variable <unknown_object>.show_debug_message_ext(101506, -2147483648) not set before reading it."
Судя по скринам, выглядит довольно интересно - как я понял, он написан на чистом GML, без библиотек? Если так, то это имхо минус, т.к. встроенное 3D в ГМ всегда будет ограниченным, и там нет особых перспектив для развития.

По описанию - очень интересно! Подписался на группу вк, буду следить, желаю успеха!

Ой, нет, рано я обрадовался - GLScene оказалась забагованная( Только сделал врапперы Freeform и Actor, как оказалось, что анимированные (и некоторые статичные) форматы при загрузке дают Access Violation. Видимо эти загрузчики никто толком не тестировал все эти годы, и там вкрались регрессионные ошибки. Придется пока отложить этот проект в долгий ящик. Жаль, конечно. Я думал, если вторую версию выпустили, то есть какая-никакая стабильность, а у них там конь не валялся)

На днях обнаружил, что, к сожалению, Xtreme3D 3.9.1 не работает с Game Maker Studio 2 версии 2022.800.0.161 и выше из-за полного перехода конструктора на 64-битную архитектуру. Движок доступен только в качестве 32-битной библиотеки. Так что можно считать, что история связки Xtreme3D + GM подошла к концу (что, впрочем, не отменяет возможность использовать его в других языках - только привязок маловато пока).

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

Выпустил новую версию с функцией PtrToReal. Теперь создавать вид надо так:

viewer = ViewerCreate(0, 0, window_get_width(), window_get_height(), PtrToReal(window_handle()));

Ссылка на релиз

Fps падает в отсутствие оптимизации покадровой нагрузки. Чем больше видимых объектов, тем больше расчетов матриц в Update и нагрузка на пайплайн для обработки примитивов (которые, возможно, в итоге вообще не будут отрисованы). Так что, по идее, нужно скрывать объекты, которые находятся за пределами экрана. Куллинг по пирамиде видимости - EngineSetCulling(vcObjectBased) или EngineSetCulling(vcHierarchical) - может в этом помочь, но не во всех случаях - например, если объекты находятся за стеной или горой, то они все равно считаются видимыми для куллинга.
В интерьерных сценах можно сделать систему порталов (т.е., показываем комнату, только если игрок в ней, или на экране виден дверной проем - и так же, рекурсивно, связанные с ней комнаты). В общем случае это будет вычислительно дешевле, чем обычный куллинг, который является брутфорс-алгоритмом - при использовании порталов мы вообще не проходим по заведомо невидимым комнатам и не проверяем их. Xtreme в принципе имеет все нужные для системы порталов инструменты, но у меня пока нет готовой реализации.
В уличных сценах можно для детализированных объектов сделать lod'ы и использовать мультипрокси, но это конечно немного усложняет логику игры, в зависимости от используемых компонентов.

Из-за того, что мало встроенных оптимизаций, GLScene/Xtreme3D - скорее для маленьких игр с ограниченным миром, чем для open world и тому подобного. Вообще библиотека, как я понимаю, изначально создавалась больше под научную визуализацию, да и игры в те времена были не такие большие.

Вот о чем я говорю (CSM):

В красной зоне один размер проекции (в данном случае 3), в зеленой больше (15), в синей еще больше (100). При этом размер теневых карт не меняется, но за счет того, что на разных расстояниях от камеры используются разные проекции, получается максимальный охват площади с плавным уменьшением детализации, которое в финальном рендере не бросается в глаза, т.к. большая проекция очень далеко.

Если использовать только одну карту, то мы бы видели тени, грубо говоря, только в красной зоне. Если эта зона не в поле зрения камеры, то теней вообще не будет видно. Я подозреваю, у тебя именно такая ситуация.

Я сомневаюсь, что тут будет дальнейший прогресс.