Войти
ПрограммированиеФорумОбщее

Движок DGLE2 (Официальная тема, Новости) (7 стр)

Страницы: 13 4 5 6 7 8 Следующая »
#90
19:56, 21 апр. 2016

DRON
О спасибо! Посмотрю как-нибудь. Не знаю как там игры на нем писать (я бы выбрал юнити или анриал), но для экспериментов над графикой для меня это лучший вариант. По этому я как никто другой рад что разработка продолжается. По крайней мере основы для старта лучше пока не видел. SDL - много того чего не надо и мало того что надо; GLFW - слишком мало всего; urho, torque, и тому подобные - слишком монструозные, да и порой весь код написан в каком-то совершенно диком стиле. Разбираться кучу времени в тонне over-закоментированном либо совсем не закомментированном С++ коде, а потом еще понять что это еще никак не расширяется, совершенно не хочется. Моя конечная цель - Voxel cone tracing(знаю знаю по памяти не эффективно, но мне пофиг). Посмотрим, если получится dgle подстроить под себя, буду использовать. В противном случае придется писать свой движок (половина кода, естественно, будет скопирована из dgle). И да, отдельное спасибо за плагинную систему и событие ET_ON_GET_SUBSYSTEM.


#91
20:58, 21 апр. 2016

k-payl
Ну я рад, что кому-то движок все-таки полезен так или иначе :)
Если что обращайся, помогу советом в реализации.

#92
21:22, 21 апр. 2016

k-payl
> половина кода, естественно, будет скопирована из dgle
Вместе с лицензией LGPL?

#93
22:42, 22 апр. 2016

DRON
У меня то конечно много вопросов. По всякой ерунде не хочу отвлекать. Ну а так хорошо, буду иметь ввиду)

gammaker
Не знаю что это такое (и знать не хочу).

#94
1:42, 23 апр. 2016

k-payl
> Не знаю что это такое (и знать не хочу).
Придётся узнать, когда тебя попросят выложить исходники своего проекта. Если конечно свой "продукт" будешь распространять, а исходники сам добровольно не выложишь.

#95
6:20, 23 апр. 2016

Меня DGLE привлек наличием 2D, Lua, Box2D.
Но пока это всё в альфе, то я им не пользуюсь.

#96
12:02, 24 апр. 2016

AntonioModer
> Меня DGLE привлек наличием 2D, Lua, Box2D.
> Но пока это всё в альфе, то я им не пользуюсь.
Посмотри движок Defold, там все это есть и сделано хорошо. Из всего что есть на рынке, он больше всего похож на то, каким я хотел бы видеть DGLE.

#97
15:04, 24 апр. 2016

DRON
> Посмотри движок Defold, там все это есть и сделано хорошо. Из всего что есть на
> рынке, он больше всего похож на то, каким я хотел бы видеть DGLE.
Спасибо DRON :), я за этим движком уже 2 года наблюдаю, тему тут создал (http://www.gamedev.ru/code/forum/?id=213486)
Мне больше LOVE2D (http://love2d.org) нравится, я на нем свой игровой движек пилю.

#98
11:17, 25 апр. 2016

AntonioModer
Я сам LOVE2D не смотрел, но слышал хорошее про него.

#99
21:30, 14 мая 2016

DRON
Эх что-то экспортер из макса не работает. У простого единичного кубика в dmd файле оказываются не правильные нормали. Да что там кубик. Просто треугольник экспортировал, итог: три нормали - почти нулевые вектора(координаты порядка 10^-8). Может было уже такое? Скрин данных нормалей у кубика:  normals_dmd | Движок DGLE2 (Официальная тема, Новости) Причем до этого данные позиций вершин видно нормальные.

#100
15:25, 17 мая 2016

k-payl
Чет я не понял... На скрине 1.57xxxx не выглядит как почти нулевое число. То что это и не выглядит как правильная нормаль, я тоже согласен... хотя больше похоже, что просто не нормализована может... Но в любом случае где что на скрине я наверняка сказать не могу.
А вообще в движке рисуется кубик твой? Там можно модель загрузить с флагом и пересчитать нормали, например.
Раньше с максом таких проблем не наблюдалось.

#101
19:44, 17 мая 2016

DRON
Да, все верно, нормали у кубика не нулевые. Почти нулевые получились при экспорте треугольника. В движке этот кубик рисуется и даже правильно, при модели освещения по Ламберту:))(ниже на скриншоте). Я сначала думал, это шейдер мутит а оказалось корявые нормали.  А тут получается у половины вершин нормали направлены в одну сторону по оси Z, у другой половины в другую, поэтому на середине нормали резко меняют направление. Встроенный в движок кубик рисуется, кстати, нормально. При загрузке с флагом там, насколько я понимаю, группы сглаживания собьются поэтому не пробовал. Еще только что попробовал в максе экспортировать с флажком "build faset normals" - с кубиком все ок, но с цилиндром, естественно, такой трюк не прошел. Короче наверно в максе какой-нибудь баг. cube | Движок DGLE2 (Официальная тема, Новости)

