Извините, ничего не найдено.

pozitiffcat · 03.12.2013, 19:14

Сообщение от HolyDel

У меня в движке есть граф сцены, что совершенно не мешает рендерить в ручную объекты.

camera->RenderEntity(entity(;

у меня slim

ничего лишнего, хочу попробовть такую реализацию

pozitiffcat · 03.12.2013, 19:17

Сообщение от moka

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

Также менеджить свой стейт - это круто в плане контроля и возможностей, но очень не удобно и требует дополнительной разработки от самого разраба, что приведёт его к переписке того же стейт менеджера, но по своему.

Имхо, стейт менеджер должен быть конкретным и простым, реализующим всё что нужно и наипростейшими методами.
Удобство работы имхо на первом месте, тогда и не нужно будет думать о своём стейт менеджере.

батчи у меня автоматически юзаются, все, что одной текстурой - то рендерится одним батчем. Изображения создаются из текстурного атласа, там правда не супер удобный механизм

загрузка изображения1 в атлас - получение текстурной координаты
загрузка изображения2 в атлас - получение текстурной координаты
билд атласа (создает текстуру внутри себя)
создание изображение1, передав в атлас текстурные координаты1
создание изображение2, передав в атлас текстурные координаты2

pozitiffcat · 03.12.2013, 19:21

Сообщение от ABTOMAT

Ну и в чём будет принципиальное отличие?
В 2Д так делали потому что в каком порядке отрендеришь картинки, в таком они и будут друг на друге лежать.
В 3Д этим занимается Z-буфер, и хоть ты в каком порядке отрендеришь, всё будет так же, как и с Z-буфером.
Логично рендерить группами с одинаковыми текстурами/шейдерами, чтоб не гонять их каждый раз и этим стоит заниматься движку.
Альфе нужна сортировка, но с этим опять же лучше пусть двиг справляется.
В-общем я не вижу что такого может прогер сделать крутого, что не может сделать за него двиг и смысла забивать прогеру голову этим.
Разве что в FPS ствол поверх всего отрендерить, но ради 1 ствола огорода не городят.

я когда делал освещение, я просто охренел от количества шейдеров, которые расплодились, и что-то простотой перестало пахнуть, решил сделать движок, расчитаный на более продвинутого в плане графики программиста, и возложить цикл на его плечи, так контролировать всякую такую хрень проще. Темболее нарисовать в цикле много раз 1 меш в цикле (как 2д с картинками) проще ИМХО.
Опытом проверится... на самом деле хз.

HolyDel · 03.12.2013, 20:28

загрузка изображения1 в атлас - получение текстурной координаты
загрузка изображения2 в атлас - получение текстурной координаты
билд атласа (создает текстуру внутри себя)
создание изображение1, передав в атлас текстурные координаты1
создание изображение2, передав в атлас текстурные координаты2

тоже хотел такую штуку замутить но все руки не доходят

pozitiffcat · 04.12.2013, 17:02

добавил доки, правда их там мало не все успел написать
https://bitbucket.org/pozitiffcat/sl...oc/?at=default

реализовал кучу функционала, которым можно воспроизвести работу Clear Engine. И даже более, единственное ограничение, это формат вершины, 96 байт positions, normal, texcoord, texcoord2, joint, weight, binormal, tangent.

Mr_F_ · 04.12.2013, 17:07

96 байт

жирно. необходим выбор программистом любого своего варианта

pozitiffcat · 04.12.2013, 17:10

Сообщение от Mr_F_

жирно. необходим выбор программистом любого своего варианта

да, но там как бы все самое необходимое, причем загрузчик моего формата использует все эти атрибуты
хотя как вариант хранить в поверхности еще и формат описывающий ее...
---
хоят не не вариант. Я не могу для всех шейдеров хранить attribute location в поверхности

Mr_F_ · 04.12.2013, 17:16

ни одной модели не нужны все эти данные, большинство моделей не имеют скининга, а те кто имеют - редко требуют вторые UV.
тангент и бинормал ужимаются в один vec4.

--
со страницы 19 можно почитать как жестоко ужимали вертексы в just cause 2:
http://www.humus.name/Articles/Perss...GameWorlds.pdf

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

pozitiffcat · 04.12.2013, 20:23

запилил атрибуты



sProgramInitData progInit;
progInit.add(VertexAttribute::VaPosition, "POSITION");
progInit.add(VertexAttribute::VaTexcoord0, "TEXCOORD");
progInit.add(VertexAttribute::VaJoint, "JOINT");
progInit.add(VertexAttribute::VaWeight, "WEIGHT");
progInit.vertexSource = readTextFile(context, "simple_anim.vs");
progInit.fragmentSource = readTextFile(context, "simple_anim.fs");
m_program = context->video()->createProgram(progInit);

sVertexDeclaration vd;
vd.attributes.push_back(sAttributeDeclaration(VertexAttribute::VaPosition, 0, 3));
vd.attributes.push_back(sAttributeDeclaration(VertexAttribute::VaTexcoord0, 24, 2));
vd.stride = sizeof(sVertex);
surface->setVertexDeclaration(vd);

HolyDel · 05.12.2013, 02:09

столько лишних слов...
это нифига не slim.

pozitiffcat · 05.12.2013, 09:49

Сообщение от HolyDel

столько лишних слов...
это нифига не slim.

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

Slim не в плане простоты, а в плане того, что движок не жирный.

Samodelkin · 05.12.2013, 15:45

Кстати вот в d3dx есть такая штука id3dxeffect, которая позволяет более менее структурировать большое кол-во шейдеров, хотя конечно имхо от большого кол-ва шейдеров нужно по возможности избавляться. Можешь попробовать в opengl что-то подобное сам сделать.

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

По моему убеждению движок должен не добавлять/обобщать/урезать функционал тех компонентов с которыми он работает, а интерпретировать высокоуровневую работу с абстрактными сущностями через эти низкоуровневые компоненты.

Что ты понимаешь под простотой движка? Например кодить небольшие игры довольно просто на unity3d или blitz3d, однако их нельзя назвать оптимизированными по производительности. С другой стороны оптимизированный код обычно больше по размеру чем универсальный, потому что в нем может быть много частных случаев и ассемблерных вставок, он сложней для понимания и отладки. Так что имхо упрощать нужно архитектуру, убирать ненужный функционал, а также упрощать структуру и семантику кода пока это совпадает с повышением его производительности, и улучшением читабельности.

Управление сложностью является решающим фактором успешного развития движка в будущем.

Поэтому я бы еще раз обратил внимание на пост товарища jimon'а где то в начале темы - там он расписывал о driven data.
Это удачное решение потому что позволяет четко распределить обязанности между движком и редакторами. Задача движка воспроизводить контент на разных платформах, с минимальным вмешательством программиста. Задача редакторов предоставить функционал движка разработчикам игр в наиболее подходящей для данного проекта форме. Тем самым подход становится более декларативным - мы даем движку контент и говорим что делать, а не как делать. Движок становится проще, а редакторы гибче, к тому же я могу на каждый проект сделать свой набор редакторов, и делать их по мере необходимости.

Mr_F_ · 05.12.2013, 17:07

Samodelkin · 05.12.2013, 17:46

Mr_F_ · 05.12.2013, 18:03