Мат. либа, основанная на GLSL.

Сейчас вот новым движком занят и думаю, что лучше не оставлять старую мат. либу, а написать новую.
А за основу взять GLSL.

Вот хочу определиться в некоторых моментах.
Например, стоит ли использовать GLSL'вскую функцию mix вместо привычного lerp?
Какие методы стоит добавить в вектор/матрицу?
Например, мне кажется логичным использовать функцию dot вместо перегруженного оператора умножения (как в GLSL), т.к. скалярно перемножить 3 вектора нельзя, а при расчёте освещения, напр., будет чётко видно, где какие действия выполняются.
Также имеет смысл все конструкторы делать explicit, т.к. неявные преобразования (implicit), запрещённые в GLSL, могут усложнить поиск ошибок.
Нужен ли метод normalize или достаточно глобальной функции?
Как делать инвертирование матрицы, в виде глобальной функции или метода? Сколько перегруженных форм нужно?
Нужен ли класс матрицы 3х4? Или можно просто использовать 4х4, тогда стоит ли перегружать оператор умножения для произведения 4-хмерной матрицы аффинного преобразования и 3-хмерного вектора, или для понятности лучше использовать vec3(SomeMat44*vec4(SomeVec3,1.0))?
Аналогично с матрицей 4х4, содержащей перспективное преобразование: нужна перегрузка operator* для 3-хмерного вектора или перспективное деление выполнять каждый раз вручную "resVec4=SomeMat44*SomeVec4; resVec4=vec4(resVec4.xyz/resVec4.w,1.0);". А может лучше, в этом случае использовать глобальную функцию?
Стоит ли делать класс plane, или же достаточно вектора?
Нужен ли swizzling? Или можно обойтись без него?

Здесь я не хочу обсуждать реализацию, прошу высказывать только мнения о том, какие функции необходимы, какие названия им больше подходят и т.д. Только проектирование.
Если бы создатели GLSL делали мат. либу для 3D-движка, то какой бы она была?
Целью нашего обсуждения должна стать не готовая полноценная библиотека, а лишь проект/спецификация её части, не включающей всякие AABB, OBB, кватернионы и т.д.
То есть некий набор мат. функций/классов, максимально удобный для применения в большинстве областей 3D-графики.

Берешь доку по глсл и один в один ее на ++ переводишь :-)
Я так сделал.

viv
>Берешь доку по глсл
Доку то я целиком прочёл. Это всё понятно.
>Я так сделал.
Молодец, что сделал. Но ты ж что-то добавил. Вопрос как раз в том, что именно.
Ведь математики GLSL явно недостаточно для очень многих вещей.

all
Ну может кто-нить хоть просто ответит на мои вопросы в первом посте. Как лично он считает сделать лучше.

Неужели ни у кого никаких мыслей нету? Давайте  же делать GLML (GL Math Lib) !!!    :-)

tav

>> А за основу взять GLSL.

а почему именно её?

>> Например, стоит ли использовать GLSL'вскую функцию mix вместо привычного lerp?

не гуру GLSL, скромно промолчу.

>> Какие методы стоит добавить в вектор/матрицу?

да никаких, всё что можно во free-функции

>> Например, мне кажется логичным использовать функцию dot вместо перегруженного оператора умножения (как в GLSL), т.к. скалярно
>> перемножить 3 вектора нельзя, а при расчёте освещения, напр., будет чётко видно, где какие действия выполняются.

мне кажется обратное.

>> Также имеет смысл все конструкторы делать explicit, т.к. неявные преобразования (implicit), запрещённые в GLSL, могут усложнить поиск
>> ошибок.

имеет.

>> Нужен ли метод normalize или достаточно глобальной функции?

free-функция

>> Как делать инвертирование матрицы, в виде глобальной функции или метода?

free-функция

>> Сколько перегруженных форм нужно?

???

>> Нужен ли класс матрицы 3х4?

нет

>> Или можно просто использовать 4х4, тогда стоит ли перегружать оператор умножения для произведения 4-хмерной матрицы аффинного
>> преобразования и 3-хмерного вектора,

нет

>> или для понятности лучше использовать vec3(SomeMat44*vec4(SomeVec3,1.0))?

нет

>> Аналогично с матрицей 4х4, содержащей перспективное преобразование: нужна перегрузка operator* для 3-хмерного вектора

нет

>> или перспективное деление выполнять каждый раз вручную "resVec4=SomeMat44*SomeVec4; resVec4=vec4(resVec4.xyz/resVec4.w,1.0);".

да

>> А может лучше, в этом случае использовать глобальную функцию?

да

>> Стоит ли делать класс plane?

да

>> Нужен ли swizzling? Или можно обойтись без него?

нет

ну как тсало легче?

