XaeroX писал: Никто не мешает перегрузить для любого АТД new и delete.
Это да, но мне не даёт покоя мысль, почему Кармак это отключил для д3. Сделал и выключил.
Добавлено 24-10-2019 в 18:23:
Вот кстати, говоря возвращясь к той статье на Хабре про устройство современного процессора, там прямо в начале были такие занимательные строчки, что мол опытные программисты, до сих пор имеют о процессорах представление, застывшее на уровне суперскалярной архитектуры первого пня, а то что сейчас стоит у всех в компьютерах, даже С++ на дух не переносит, оно вообще точилось под виртуальные машинки.
Есть над чем задуматься.
Дядя Миша писал: что мол опытные программисты, до сих пор имеют о процессорах представление, застывшее на уровне суперскалярной архитектуры первого пня
Типичный хабр - "все вокруг дураки, один я умный в белом пальто стою красивый".
С декалями я придумал вот какую концепцию - декаль будет тоже модель. Ну разумеется не для пользователя, а с точки зрения движка. Мой менеджер моделей в своей концепции позвоялет ссылаться на другую модель, как на родителя. Таким образом парент для модели декалей будет например мир или бмодель. Причём эта модель будет линковаться не к самой модели, а к энтити, чтобы не получилось ситуации, например, когда дубликат одной и той же встроенной модели заодно дублирует и свои декали на ней. Сохранение таких декалей будет происходить через методы, встроенные в саму модель (не только для модели декалей, а вообще для любой модели).
И пользователь сам сможет определить для какой модели надо сохранять декали, а для какой нет. Аналогично для такой модели будет строится и область видимости, как и для брашевой. Это позволит держать рендеринг в юниформе. И для травы будет точно такая же модель со ссылкой на родителя. а шейдеры будут линковаться через хинты mod_decal, mod_grass.
Сам рендеринг при этом принимает максимально однотипный вид - промаркировали видимость для списка и отрисовали всё.
Текущий вариант организации скриптов. Здесь всё рабочее, все условия, параметры. всё рулит процессом. Работать становится всё удобнее, я к примеру добавил освещение на брашы, дописав несколько строчек в shaders.def
Вложение: scripts.zip (3.8 кб)
Этот файл был скачан 99 раз.
Этож не просто key-value. Если бы ты дальше промотал. то увидел бы вот например такое:
C++ Source Code:
1
"{gratestep3"
2
{
3
#material grate
4
5
AlphaFunc( GL_GREATER, 0.25f );
6
}
Можно вообще всё полностью перегрузить, из того что объявлено в технике\шейдер объекте. Оно нечасто нужно, ну вот скажем зеркала или там видеотекстуры. Вот для таких случаев.
то есть все квары теперь рулят дефайнами именно отсюда. Движок ничего не знает про эти шейдеры, он вообще про них ничего не знает. Всё здесь.
Добавлено 28-10-2019 в 01:42:
Вот примерчег чуть посложнее
C++ Source Code:
#if r_detailtextures && u_DetailMap
#define HAS_DETAIL
#endif
Что проверяется здесь? Во первых, чтобы квар r_detailtextures был установлен в состояние, отличное от нуля. Во вторых юнит u_DetailMap проверяется на заданный путь (причём неважно где вы его задали, в технике, в шейдеробъекте или в самом материале) и только если текстура действительно существует - применяется #define HAS_DETAIL. Т.е. система способна выполнять реальные проверки на валидность пользовательских данных. Ну и с бампом аналогично.
Добавлено 28-10-2019 в 01:46:
Может у кого-то вопрос возникнет, почему это именно препроцессинг. Отвечу, потому что эти условия выполняются только перед компиляцией шейдера. А квары, типа r_lightmap имеют теперь особый флажок FCVAR_RELOAD_SHADERS, который провоцирует ребилд шейдеров у всех моделей. Т.е. проверка идёт именно на этапе сборки. Условия, которые выполняются всё время, очевидно находятся в самих GLSL-шейдерах.
Ну впрочем, функции gl-state тоже часть реального кода, но условий там нету.
Добавлено 28-10-2019 в 01:51:
Кстати говоря, заведомо статичные условия выполняются еще на стадии парсинга всех этих скриптов.
Дядя Миша
Я правильно понимаю, что к моделькам уже можно вязать ключ-значения и что они могут передаваться как параметры в шейдер? И для каждой модельки эффект будет зависеть от значений параметров?
Дядя Миша писал: Может у кого-то вопрос возникнет, почему это именно препроцессинг. Отвечу, потому что эти условия выполняются только перед компиляцией шейдера. А квары, типа r_lightmap имеют теперь особый флажок FCVAR_RELOAD_SHADERS, который провоцирует ребилд шейдеров у всех моделей. Т.е. проверка идёт именно на этапе сборки. Условия, которые выполняются всё время, очевидно находятся в самих GLSL-шейдерах.
Ну впрочем, функции gl-state тоже часть реального кода, но условий там нету.
По-моему ты с ума сойдёшь всё это документировать.
GL_GREATER это научное название альфатеста?