пятница, 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 пока отбалды расставлены в переди еще оптимизация в этом плане )