Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Немного софтверного рендеринга (7 стр)

Немного софтверного рендеринга (7 стр)

Поделиться

Страницы: 1 2 3 4 5 6 7 8 Следующая

122Постоялецwww26 окт. 20170:30#90
eDmk
> Есть почти такой же
Нет. :)
FordPerfectПостоялецwww26 окт. 20170:32#91
>У меня софтверный движок с треугольниками у которых отрицательная площадь.
И что?

>Для этого нужна обратная Dot-функция.
Для чего "этого". И вообще - с чего бы это?

>А то все будет вогнутым.
С чего бы это? И каким именно вогнутым?
И с чего бы это решать арккосинусом, а не сменой знака площади.

>На железке легко сделать снизу вверх, а в софтвере не очень, т.к. SetDIBitsToDevice рисует сверху вниз.
Я не уверен, что это правда.
Ну и StretchDIBits - явно умеет и это. Я через неё делал у себя.

FordPerfectПостоялецwww26 окт. 20170:38#92
>Вот только в затенении есть разница. По вашему методу тени жесткие получаются.
>Сравните с моей версией. Увидите разницу. Затенение плавнее и мягче.
Можно полностью формулы, по которым считается и в том и в другом случае?
И скриншоты.
eDmkПользовательwww26 окт. 20170:45#93
122
Похожая сцена. Около 14 тыс полигонов.
Тут exe и файл называется cube_test.obj
+ Показать

Слепил на скорую руку в 3ds max, так что немного не похоже.

Правка: 26 окт. 2017 0:47

eDmkПользовательwww26 окт. 20171:05#94
>Можно полностью формулы, по которым считается и в том и в другом случае?
Код затенения:
+ Показать

Изображение не корректировал. Скриншот как есть.
Мне на моем калиброванном мониторе разница видна хорошо.

+ Показать

Я по формуле делал с mathprofi.ru. Вроде норм сайт по математике.
Матрицы и прочее тоже по формулам. Все пашет.

Правка: 26 окт. 2017 1:11

FordPerfectПостоялецwww26 окт. 20172:04#95
eDmk
Ага, спасибо.
В этой версии формула наверно же должна быть
begin
  Result := VecCosAngle(LightDir, FaceNormal);
  Clamp(Result, 0.0 , 1.0);
  Result := KM + Result * (1.0 - KM);
end;

А смысл твоей

CosAngleTabS(Angle - (Angle * KM));
я вообще не особо понял. Но минимальную яркость она даёт CosAngleTabS(90.0 - (90.0 * KM)), что примерно равно [cht]\frac{\pi}{2} KM[/cht], насколько я понимаю.
Что в ~1.57 раз выше, чем для первого случая, ну и clamp подкорректировать.

122Постоялецwww26 окт. 20173:14#96
eDmk
Не, я говорил про твою фразу из #89 сообщения:
> Есть почти такой же (процентов 85% по скорости). Почти весь на асме написан.
А по ссылке там ведь не он? Потому что по ссылке где-то 8% по скорости от моего рендера. А не 85%.
Если не трудно, покажи вот тот, на асме и быстрый.
eDmkПользовательwww26 окт. 20173:27#97
>А по ссылке там ведь не он? Потому что по ссылке где-то 8% по скорости от моего рендера. А не 85%.
По сылке барицентрический вариант. Завтра выложу. Мне сейчас спать хоцца )
eDmkПользовательwww26 окт. 20173:30#98
>я вообще не особо понял.
Чтобы тени сзади не убивались в ноль. Просто немного сжимаю диапазон.
Типа Ambient.
+ Показать

Обновленный код:

+ Показать

Правка: 26 окт. 2017 3:49

SuslikМодераторwww26 окт. 20173:49#99
eDmk
> Типа Ambient.
> Result := CosAngleTabS(Angle - (Angle * KMin));
ambient считается не так. дело, конечно, твоё, но в таких делах обычно лучше отсебятиной не заниматься и не подгонять структуру формулы. если тебе хочется получить какой-то конкретный вид результата, то подгоняй коэффциенты в формулах, а не сами формулы. разумеется, от тригонометрии в формулах освещения, тем более софтварного, всегда лучше избавляться, мало того, что это дольше считается, в этом ещё и смысла особого нет, потому что в реальной физике освещения вроде phong'а тригонометрии просто нет.

например, самое простое освещение из диффуза и эмбиента считается примерно так:

resColor = (max(0, -dot(view, norm)) * diffuse + ambient) * materialColor * lightColor;
здесь diffuse + ambient = 1 — скалярные коэффициенты, определяющие баланс между диффузом и эмбиентом. materialColor — rgb вектор цвета поверхности, lightColor — rgb вектор цвета источника, умножение подразумевается покомпонентное. view — вектор от камеры к элементу поверхности, norm — нормаль поверхности.

если тебе хочется меньше черноты в затенённых областях, то не занимайся шаманством, а просто прими, например diffuse = 0.6, ambient = 0.4.

MikleМодераторwww26 окт. 20178:30#100
eDmk
> SetDIBitsToDevice рисует сверху вниз
Заполняя структуру bi32BitInfo.bmiHeader, подставь в biHeight отрицательное значение - и SetDIBitsToDevice сменит направление заливки экрана.
ХаусПостоялецwww26 окт. 201713:26#101
eDmk

Сделай чайник с освещением Ами Гуч, как у Борескова на сайте.
eDmkПользовательwww26 окт. 201713:34#102
>подставь в biHeight отрицательное значение
Так с отрицательным она рисует сверху вниз. С положительным снизу вверх.
Координаты меняются после этого. Всю библиотеку переписывать.
У меня там и вывод шрифтов и линии и полигоны и прочее. Геморрой короче.
Все переписывать с учетом обратного вывода.
eDmkПользовательwww26 окт. 201713:39#103
>Сделай чайник с освещением Ами Гуч
Если у вас софтверный движок, то выкладывайте.
OpenGL здесь не обсуждаем.
ХаусПостоялецwww26 окт. 201713:45#104
eDmk
> Если у вас софтверный движок, то выкладывайте.

У тебя есть. Забыл? :)

Страницы: 1 2 3 4 5 6 7 8 Следующая

/ Форум / Программирование игр / Графика

2001—2017 © GameDev.ru — Разработка игр