пятница, 25 июля 2014 г.

Привет ! ) 

итак поехали новости 

главная - даже выделю )) ВИНДА ( читаем ниже ) 


1 пилю свой редактор ! ( наконец то !!! в нем будет пасьянсы и куртизанки ) 
- что есть ? - пока не чего, кроме вывода модели и простого ее редактирования ( типа подвинуть повернуть и т.д., все примитивно, НО это старт ) 
- самое главное в этом всем то что мой движок теперь отлично пашет в Windows !!! 
кстати к слову портирование прошло более чем гладко( привет L кто то говорил что я встряну ))) , С++ он и есть С++ %) другие платформы так же не доставят особых проблем, что очень радует !

2 наконец разобрался с асихронной загрузкой ресурсов в огл на ios, довольно просто все получилось ибо шаринг контекстов ( кто бы мог подумать ))) ) осуществляется очень просто 
- результат, модели грузятся в бекграунде при этом камера активна и двигается без подторможиваний ! ( приятнее выглядит )  

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

что касается куртизанок так это будет редактор материалов ! причем как я уже ранее писал я все таки выстрадал идеальную систему микрошейдинга которая уже себя показала во всей красе ))) более того к системе микрошейдинга плавно присоединилась система техник в которых можно легко и не принужденно реализовать любой эффект - был бы код %))) 

каринки пока делать нет смысла ибо мой БамблБии выглядит фактически точно так же %)) ну да тени ну да свет - но кто его не видел ? учитывая что свет это дот ... а тени это обычные ШМ ))) вот когда будет на материалах сделан хотя бы фонг + каскад или ТСМ, вот тогда уже будут скрины

ну и ПС 
сейчас движок работает на 

- mac os 
- ios 
- windows ! 



воскресенье, 13 июля 2014 г.

Привет )

с последнего поста произошло несколько изменений

1 столкнувшись с ограничением в размере VBO я понял что так дело не пойдет )) и реализовал следующее
а) при выгрузки модели из 3д макс считается размер ее в памяти и если размер больше допустимого размера vbo, модель делится на чанки
б) так как моделей может быть тьма тьмущая я сделал активный буфер ( состоящий из нескольких VBO и IBO ) в который записываются модели таким образом
- модель 1
- модель 2
и т/д/ если места не осталось ( то есть наш гранд буфер заполнился ) то происходит следующее
требуемая модель пишется в начало буфера, затирая при этом уже загруженную в нее модель то есть старт записи в модель обнуляется
после записи происходит анализ того что было затерто и тому что было затерто ставится флаг - повреждености, соответственно при следующей попытки рендера такого объекта его поврежденные части будут перезагружены, то есть некий такой плавающий буфер )

2 сделал базовую систему звука ( рассказывать особо не чего ибо все травиально и очень базово, но уже есть кеш и так же буфер :)

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

в итоге сценки в АР сейчас с звуком и тенями ( стало поживее )

прогнал всю систему на лики памяти и соответственно поправил все это действо, в итоге система работает отлажено )


в перспективе планирую выпилить систему чанков ( ибо маразм делать модели больше размера VBO уж проще превратить все это в сабмешинг с полноценными отсечениями и т/д/ - под это дело уже стоит в планах редактор под движок )


понедельник, 7 апреля 2014 г.

С добрым утрецом чтоли )))


отделаюсь картинкой ( приболел чтот я + не много на другое силы пришлось перекинуть, вобщем теперь в строю


существенных изменений в движке не было, однако чутка допилил С++ экспортер ( теперь появляется диалог в котором можно выбрать что именно экспортим, пока экпортить можем - цвет, текстурные координаты, нормали )


чуть не забыл
картинка то к теме дополненной реальности )
тут бамбл би выводиться при наличии его маркера :)

сегодня бесоница какая то (( пытался заснуть часа 3 в итоге встал 

вторник, 11 марта 2014 г.

короткой строкой
- экспортер теперь на C++ в виде плагина для 3ds max 2014
удобно блин

1 скорость выгрузки несопоставима с максовым скриптом ! к примеру 450к поликов выгружаются через maxscript часа 4 через С++ меньше 10 секунд

2 экспорт происходит вызовом команды из максового меню export

короче мега удобнее мега лучше ! кстати еще + вершины через С++ выгружаются в дефолтном состоянии ( то есть без скейлов ротаций и смещений ) можно отдельно выгрузить эти матрицы ( что удобнее чем влоб получение позиций как в макскрипте ) 

воскресенье, 9 марта 2014 г.

Привет)

Да я опять без скринов ) на самом деле сижу жду пока произойдет выгрузка модели из 3дмакса ( 400к поликов ... )

Поэтому расскажу пока вот что

Дополненная реальность
итак пути развития есть 2

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

