Дядя Миша да не, я не об этом.
Вот когда рассчитываешь текстурные координаты фейса под лайтмапу, берешь обычные текстурные координаты и вписываешь их в квадрат (0,0) - (1,1). По краю делается какой-то "бортик"? Ну то есть вписывается в квадрат (0.1,0.1) - (0.9,0.9) или что-то такое?
ncuxonaT писал: берешь обычные текстурные координаты и вписываешь их в квадрат (0,0) - (1,1).
А зачем вписывать координаты в квадрат? Ты вообще изучал как в кваке сделано?
Для кажого фейса считаются экстентсы. Это высота и ширина в диффузки в пикселях. Далее, поделив их на кол-во пикселей на люксель мы узнаем экстентсы для самой лайтмапы, ну или проще говоря - её разрешение. Ну и прибавляем к получившемуся результату еденичку, в случае если получился нулевой размер лайтмапы по какому-то из измерений. Теперь, когда мы знаем размер лайтмапы - мы можем выделить под него новое место в атласе. А когда в атласе не останется места, загрузим его в видимопамять, а сами перейдем к следующей странице атласа. У нас остаются light_s и light_t - это смещения в пикселях относительно верхнева левого угла текущей страницы атласа (которая в lightmaptexturenum). Теперь, когда мы их знаем - мы можем легко расчитать текскорды длялайтмапы через DotProduct от текстурной матрицы.
C++ Source Code:
1
s = DotProduct( vec, fa->texinfo->vecs[0] ) + fa->texinfo->vecs[0][3];
2
s -= fa->texturemins[0];
3
s += fa->light_s * sample_size;
4
s += sample_size >> 1;
5
s /= BLOCK_SIZE * sample_size; //fa->texinfo->texture->width;
6
7
t = DotProduct( vec, fa->texinfo->vecs[1] ) + fa->texinfo->vecs[1][3];
8
t -= fa->texturemins[1];
9
t += fa->light_t * sample_size;
10
t += sample_size >> 1;
11
t /= BLOCK_SIZE * sample_size; //fa->texinfo->texture->height;
Если бы мы рассчитывали текскорды для обычных текстур нам было бы достаточно просто поделить s или t на высоту\ширину диффузки.
А для лайтмапы надо еще сделать ряд вычислений, с поправкой на то, что она находится в атласе. BLOCK_SIZE = это ширина и высота атласа (он квадратный). Но конечно никто не мешает делать прямоугольные атласы например.
Добавлено 16-03-2017 в 19:58:
А. texturemins это такая хрень, связанная с тем, что в кваке текстуры накладываются не из верхнего левого угла, а из правого нижнего или что-то в этом роде. Причём оно уже на уровне формата map, такая же въедливая гадость, как и Stupid Quake Bug и избавиться от нее удалось вроде бы как только в Quake3, даже в сорсе помоему оно осталось.
Дядя Миша ну вот в атласе текстурные координаты фейса точно совпадают с его лайтмапой, или они чуть меньше? Потому что я распаковал эти фрагменты лайтмап, и у соседних кусков крайние ряды пикселей совпадают.
Я думаю там режим текстуры clamp_edge или типа того (nomipmaps тоже вероятно должно быть).
В к3 такая фигня с крайними пикселями, если лайтмапа внешняя задана шейдером; внутренние по-другому налаживаются, корректно.
Какой толк от CLAMP_TO_EDGE, если лайтмапа в атласе?
Если карта состоит из одного квадратного фейса, какие у него будут текстурные координаты лайтмапы? 0,0-1,1?
Ну вот кроч. 2 куска из лайтмапы, соприкасающиеся пиксели у них совпадают, поэтому если их просто сложить рядом, получится такая ступенька. Но в игре такой ступеньки нет. Такое может быть, только если текстурные координаты сдвинуты от краев фрагмента. Так на сколько они всё-таки сдвигаются?
Я беру у Trigger_Camera его yaw и передаю мессагой на клиент, прибавляю его ко viewangles игрока. Таким образом, утрируя, W и S всегда двигают игрока по оси камеры. Однако при стрейфе мы не движемся по ровному кругу вокруг камеры, как должны бы, а быстро уходим прочь по спирали. Чтобы идти по кругу, нужно повернуться к камере на лишние примерно 20 градусов. Это тот самый предиктинг виноват? Просто у камеры стоит SetNextThink ( 0 ), так что не похоже. Я пробовал менять cl_lc, cl_lw, безрезультатно. Попытался прикрутить для сглаживания углов функцию V_SmoothInterpolateAngles ( ) которая во view.cpp, но я вроде кормлю ей такие же vec3_t, а она выдаёт ошибку преобразования типов.