- Che@ter
- Постоялец
Тут буду писать вопросы, касающиеся работы моего (будущего) "растеризатора". Если, конечно, тему не удалят, т. к. вопросы будут банальные.
Опишите (кратко) последовательность действий, выполняемых видеокартой перед выводом геометрии на экран.
Допустим, есть массив вершин (пусть пока только позиции). Какие преобразования вершин совершает видеокарта? И когда? До вершинного шейдера, или после?
Далее, пусть обход вершин совершается против часовой стрелки. Беру по три вершины. Как отбрасывать треугольники, расположенные к камере "задом"? Конкретно, откуда видеокарта берет первоначальный вектор "взгляда"?
Какие в принципе есть алгоритмы по отсечению треугольника областью экрана? Как и когда преобразовывать глобальные координаты в экранные?
???
Все ответы можно найти тут: http://www.ozon.ru/context/detail/id/1692806/
static_cast
> откуда видеокарта берет первоначальный вектор "взгляда"?
Позиция камеры в нулях, поэтому отсекает если угол между нормалью треугольника и вектором взгляда треугольника в нули больше 90 градусов. По крайней мере такой алгоритм должен работать.
static_cast
http://habrahabr.ru/post/248153/
mutcher
я видел это, но кое-что не понятно:
for (int i=0; i<model->nfaces( ); i++) { std::vector<int> face = model->face( i); Vec2i screen_coords[3]; Vec3f world_coords[3]; for ( int j=0; j<3; j++) { Vec3f v = model->vert( face[j]); screen_coords[j] = Vec2i( ( v.x+1.)*width/2., ( v.y+1.)*height/2.); world_coords[j] = v; } Vec3f n = ( world_coords[2]-world_coords[0])^( world_coords[1]-world_coords[0]); n.normalize( ); float intensity = n*light_dir; if ( intensity>0) { triangle( screen_coords[0], screen_coords[1], screen_coords[2], image, TGAColor( intensity*255, intensity*255, intensity*255, 255)); } }
откуда light_dir (вектор взгляда, если забыть про освещение) берётся в видеокарте?
screen_coords[j] = Vec2i(( v.x+1.)*width/2., ( v.y+1.)*height/2.);
где полагается начало координат?
+ тут нет обрезки треугольника, если он попадает в экран частично.
А зачем видеокарта "нормализует" вершины?
с обрезкой разобрался (не самым эффективным образом, но самым простым)
static_cast
Какими средствами собираешься выводить сформированную твоим растеризатором картинку на экран, если не секрет?
denesik
что конкретно подразумевается? Я вывожу всё в окно средствами winapi (даже тему создал!)
static_cast
> winapi
гемор тот еще, ну либо на любителя)
Задавался данным вопросом недавно, решил что glfw подходит лучше всего. Кроссплатформенная, держит все версии огл, теоретически если юзать огл 1.0, будет работать на всех компах.
В твоем случае написать пару строк кода - рисование одной текстурки на весь экран и будет рантайм счастье.
Не надо париться с созданием окна, с обработкой клавы/мыши.
Не содержит совершенно ничего лишнего.
https://github.com/Steve132/uraster
Micro simple software rasterizer in a single C++11 header file. Does not use OpenGL. Pure C++11.
Mostly useful as a way of teaching how the rendering pipeline in hardware works.
denesik
ха, я просто не думал даже об glfw. Уже "вступил" в винапи. Но мне код на нём даже нравится, что ли. Красиво так.
abnormality.Iga
вот это пригодится. Думаю всё еще, следует ли выделять шейдеры в структуре.
чего-то я не понимаю, как получается, что при переходе от debug в release версию фпс растёт с 24-30 до 150-600+???
static_cast
> чего-то я не понимаю, как получается, что при переходе от debug в release
> версию фпс растёт с 24-30 до 150-600+???
Ну это же хорошо, так и должно быть, или нет?
static_cast
Очевидно что кадр выполняется быстрее.
В релизе не компилится код, предназначенный для дебага, к примеру #if _DEBUG, assert().
В релизе не используются библиотеки для отладки.
В релизе используются различные оптимизации.
Так что все ок.
static_cast
> чего-то я не понимаю, как получается, что при переходе от debug в release
> версию фпс растёт с 24-30 до 150-600+???
Ну сам подумай, если бы не было прироста/падения производительности, то зачем вообще существовало бы разделение на версии?
Тема в архиве.