tav
>Например, мне кажется логичным использовать функцию dot вместо перегруженного оператора умножения (как в GLSL)
Вообще говоря, в GLSL функцией dot оно и есть. Практически все операторы в GLSL покомпонентны (кроме умножения матрицы на вектор и обратно), в том числе и умножение векторов. Это мне кажется очень здравой идеей.
edit: Впрочем, может как раз это ты и имел в виду )

A_K
>>> Нужен ли swizzling? Или можно обойтись без него?
>нет
Нет, не нужен? или нет, нельзя обойтись? :)

Sark7

>> Нет, не нужен?

на фиг мне такое на C++. на том же самом HLSL он полезен, да. но в плюсах мне оно не надо.

Thanx for answers!

A_K
>а почему именно её?
Дык я лучше не видел. Удобно сделана. Возможно, просто т.к. там очень мало функций, вот и нет ничего неудобного.
>> Например, стоит ли использовать GLSL'вскую функцию mix вместо привычного lerp?
>не гуру GLSL, скромно промолчу.
Дело в другом. Просто в GLSL lerp (ну, в HLSL, напр.) имеет другое название mix при тех же самых аргументах.
Вопрос: какое название выбрать? Ну можно так переформулировать: какое название, по твоему, больше понравиться большинству программистов 3D-графики и физики?

>> Сколько перегруженных форм нужно?
>???
Я имел в виду void mat4::invert(), void mat4::invert(const mat4 &m), mat4 invert(const mat4 &m), invert(mat4 &m). Что тут оставить, а что лучше убрать с твоей точки зрения. (А может вообще 'inverse' более общепринято, или нет?)

>>> или перспективное деление выполнять каждый раз вручную "resVec4=SomeMat44*SomeVec4; resVec4=vec4(resVec4.xyz/resVec4.w,1.0);".
>да
>>> А может лучше, в этом случае использовать глобальную функцию?
>да
На месте Pentium'а я бы завис. :-) Двойное противоречие.

>ну как тсало легче?
угу

>на фиг мне такое на C++.
Ну почему. Иногда удобно записать "flatVertex=volumeVertex.xy". Примитивный swizzling имхо, очень полезен (т.е. когда компоненты идут подряд и это элементарно делается через union'ы). А вот конструкции вида "v1.xzy=v2.yzx;" реализовать труднее, но всё же можно, и к потере производительности это не приведёт.
Не поменял своего мнения?

Sark7
>Впрочем, может как раз это ты и имел в виду
Ага. Это я просто рассуждал о "правильности GLSL". Ну я сам виноват, написал действительно двузначно.
>кроме умножения матрицы на вектор и обратно
Ну и матрицу на матрицу забыл добавить. Это всё естественно. Просто что бы не повторять спеку, считай, что в мат. либе будет весь GLSL, а остальное -- коррективы и добавления.

tav

>> какое название, по твоему, больше понравиться большинству программистов 3D-графики и физики?

lerp

>> Что тут оставить, а что лучше убрать с твоей точки зрения

mat4 invert(const mat4 &m),

>> На месте Pentium'а я бы завис. :-) Двойное противоречие.

вручную дели или фнукции специальную делай как душе угодно

A_K
>> Что тут оставить, а что лучше убрать с твоей точки зрения
>mat4 invert(const mat4 &m),
Ну ладно. Правда IC++Compiler 7.1 компилит "invMatr=inverse(matr);" похуже, чем "invMatr.invert(matr);", ну и ладно. Зато вариан с free-функцией универсальный и его одного достаточно.
(Кстати, а что такое free-функция? Глобальная? Дружественная? (хотя последнее бессмысленно, т.к. все члены math-классов открыты) Или что-то другое?)

Попробую задать очередную порцию вопросов. :-)

Как лучше назвать функцию нахождения квадрата длины вектора? sqLen()? squareLength()? sqlen() ?
Если роль плоскости будет играть vec4, как назвать функцию нормализации плоскости? normalizePlane() или planeNormalize() ?
Подойдёт ли название ф-ии умножения матрицы перспетивного преобразования на 3-хмерный вектор: vec3 persp[ective]Mult(const mat44 &,const vec3 &)?
Аналогично для матрицы аффинного преобразования (т.е. что-то вроде 3х4, но занимает памяти 4х4): vec3 aff[ine]Mult(const mat44 &,const vec3 &)?
Как обозвать функцию, выполняющую "return vec4(v.xyz/v.w,1.0);"? vec4 persp[ective]Div[ision](const vec4 &v)? Или лучше возвращать vec3 вместо vec4?
Нужна ли функция получения плоскости (vec4) по 3-м вершинам, что-то вроде vec4 trianglePlane(vec3,vec3,vec3) ?

