axelynx

[HolyDel]

разбор простейшего шейдера.
вершинный:

uniform mat4 modelviewproj;

layout(location=VA_POSITION) in vec3 position;

void main(void)
{
	gl_Position     = modelviewproj * vec4(position,1.0);
}

в первой строке получаем стандартный юниформ. Это mvp матрица. Ее считает и посылает движок.
layout(location=VA_POSITION) in vec3 position; (пока layout(location=0))
здесь в вершинный шейдер передается один из аттрибутов вершины. а именно позиция. (все системные аттрибуты можно глянуть здесь: http://code.google.com/p/axelynx/sou...ource/saSpec.h)

далее эта позиция в локальной системе координат множится на MVP матрицу - чтобы получить позицию вершины в нормированном кубе. Это такой куб (-1,-1,-1,1,1,1). потом к этой позиции применяется еще трансформация вьюпорта, чтобы получить позицию пикселя в оконных координатах.

out vec4 color;

void main (void)
{
	color = vec4(1.0,0.0,0.0,1.0);
}

задается выходной аттрибут color.
и пишется в него значение.

если нужно несколько слоев (MRT), то можно использовать записи вида:

layout(location=0) vec4 color0;
layout(location=1) vec4 color1;
layout(location=2) vec4 color2;
layout(location=3) vec4 color3;

ну вот как то так.

HolyDel, а у тебя есть схема какая-нибудь которая показывает целиком архитектуру и устройство движка, чтобы было понятно как там все взаимосвязано и как работает?

нетъ

У тебя как хранение объектов организовано (в плане доступа к ним со стороны движка)?

храню указатель предков. динамическая типизация.

Просто я вот думаю, вот например есть объекты разных типов (шаблонные классы), и их нужно как то хранить в структуре похожей на связанный список. Но ведь связанные списки могут хранить объекты только одного типа. И я так понимаю что используя только статическую типизацию такой связанный список с объектами разного типа вообще нельзя сделать. Можно отказаться от шаблонов в пользу наследования, но гибкость теряется. Может разнотипные объекты как то по другому надо хранить?

шаблоны используются по минимому. мне вполне хватает наследования.

[Samodelkin]

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

А кстати по поводу шейдеров. В RM там конечно здорово но там максимальная версия вроде 3.0. Бесплатных редакторов я что то не видел где была бы версия шейдеров выше. Может в движок стоит добавить какой-нибудь небольшой редактор? Ведь в реалтайме редактировать шейдеры удобней.
Вот смотри тут есть: http://www.uraldev.ru/articles/22

[HolyDel]

новая версия.

пофикшена ошибка с MRT
пофикшена ошибка в шейдере паралакса
пофикшена ошибка в проигрывании феоры
пофикшена ошибка в инстансинге

добавлен ряд старых сэмплов
начата работа над справкой по движку и по шейдерам (в архиве они есть).

версия фулл (с прекомпилированными статическими либами, 96 метров)
http://axelynx.googlecode.com/files/...x_106_full.exe

версия лайт( без либ, 40 метров):
http://axelynx.googlecode.com/files/...x_106_lite.exe

[pax]

А не слишком резкая граница размытия между передним планом и областью фокуса? На заднем плане лучше смотрица.

[HolyDel]

так лучше?

можно играться вот с этой строчкой в шейдере dof.fs

blur = pow(-dist / focal_distance,2.5);

[pax]

Вроде да

[HolyDel]

добавил группы рендера
пофиксил ошибку в рендере спрайтовых систем
ускорил расчет тангентов

пилю демку с DS

[Samodelkin]

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

добавил группы рендера
пофиксил ошибку в рендере спрайтовых систем
ускорил расчет тангентов
пилю демку с DS

В чем суть групп рендера, как и где их можно будет использовать, в чем приемущество или удобность?

Что такое DS?

В движке будет что то аналогичное SpeedTree ?

[HolyDel]

В чем суть групп рендера, как и где их можно будет использовать, в чем приемущество или удобность?

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

Что такое DS?

deffered shading (хотя я лучше бы называл его deffered lighting)

В движке будет что то аналогичное SpeedTree ?

нет, это сгенеренная в максе геометрия.

[HolyDel]

1000 источников света
почти 4 ляма трисов в кадре

[HolyDel]

водичка в процессе разработки. пока без динамических отражений

[4yBa4Ok]

4откие скрины :D

[HolyDel]

лайт версия (60 метров)
http://axelynx.googlecode.com/files/setup_107_lite.exe

фулл версия (114 метров)
http://axelynx.googlecode.com/files/setup_107_full.exe

в сдк есть 20 примеров (исходники и бинарники). правда без комментариев.

[Hurrit]

а под iOS и android трудно будет его переделать? и есть ли возможность запускать на маке?

[HolyDel]

а под iOS и android трудно будет его переделать? и есть ли возможность запускать на маке?

теоретически - должно быть не сложно. но только под gles 2.0. Так как все на шейдерах. + нужно будет писать свой парсер для всяких layout-ов. Да я и с самого начала планировал, что будут порты под современнве девайсы.

на практике - мне так и не удалось нормально собрать NDK чтобы посмотреть на нем какие-нибудь gles 2.0 примеры. Мака нет, вираулку ставить не хочу, хакинтош тоже. Мак есть на работе, но там пока времени нет что то сделать для себя.