в итоге мы получаем заветные наши 4 точки которые через solvePnP можно преобразить в два вектора tVec и rVec далее путем простой математики мы получаем матрицу для openGL

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

2 это решение через featureDetect
- получили картинку
- нашли на картинке точки ( определенным образом )
- далее ищем соответствия с просчитанными заранее точками маркера
- ну тут конечно нужно будет отсеять кучу не нужного, например - точки могут найтись там где фактически маркера нету. путь решения - считать длину ( не подходящую выкидывать ), и считать сколько точек сосредоточены в одном месте ( это кстати просто мысль ), судя по тестам ошибочные точки хаотичны и разбросаны по картинке поэтому если подсчитать сколько точек находятся наиболее тесно друг другу в одном месте можно понять нашли мы то что нужно или нет
- мобильная оптимизация, самым главным образом
1 на маркере ищем порядка 1500 точек
2 на кадре ищем порядка 100 точек ( кстати есть статья где говорится что достаточно искать 20 точек но что то мне не верится а времени проверить пока нет )
3 если мы нашли маркер то к следующему кадру мы готовим только найденные точки
- в итоге это позволяет сузить нагрузку но на сколько пока не ясно
- для найденных точек мы вызываем findHomography которая нам выдает матрицу 3х3
- далее по матрице можно а) найти 4 точки описывающие наш маркер, б) построить матрицу для openGL

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

все это больше похоже конечно на записку чем запись в блоге ) так что считаем это убиением времени и промежуточным вариантом статьи )


среда, 5 марта 2014 г.

Привет ) я тут и дело движется
сейчас я занят дополненой реальностью и написанием движка на основе опенСВ, чуть позже когда появятся картинки я буду выкладывать инфо об этом направлении ( конечно для рендера используется мой движок )

кстати я тут провел массовые замеры + тесты, итак

GLKMatrixMult vs XTECHMath

GLKMult время исполнения запроса 0.06
XTECHMath время исполнения 0.04

что главным образом у меня сделано ?
- передача в функции указателей
- агресивный инлайн функций
- арм НЕОН ( он есть и в ките, но на примере используется не много другой код мультипликации )

тестирование было как в симуляторе на чистом С++ коде так и на устройстве с включенным НЕОН, так же я пробовал вставлять агресивный инлайн в GLK, в итоге во всех тестах моя реализация показала себя быстрее ;)

на данный момент я загрузил в движок 24к поликов ( не много, да, но это моделька из асасинкрита ) включил пер-пиксельное освещение и тени, и имею 1 мс утилизации GPU и 1ms утилизации CPU на iphone 5, пока сложно сказать на сколько это хорошие или плохие показатели так как сцена все таки мега простая, но как старт я думаю норм )


статьи по дополненной реальности я буду писать в этот же блог так что ждем обновления, совсем скоро я расскажу о двух методах определения маркеров в кадре и о трекинге ;)


суббота, 22 февраля 2014 г.


Привет )
добавил два флага в материал
base->flags|=DYNAMIC_PER_PIXEL_BASE_LIGHT;
base->flags|=RESAVE_SHADOW_SM;

+ включил тени на ios, текстурка на примере 1024х1024 и думаю оверхедовый размер ( но это все настраиваемо так что проблем поменять нет )

оптимизировал не много расчеты лайтинга и теней

шейдер света
шейдер тени 




все таки решил онли свою математику юзать ) ( нашел оптимизации для NEON и потихоньку пишу свою матлибу ( свет уже на ней работает ) 

что вошло в оптимизации 
свет
- свет без затуханий и т/д/ это самый банальный дот вектора светильника и нормали ) не чего лишнего 
- перенес нормализацию в вертексный буфер 
тени 
- убрал скейл и транслейт из пиксельного шейдера в матрицу рассчитываемую на CPU при изменении позиции светильника 
- не большая оптимизация по инструкциям 
было 
            vec3 smcoord = lpos.xyz / lpos.w;
            float shadow = float(texture2D(shadowMaps, smcoord.xy).x<=smcoord.z);
            float fSurfaceShadow = 0.25 * shadow + 0.75;
           color = color*fSurfaceShadow;
стало 
            highp vec3  smcoord = lpos_v.xyz / lpos_v.w;
            highp float d = texture2D(depthTexture, smcoord.xy).x;
            color = color;
            
            if (smcoord.z >= d) {
                highp float fSurfaceShadow = 0.75;
                color = color*0.75;
            }
вместо на каждый пиксель
- проверка 
- каст к флоату 
- умножение 
- сложение 
- умножение 
стало только для затеных пикселей 
- проверка 
- если да то одно умножение 


пока вроде все ) 

ЗЫ highp пока отбалды расставлены в переди еще оптимизация в этом плане ) 



среда, 19 февраля 2014 г.