#102
12:32, 18 мая 2016

k-payl
Скорее всего проблема с группами сглаживания ну и на последних версиях макса скрипт никто не проверял. Увы.

#103
23:52, 27 мая 2016

DRON
Привет Дрон!) Пишу свой Core render для современного OpenGL. Если не затруднит, не мог бы ты по подробней пояснить смысл\назначение некоторых функций? Больше всего волнуют сейчас функции ICoreGeometryBuffer::Reallocate(), ICoreGeometryBuffer::SetGeometryData(), ICoreTexture::Reallocate(), ICoreTexture::SetPixelData().
Как это я понимаю. В core render мы можем создавать core-текстуры, core-геометрию. Некоторые параметры уже нельзя будет изменить (типа E_CORE_RENDERER_DRAW_MODE у геометрии, E_CORE_RENDERER_DATA_ALIGNMENT у текстуры), зато можно заменить само содержимое у текстуры и у геометрии с помощью соответствующих функций Reallocate(). Поправь, если это не так.
Еще есть микро вопросы. Что означает аргумент bMipMaps у функции ICoreTexture::Reallocate(const uint8* pData, uint uiWidth, uint uiHeight, bool bMipMaps, E_TEXTURE_DATA_FORMAT eDataFormat)? То что нам нужно сгенерировать mipmap-ы или то что все mipmap-ы содержатся в pData? Немного намучился со структурой TDrawDataDesc. Не понятно, кто должен быть ответственным за удаление pData внутри этой структуры, ввиду отсутствия конструкторов копирования. Есть какие-то правила по работе с этой структурой? Если я правильно понял, в структуру TDrawDataDesc не добавляется конструктор копирования из-за утраты свойства "быть POD типом". Но в c++ сейчас есть более тонкие характеристики типов "standard layout", "trivial copyable". Вот в "standard layout" можно добавить нормальный конструктор копирования. Еще, насколько я понял, сама структура TDrawDataDesc представляет некий абстрактный кусок геометрии. Почему бы в эту же структуру не засунуть количество вершин, количество индексов? Везде в коде я вижу (const TDrawDataDesc& stDrawDesc, uint uiVerticesCount, uint uiIndicesCount,...), то есть данные о вершинах в stDrawDesc, но само количество вершин в uiVerticesCount.

#104
15:03, 30 мая 2016

k-payl
Круто, что ты занялся таким делом! Я сам хотел :) В принципе, можно взять legacy OpenGL core renderer и просто его немного перефигачить под современный стандарт.
>ICoreGeometryBuffer::Reallocate(), ICoreGeometryBuffer::SetGeometryData(), ICoreTexture::Reallocate(), ICoreTexture::SetPixelData()
Эти все методы действительно для того, чтобы можно было изменять содержимое объекта уже после того как он создан.
При этом его размеры в памяти могут меняться, для текстуры это мипуровни и разрешение, для геометрии это — кол-во вершин. Фактически это равносильно созданию нового объекта, но с сохранением ссылки на базовый объект и некоторых свойств.
Проще говоря, ты понял все правильно.
>bMipMaps
Движок сам умеет генерировать мипмапы на уровне менеджера ресурсов. И ф-я Reallocate также как и создание текстуры, обычно вызывается оттуда. По этому, этот флаг просто указывает представлены ли мипуровни в pData или нет. Только не забудь в ICoreRenderer::IsFeatureSupported сказать false на CRFT_TEXTURE_MIPMAP_GENERATION, чтобы движок ничего от тебя не ждал. Но в любом случае, ситуации когда  bMipMaps == true, а мипуровней в pData нет, быть не может.
>TDrawDataDesc
TDrawDataDesc - это дескриптор неких данных, которые можно нарисовать и сами данные в нем не хранятся, он лишь на них указывает. Причем pData может как указывать на данные в RAM так и быть оффсетом для данных в VRAM (в случае VBO, например). Тоже относится и к pIndexBuffer. Так как это дискриптор ссылающийся на некое место откуда данные начинаются, то он не должен знать сколько вершин и начиная с какой есть отдельный объект. Например, в случае с динамическим батчингом один такой дескриптор может хранить много геометрии свойства которой совпадают.
Если к тебе эта структура приходит с выделенной pData, то значит, кто ее тебе передал тот и ответственный за удаление. Если ты внутри себя создаешь копию и выделяешь новую pData и копируешь в нее что-то из другого TDrawDataDesc, то конечно, ты и становишься ответственным за удаление. Вообще в движке за крайне редким исключением (1 или 2 случая специфичных) данные удаляются в том-же cpp файле, в котором они и выделяеются. А что касается ресурсов (текстур, моделей и прочего...), то там за все связанное с памятью отвечает менеджер ресурсов.

Надеюсь, что ответил четко на твои вопросы, сорри что с не большой задержкой, был занят в выходные :)

Страницы: 13 4 5 6 7 8 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.