Автор: Глеб Лебедев
Движок Cafu, известный ранее под именем Ca3D, получил новую лицензию – GPLv3. В соответствии с новым статусом были открыты исходные тексты движка. Сам движок написан на С++, и его отличает от множества схожих бесплатных движков наличие сетевой подсистемы с предсказанием данных на клиенте.
С полным набором фич можно ознакомиться на официальном сайте движка по ссылке:
http://www.cafu.de/features
11 февраля 2010
охренеть
список фич впечатляет
Ирония?
GLoom
> Ирония?
отнюдь
Коментъ на немском местами, ужаснъе хидеръ полнъе коментов.
Немного устаревшие технологии (BSP/PVS), которъе к тому же очень требовательнъ к тулам.
Немного чудивищная на первъй взгляд система материаллов имхо.
Меши вообще написанъ на коленке.
Т.е. движок пилить и пилить для чего-то сериозного, после беглого просмотра.
Z
А что конкретно там не так с мешами и системой материалов?
Subject
Меши какие-то симплистичнъе - какой-то массив из толстъх вертексов в RAM-е, какой-то array_t при етом. Может ето меш для процессинга тулами только?
Ведь охота иметь множество вертекс форматов, охота не грузить меши вообще в RAM, создавать прямо из куска в памяти, етц. Winding же - имхо должно бъть прямо в материале.
Нашел в Model виртуальнъй метод Draw... :)
Какие-то ужаснъе std::string как параметръ почти везде...
Материал же - какое-то порождение Quake движков - предефинированнъй сет текстур.
Булевъе переменнъе вместо флагов, несколько шейдеров под разнъе случаи - а надо только один шейдер риференс имхо, где все ето написано.
Вообще ничего про бинарность ресурсов, какой-то парсинг текстовъх файлов только...
Вообще, сильное ощущение движка, которъй не сталкивался с суровой реальностью - ну или автор решил в пользу архитектурности, за счет перформанса (ничего плохого в етом нет).
И вот такое - TextureMapManagerImplT::Get().FreeTextureMap(DiffTexMap ) настораживает. Вообще, мельком посмотрев на сорс заметно местами паттернъ - длинющие строчки кога с минимальнъми отличиями... труевое ООП, да :)
Z
>Ведь охота иметь множество вертекс форматов
А зачем во внутреннем формате меша иметь поддержку множества вертекс форматов?
>Нашел в Model виртуальнъй метод Draw... :)
это от лукавого, да)
>Вообще ничего про бинарность ресурсов, какой-то парсинг текстовъх файлов только...
на этапах разработки текстовые файлы имеют место быть имхо. А к релизу уже билдить их в бинарный пак.
>TextureMapManagerImplT::Get().FreeTextureMap(DiffTexMap )
черезчур труёвое)
строка напомнила Ogre3D
Subject
> А зачем во внутреннем формате меша иметь поддержку множества вертекс форматов?
Что такое - внутренний формат?
>на этапах разработки текстовые файлы имеют место быть имхо. А к релизу уже билдить их в бинарный пак.
Ето утверждение верно, но не отвечает нам на вопрос почему бинарнъх даннъх все же нет.
Z
>Что такое - внутренний формат?
Какой-то минимальный класс, описывающий геометрию (кусок геометрии). С опредлённым форматом.
Рендер умеет рендерить такие меши.
Тулсет умеет делать такие меши.
Для чего может понадобиться разные форматы вершин?
>Ето утверждение верно, но не отвечает нам на вопрос почему бинарнъх даннъх все же нет.
Оставили вид и формат бинарных данных на усмотрение разработчика, использующих этот миддлеваре)
Z
>Материал же - какое-то порождение Quake движков - предефинированнъй сет текстур.
>Булевъе переменнъе вместо флагов, несколько шейдеров под разнъе случаи - а надо только один шейдер риференс имхо, где все ето написано.
Возвращаясь к материалам.
Как они должны выглядеть на уровне граф движка? Набор неких аттрибутов, по которым генерится шейдер?
Subject
> Рендер умеет рендерить такие меши.
> Тулсет умеет делать такие меши.
> Для чего может понадобиться разные форматы вершин?
Для чего может понадобится такой меш, сначала надо понять..
Для дебаг визуализации какой-то?
>Оставили вид и формат бинарных данных на усмотрение разработчика, использующих этот миддлеваре
Еще хорошо, что они систему материалов не оставили на усмотрение разработчика.
>Набор неких аттрибутов, по которым генерится шейдер
Я не говорю, что надо делать что-то генерально различное. Просто то что там - сърое. Текстуръ експлицитно расписъвать - ето значит везде писать експлицитно код рефлексирующий их. Булевъе переменнъе - вообще без коментария. Шейдер имена - как я сказал одно имя (таг), по которому уже можно ресолвить шейдера для теней, шейдинга, разнъх деферед пассов и т.д., а не писать все ето (которое объчно coupled сильно) в материаллах.
Примерно:
struct SubMaterial
{
struct Map
{
MyString name;
int tex_coord;
int semantic;
};
Map m_maps[12];
ShaderDefs m_sdef; // shader definitions
MyString m_shader_name; // shader reference name, i.e. 'phong' for example
float m_fadeRange[2]; // custom material fade range
float4 m_gloss_color; // constant gloss color
float m_scroll_time; // texture scroll time
Shader * GetShader( PassType pass );
};Полноценнъй материал, почти копия нашего. Пишется очень просто в бинарнъй вид, генерирует необходимъй шейдер под каждъй пасс, может содержать 2 дифузнъх мапа если нужно, етц.
Z
>Для чего может понадобится такой меш, сначала надо понять..
>Для дебаг визуализации какой-то?
Почему для дебаг?
Для рендеринга обычного. Просто формат предоставления геометрии.
>Еще хорошо, что они систему материалов не оставили на усмотрение разработчика.
))
А расскажи плиз про ShaderDefs и GetShader( PassType pass ).
Ну и вообще про то, как оно работает)
А никто не обратил внимания, что GPLv3 - копилефт лицензия? То есть если что-то захотите выпустить, придется код открывать.
batment
> А никто не обратил внимания, что GPLv3 - копилефт лицензия? То есть если что-то
> захотите выпустить, придется код открывать
Доступно двойное лицензирование.
Тема в архиве.