Татирати та та та ))) я вернулся ! и теперь уже надолго !

да кстати тут была паралельная разработка 2д движка ( которая кстати скоро переедет в эту версию )

блог моего 2д двига - http://immortal-engine.livejournal.com/  ( да он уже не будет обновляться ! вся инфа теперь будет только тут )


что нового ?

эээ наверно много %) начнем с того что я последнее время читал и внимал математику основы С++ ( все таки нужно было заполнить пробелы ) и т/д/ вобщем очень во многом подтянул знания , пересмотрел в итоге многое и сейчас куски которые писались на протяжении всего времени собираются потихоньку в кроссплатферменный движок )


что есть ?

нус начнем

1 код конечно весь на С++
2 есть сборка уже под mac os и так же под iphone/ipad, чуть позже будет под андройд и когда нибудь под Win
3 оптимизации геометрии
- post-tnl ( пока выставлен в 8 - не доходят руки проверить сколько же на самом деле можно закешировать )
4 рендер на основе запросов, в крации
- есть класс который по объектам на сцене собирает листы объектов ( те что могут в камеру отбросить тень, те что в камере и т/д/, вобщем под запрос ) и создает запросы
- в рендере происходит отрисовка этих запросов ( при чем запрос можно отрендерить определенным рендером ( LPP / FR ), все это происходит прозрачно и на деле под нужную архитектуру исполняется только нужный код ( не каких проверок и т/д/, всем рулит система сборки запросов ), в целом уже сейчас можно рендерить объекты разными техниками к примеру есть в рендере такой метод - рендер воды(лист), в этот метод попадает объект если для него установлена техника рендера воды, не много сумбурно поэтому резюмирую - система собирает списки объектов для рендер запросов, в рендере есть цикл который выполняет запросы и получается картинка ), при этом если рендеру нужно будет отрендерить объекты только с текстурой, оверхеда не будет ... в развернутом виде произойдет вызов только нужных для этого методов
5 SSAO для ПС рендера
6 LPP для openGL ES3 или для PC
7 тени
8 попиксельное освещение ( разные типы источника света,  позже опишу подробнее )
9 офкос материалы, разные модели освещения, параметры и т/д/, можно уже сейчас лепить )
10 все это добро доступно благодаря допиленной системе микрошейдеров
что это на практике
к примеру есть такой вот шейдер shader0.xml



что он может ? 
1 есть порядок формирования основного шейдера ( за это отвечает zIndex ) 
2 из шейдера можно запросить нужные данные к примеру нам нужна позиции камеры 
добаляем

вауля у нас внутри шейдера можно юзать позицию камеры, все остально точно так же, все что нужно шейдеру можно задать и использовать ( конечно если система может это дать, для этого есть отдельный список того что может выдать рендер ) 

сам файл шейдера может содержать как вертоксную составляющую так и пиксельную а так же все вместе к примеру 
шейдер 1 shader1.xml


шейдер 2 shader2.xml





из этого система соберет вот это 

 uniform mat3 modelNormalMatrix;
 uniform mat4 perspectiveMatrix;
 uniform mat4 cameraViewMatrix;
 uniform mat4 worldObjectMatrix;
 attribute vec3 a_normal;
 attribute vec3 a_position;
 varying mediump vec3 normal;
 varying mediump vec4 position;
 void main(void)
{
normal=a_normal;
vec4 position = vec4(a_position,1.0);
        normal   =  a_normal*modelNormalMatrix;
        position = vec4(position.x*0.5+0.5,position.y*0.5+0.5,position.z*0.5+0.5,position.w);
    
        position = perspectiveMatrix*cameraViewMatrix*worldObjectMatrix*position;
    
 gl_Position = position;

}

 varying mediump vec3 normal;
 varying mediump vec4 position;
        highp float grid(highp float size){
            // hello
            return 1.0;
        }
    
    
 void main(void)
{
 mediump vec4 color;
        color = vec4(normal.x,normal.y,normal.z,1.0);
    
        color = vec4(color.x*0.5+0.5,color.y*0.5+0.5,color.z*0.5+0.5,1.0);
    
 gl_FragColor = color;

}

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

картинка 




















как видно нормали замылены благодаря второму шейдеру

едем далее

все кешируется, шейдеры, меши, и т/д/ в рендере идет выставление униформ и остального только если происходят изменения ( то есть в чистом проходе имеем вызов только glDrawElements )

- в системе сбора запросов оставленно место для алгоритмов отсечения
- лайтмапы + любые другие эффекты легко вставляются в текущую архитектуру

математика для OSX юзается GLKit для остального пока есть собственная реализация, которая постоянно улучшается )

на сегодня все ) по мере продвижения буду добавлять информацию

картинка с ПС ( LPP/SM/SSAO( которое не докручено и не видно тут )/направленный источник света )