ErV юка1на счет обилия литературы скорее всего наврал, не так понял задание:)

но все равно, не очень понятно задание, что в конечном счете нужно?

нужно сжать массив в памяти, проиндексировать матрицы и искать их по индексу? Или нужен поиск только по t?
Конкретно пожалуста.

Потеря точности при сжатии допустима или нет?

Скорее всего есть методичка/лекции/книжка или что-либо подобное, где описываются подобные примеры. Ее авторы частенько живут в своем узеньком мире, так что, возможно, нужно смотреть эту методичку и там будет сказано как это делать и все сведется к вычислению среднего арифметического:)

проиндексировать все варианты матрицы можно единичным вектором, например, с конечной точностью. но это просто мысль.

я тебе завидую:)
короче, нужен "поток" структур Element. который хранится в памяти в фиг знает каком виде(сжатом), и позволяет установить в нем позицию считывания (медленно), и промотать/считать весь поток подряд по одному элементу с позиции к концу либо к началу(быстро/оптимизироавнно). Причем все это должно хранится (желательно) в памяти. короче, это что-то аналогичное cжатию аудио и видео.
"матрица трансформации/поворота" и т.д. обозначает, что x, y, z образуют локальную координатную систему(вектора системы), они взаимно перепендикулярны для каждого элемента но длина >= 0 и она у все разная может быть, а p задает смещение системы. от элемента к элементу значения меняются. Потери лучше не стоит, либо не слишком большие, либо чтобы можно задать было) Приемлимая потеря зависит от разброса значений.
ясно, что xyz во всех векторах кроме p находится приблизительно в разбросе
- (-some_value..0]&&[0..+some_value); максимальная потеря - где-то 1% от some_value. для p - аналогично, но не больше 0.01f.

Я уже спать, хочу и по-русски никак, только кодом... :) :) :)
Если кому чего непонятно, ниже писанина сонного программиста...
нужно приблизительно следующее:
class DataStorage{
public:
int getNumElements();
void setElementIndex(int index);//медленно
int getElementIndex(void)
void getCurrentElement(Element& destination);
void nextElement(void);//
void prevElement(void);
protected:
void* packedData;
DWORD packedDataSize; //packedDataSize < getNumElements()*sizeof(Element)
};

//где-то в коде:
DataStorage* dataStorage = //инициализация и т.д.
Element tmp;
dataStorage->setElementIndex(0);
do{
dataStorage->getCurrentElement();
dataStorage->nextElement();
doSomethingWithElement(tmp);
}(while(dataStorage->getCurrentIndex() < getNumElements()));

Ещё вопросы?
Если знаете литературу, киньте ссылку, что ли...


Моя идея может показаться не совсем здравой, но светаки:

Попробуйте заменить систему координат.
Зачем иметь три значения коорднат xyz и длину ,
если можно иметь только угол и длину .
Такой подход позволит получить сжатие ~30 %
практически без потери точности.
Потеря точности будет будет только в последнем разряде при
вычислении длин тригонометрическими функциями.


з.ы. Внутренний голос мне подсказывает, что помимо сжатия
вы получите и прочие дивиденды, с точки зрения оптимизации расчетов.

Pavel Kilevatyh onstat-
Попробуйте заменить систему координат.
Зачем иметь три значения коорднат xyz и длину ,
если можно иметь только угол и длину .
Такой подход позволит получить сжатие ~30 %
практически без потери точности.
Потеря точности будет будет только в последнем разряде при
вычислении длин тригонометрическими функциями.


Вах! Какая красивая мысль.
Только мне кажется два угла нужно, мы же в пространстве работаем.


Да, точно, 2 угла и длина.

Если говорить об оптимизации хранения длины то достаточной точности длина умещатся в 1 бйт(7 бит) исходя из

ErV
ясно, что xyz во всех векторах кроме p находится приблизительно в разбросе
- (-some_value..0]&&[0..+some_value); максимальная потеря - где-то 1% от some_value. для p - аналогично, но не больше 0.01f.


А мантису(порядок) значения можно регулировать в зависимости от
необходимого разброса максимального и минимального значений.
Если 10 в степени 255 будет достаточно то тоже 1 байт.

ErVспасибо, конечно, но:
1) одного и двух углов будет недостаточно, нужен кватернион, к тому же вектора системы координат могут менять длину, соответственно ещё нужно включить масштабирование. Вычисления эти варианты не сэкоомят, так как все равно надо будет переводить в матрицы. Этот вариант даст
4(кватернион)+3(масштабирование)+3(позиция)флоата вместо 12. ИМХО, это мало. fixed-point, теоретически, приемлимо, но, блин...
идея была о создании хранилища сжатых данных, заточенного под последовательный перебор элементов. И интересовало не оптимизация варианта хранения данных, а именно их сжатие. Есть ещё варианты?


У меня немного не хватает знаний, немогли бы Вы Обьяснить что такое
кватернион.

И еще вопрос, зачем засобой таскать в каждом обьекте систему координат
без самого рассматриваемого объкта.

Я догадываюсь, что там есть вектор, ради него все это и делатся
и вычисляется через длины взамноперепендикулярных векторов.

Если смотреть в корень то сам вектор это две точки и направление.
Или одна точка, длина и угол(ы).
Может оптимизацию хранения построить на этом.

Это меньше чем три взамноперепендикулярных вектора.

По поводу сжатия очень правилная фраза была сказана:

Pavel Kilevatyh
на совсем случайных величинах никакой алгоритм сжатия не даст хорошего результата.

