Это не практический смысл, а исторический. Не всё поддаётся логическому объяснению, надо знать историю.
В чистом Си вообще не было переменной bool. В принципе, поскольку адресация памяти начинается с одного байта, создать единичную переменную такого типа невозможно в принципе.
Она всегда будет занимать места гораздо больше чем это требуется.
Для хранения битовой информации обычно используются флаги, но битовый доступ - лишние такты процессора. Иногда проще реально иметь отдельные переменные, пожертвовав памятью. В чистом Си была распространена практика делать bool из 32-разрядного числа. По идее такие числа на 32 разрядных процессорах имеют максимальную скорость доступа. По крайней мере в те далёкие времена. Традиция осталась.
В С++ Страуструп ввёл в язык переменную bool и принял её равной одному байту. И началась чертовщина, которую необходимо учитывать, когда имеешь дело одновременно с двумя языками.
Поэтому размер bool ВСЕГДА надо проверять, если код не слишком хорошо изучен.
В Сорсе вроде как студиомодели освещаются в один момент не более чем двумя источниками. Кто-нибудь в курсе, каким образом выбираются эти два источника, и как определяется, не в тени ли модель? Кидаются трассы до всех лампочек, и выбираются самые яркие?
Как вытащить из mdl анимацию? Хочу посчитать тени от моделей, геометрию вытащил, но многие модели повернуты анимацией, а я не могу разобраться, как она записана.
Все анимации в модели анализируются и для 6DOF находятся максимально возможные величины скейлов. Эти значения записываются в структуру костей. При извлечении анимации надо умножать полученные значения на них. Сами анимации точно так же делятся на 6 независимых потоков.
XYZ-pos, XYZ-rot.
C++ Source Code:
1
typedefstruct mstudioanim_s
2
{
3
unsignedshort offset[6];
4
} mstudioanim_t;
вот оффсеты до каждого из потоков.
Поток содержит двойственную информацию. Там либо RLE-данные, либо непосредственно значение анимации.
C++ Source Code:
1
typedefunion
2
{
3
struct
4
{
5
byte valid;
6
byte total;
7
} num;
8
short value;
9
} mstudioanimvalue_t;
Ну и дальше поток как бы рулит сам собой. Указываешь номер кадра, для которого нужно получить значение анимации (раздельно для каждой степени свободы). И в цикле ищешь нужный участок, ориентируясь по RLE-информации. См. функцию ExtractAnimValue в той же параное.
Вроде как ничего сложного.
ncuxonaT ты же код студиомоделей смотришь.
Извлечённое значение из анимации надо сперва умножить на скейл из структуры кости. А потом прибавить дефолтное положение скелета.
C++ Source Code:
final = bone->value + anim->value * bone->scale
Из полученных значений надо построить матрицы. Значения анимации - локальные. Т.е. матрицы еще надо перемножить друг на друга, согласно их иерархии. Сортировать кости при этом не требуется, скелет всегда отсортирован.
Добавлено 08-04-2021 в 21:37:
Кстати там потенциальная бага. Из-за сложения углов эйлера может получиться бяка. Но анимации как правило не содержат таких резких поворотов по нескольким осям.
Как мне правильно отрисовать хулл энтити через опенгл? Начну с того, где взять правильный оригин? cl_entity_t->origin и cl_entity_t->curstate.origin почему-то выдает разные числа. А еще, как повороты учитывать? Я вот скопипастил матрицу трансформации для энтити из ксашмодовской GL_CacheState, каждую вершину хулла умножаю на матрицу, и в итоге оно при повороте энтити куда-то улетает. Не пойму что делать.