>>Как лучше назвать функцию нахождения квадрата длины вектора? sqLen()? squareLength()? sqlen() ?
qlength(); //q - quad || q - quick
>>Если роль плоскости будет играть vec4, как назвать функцию нормализации плоскости? normalizePlane() или planeNormalize()?
если глобальная, то 1-ый вариант, если метод класса то просто normalize(); norm();
>>Нужна ли функция получения плоскости (vec4) по 3-м вершинам, что-то вроде vec4 trianglePlane(vec3,vec3,vec3) ?
думаю лишней не будет, я бы обозвал vec4 makePlane(const vec* vertex); || vec4 buildPlane(const vec* vertex);
или сделай класс Plane отдельно и пусть эту роль выполняет конструктор.
>>return vec4(v.xyz/v.w,1.0);
а для чего она?

Aroch
>>>Как лучше назвать функцию нахождения квадрата длины вектора? sqLen()?
>>>squareLength()? sqlen() ?
>qlength(); //q - quad || q - quick
Не. Не пойдёт. quad можно перевести как "учетверённый", а square -- только как квадратный (ну, ещё есть значения слова, но они с математикой не связаны)

>>>Нужна ли функция получения плоскости (vec4) по 3-м вершинам, что-то вроде
>>>vec4 trianglePlane(vec3,vec3,vec3) ?
>думаю лишней не будет, я бы обозвал vec4 makePlane(const vec* vertex); || vec4
>buildPlane(const vec* vertex);
Хм. Как-то это не по GLSL-вски. Может triangleNormal (или cross(vec3,vec3,vec3) ) сделать? А потом вручную если надо уже компоненту D плоскости искать как -dot(N,v0)?

>или сделай класс Plane отдельно и пусть эту роль выполняет конструктор.
Не. Это гон. Только ради конструктора делать целый класс. (Ну, може ещё пара методов наберётся, вроде нормализации и пересечении с прямой, ну и операторы >,<,==,>=,<=.  Во. Кстати, а как обозвать функцию пересечения с прямой с плоскостью? getPlaneIntersect()? planeIntersect()? lineWithPlaneIntersect()?

>>>return vec4(v.xyz/v.w,1.0);
>а для чего она?
Напр., у тебя вектор в однородных координатах, и его нужно перевести в декартовы координаты. В этом случае нужно выполнить перспективное деление, т.е. деление всех компонент вектора на w.

Только что увидел ссылку в новостях, на OpenGL.org

http://glf.g-truc.net/

_NetSurfer_
М-да. Меня, как обычно, опередили.
Ну что ж. Спасибо за ссылку. Буду хоть знать, что название GLM уже забито. :-)
Либа неплохая, конечно, но сырая, как...
Очень много лишнего, туча недочётов, ошибок и т.д. Конструкторы с одним параметром не объявлены как explicit, выполняется ненужная инициализация объектов (этого ведь нет в GLSL), а вдруг у меня миллион вершин и я их гружу с диска, каждый раз весь массив при создании будет инициализироваться напрасно. Неправильно выполняется инициализация матриц. Нет операции умножения вектора на матрицу (есть только матрица на вектор). Текстурные координаты перепутаны местами: q-координата текстуры стоит на 3-м месте, хотя должна на 4-м (и в vec3, и в vec4). Нет swizzling'а. Операции инкремента, декремента и логическое покомпонентное отрицание не определены для bool-векторов согласно спецификации, а в этой либе есть соотв. операторы. И вообще такое чувство, будто создатель этой либы и 3-х раз не читал спеку по GLSL, хотя сишку знает очень хорошо.
К тому же функциональность не выходит за рамки GLSL, что не есть хорошо.

В общем, всем советую. Ошибки вылавливать месяцами придётся. :-)
Уж про уникальное пространство имён я вообще молчу. Ну ладно, его можно было бы делать, если бы функции не пересекались со стандартной библиотекой, а так написать "using glm;" не получится - хотя бы тот же sin есть в стандартной math.h, а без неё никуда. Так что пиши:

using glm::vec2;
using glm::matrixCompMult;
using glm::greaterThanEqual;
using glm::smoothstep;
......................

all
Ладно.
Вот, что можно добавить к GLSL:
Type1 lerp(Type1,Type1,Type2)
mat inverse(mat)
mat transpose(mat)
float/int sqlen(vec)
vec4 normalizePlane(vec4)
vec4 plane(vec3,vec3,vec3)
vec4 plane(vec3 N,vec3 pointOnPlane)
vec3 planeNormal(vec3,vec3,vec3)

Плоскость задаётся просто 4-хмерным вектором, так что определить находится ли точка спереди плоскости можно так: dot(pl.xyz,point)+pl.w > 0.0. Если point -- 4-хмерный ветор в однородных координатах, то можно так: dot(pl,point) > 0.0 . А если нужно расстояние до плоскости, то в последнем случае dot надо разделить на pl.w (это если нормаль плоскости единичная).

Чтото я не понял про "Вот, что можно добавить к GLSL: Type1 lerp(Type1,Type1,Type2)"... В GLSL есть lerp, я сам юзал...