Если применять сжатие с потерей качества, то необходимо кардинально менять структуру потока.

Алгоритмы пытаются привести участок сырого потока
к какой либо извесной функции
например y=х^n , y=sin(x) и тд,
В сжатую последовательность записывается функция , длина и дискретность.

Чем больше функций может поймать алгоритм в потоке
тем выше качество сжатия.

При разжатии через извесные функции вычисляются значения потока.

Думаю вас такой вариант не устроит, так как Ваша память
будет содержать экстремумы, которые могут быть сглажены.

Например: Как вы относитесь к искаженю значения t.

ErV e
ErV
Запиши пример этой таблицы в отдельный бинарник и попробуй его сжать чем-нибудь. Если сожмётся то сжимай, а нет то тогда за счёт оптимизации хранения.
float t;
union{
struct{
float x[3];
float y[3];
float z[3];
float p[3];
};
float m[4][3]
};
p - я так понимаю длинна вектора. Если не жалко времени, то
p=sqrt(x^2+y^2+z^2).
[/quote]
Таблица хорошо сжимается, уже пробовал. Не в 10 раз, но в 2..4 точно есть.
p - это не длина вектора. Это адрес точки "ноль" координатной системы, образованной векторами x, y, z. система (x, y, z ,p) находится в мировом пространстве. Для того, чтобы выполнить перенос из этой системы в мировую, надо сделать (x, y, z, p, newPos, oldPos - вектора):
Vector3 newPos = oldPos.x*matrix.x + oldPos.y*y + oldPos.z*z + p;
Ради этого все и затевалось.

"поток" представляет собой набор трансформаций анимационных ключей для объекта/структуры объектов. соответственно, поле t - время в секундах(нельзя терять), когда эта трансформация наступает, а m - состояние локальной системы координат в этот момент. При работе фактически в памяти хранятся два ключа, матрицы которых интерполируются(не "в лоб", там хитрее, но это ещё на пол страницы писанины) по значению (currentTime-prevKey.t)/(nextKey.t-prevKey.t); Надеюсь, что понятно объяснил :) соответственно, данные меняются относительно "плавно". Однака кривая изменения для текущего варианта будет ломаной линией, так как интерполяция позиции, например - линейная (result = a1*(1-f)+a2*f, гда f принадлежит 0..1.0f;). Соответственно, на этом как-то можно сыграть, но просто не знаю какой алгоритм/область данных смотреть, из-за чего тема и возникла.

[quot]
У меня немного не хватает знаний, немогли бы Вы Обьяснить что такое
кватернион.

кватернион - это четырехкомпонентный вектор (xyzw), получаемый из оси вращения, выраженной единичным вектором и синуса/косинуса угла поворота.
Вот цитата(пардон, что инглиш) ещё можно глянуть в сети "The Matrix and Quaternions FAQ". Тоже инглиш.:
[fix]
Q56. How do I convert a rotation axis and angle to a quaternion?
----------------------------------------------------------------
Given the rotation axis and angle, the following algorithm may be
used to generate a quaternion:
------------------------------------------------
sin_a = sin( angle / 2 )
cos_a = cos( angle / 2 )
q -> x = axis -> x * sin_a
q -> y = axis -> y * sin_a
q -> z = axis -> z * sin_a
q -> w = cos_a
quaternion_normalise( q );
------------------------------------------------
It is necessary to normalise the quaternion in case any values are
very close to zero.
[/fix]
Это удобно при интерполяции двух вращений - при линейной интерполяции двух систем координат у них нарушается перпендикулярность, и объекты скособочиваются (в 3D графике/играх). (так, похоже, я начинаю перезагоняться :))


И еще вопрос, зачем засобой таскать в каждом обьекте систему координат
без самого рассматриваемого объкта.

Я догадываюсь, что там есть вектор, ради него все это и делатся
и вычисляется через длины взамноперепендикулярных векторов.
...

Там не вектор. Я сейчас игровой движок доделываю, ради него все и делается. Есть система анимации персонажей/объектов, которая хранит набор треков как раз в виде массиово этих структур. На персонажа треков может быть порядка от двенадцати и где -то до 40. Трек и является таким "потоком" Все хорошо работает, удалось даже разгнать все за счет применения двоичного поиска, но вот меня сильно не радует размер, который все это дело (данные анимации) в памяти занимает. Ключей в треке может быть 1, а может быть и несколько тысяч. Имхо - это слишком много, а пямять потом нужна на звук, физ движок (который её кушает быть здоров), и много ещё чего. Кроме того, файлы с анимации в бинарном виде (читай - дамп этого самого потока) весят немало.

Если смотреть в корень то сам вектор это две точки и направление.
Или одна точка, длина и угол(ы).
Может оптимизацию хранения построить на этом.

Хорошая идея, я про это забыл, но в случае с масштабированием осей не будет работать.


По поводу сжатия очень правилная фраза была сказана:
Поток не из случайных данных, см выше.

Просто подскажите хотя бы доки/линкам по компрессии данных (инглиш, плиз)/алгоритмам.


У Вас есть точка начала координат, у вас есть взимно перпендикулярные вектора.
Если вы будете хранить только вектор, с помощью тригонометрических
функций вы сможете воссоздать ваши взаимно перпендикулярные вектора
в момент когда очередь дойдет до обработки конкрентого элемента.

Храните помимо вектора и масштабирование, думаю оно влезет в 1 байт для
каждой оси. Т.Е.