Войти
ПроектыФорумОцените

Handy Math Library v0.61 beta (2 стр)

Страницы: 1 2 3 Следующая »
#15
0:00, 7 окт. 2005

avost
>если ты говоришь о разных компиляторах то align в aligned_float4 соблюдать через __m128 нехорошо :))
>может как нить через #pragma pack(16)
это тоже учтенно :)

>я про это место:
а что не так там? я же объяснял, msvc натыкается на #pragma once и больше не парсит файл. а те кто не знают об этой директиве, натыкаются на стандартные гварды

#if	defined(_MSC_VER) && defined(MTL_USE_SSE_SPECIALISATIONS)
	#include	<xmmintrin.h>
	#include	"basic_types.h"
#else
	#include	"basic_types_non_sse.h"
#endif

а #pragma pack не катит. так как мне нужно выравнивание, а не padding.


#16
1:59, 7 окт. 2005

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

tav
На VC7.1 не компилируется (этот компилятор уже считается устаревшим..?)

На ICC8.1 в дебаге всё хорошо (видимо, это не показатель :), вылетает в релизе:

bvec3(HMtrue,HMfalse,HMtrue)[2]                 - BUG!!! (line: 68)
bvec3(HMtrue,HMfalse,HMtrue)!=bvec3(HMtrue,HMfalse,HMtrue)- ok
bv3=bvec3(HMtrue,HMtrue,HMfalse)                - ok
bvec2(bvec3(HMfalse,HMtrue,HMfalse))            - ok
vec3(vec3(-2,1,4))                              - ok
vec3(12)                                        - ok
(v3=vec3(3,-1,4))[2]                            - ok
vec3(2,0,-1)!=vec3(2,0,0)                       - ok
v3=vec3(5,8,6)                                  - ok
ldvec3(10,-20,4)+2.0l                           - ok
vec3(10,-20,4)-2.0f                             - ok
dvec3(10,-20,4)*-2.0                            - ok
ivec3(10,-20,4)/2                               - ok
ldvec3(1,-2,3)+ldvec3(-2,1,0)                   - ok
vec3(1,-2,3)- vec3(-2,1,0)                      - ok
dvec3(1,-2,3)* dvec3(-2,1,0)                    - ok
ivec3(1,-2,0)/ ivec3(-2,1,3)                    - ok
ldvec3(10,-20,4)+=2.0l                          - ok
vec3(10,-20,4)-=2.0f                            - ok
dvec3(10,-20,4)*=-2.0                           - ok
ivec3(10,-20,4)/=2                              - ok
ldvec3(1,-2,3)+=ldvec3(-2,1,0)                  - ok
vec3(1,-2,3)-= vec3(-2,1,0)                     - ok
dvec3(1,-2,3)*= dvec3(-2,1,0)                   - ok
ivec3(1,-2,0)/= ivec3(-2,1,3)                   - ok
2.0l+ldvec3(10,-20,4)                           - ok
2.0f- vec3(10,-20,4)                            - ok
-2.0* dvec3(10,-20,4)                           - ok
200/ ivec3(10,-20,4)                            - ok
-dvec3(1,-2,-3)                                 - ok
++ldvec3(1,-2,-3)                               - ok
-- vec3(1,-2,-3)                                - ok
(v3++)==vec3(5,8,6) && v3==vec3(6,9,7)          - ok
(v3--)==vec3(5,8,6) && v3==vec3(4,7,5)          - ok
vec2(vec3(1,2,3))                               - ok
bvec4(bvec4(HMtrue,HMfalse,HMfalse,HMtrue))     - ok
bvec4(HMtrue)                                   - ok
bvec4(HMtrue,HMfalse,HMtrue,HMfalse)[2]         - BUG!!! (line: 109)
bvec4(HMtrue,HMfalse,HMtrue,HMtrue)!=bvec4(HMtrue,HMfalse,HMtrue,HMf
bv4=bvec4(HMtrue,HMtrue,HMfalse,HMfalse)        - ok
bvec2(bvec4(HMfalse,HMtrue,HMfalse,HMtrue))     - ok
bvec3(bvec4(HMfalse,HMtrue,HMfalse,HMtrue))     - ok
vec4(vec4(-2,1,4,3))                            - BUG!!! (line: 115)
vec4(12)                                        - ok
(v4=vec4(3,-1,4,5))[2]                          - BUG!!! (line: 117)
vec4(2,0,-1,-2)!=vec4(0,2,-1,-2)                - ok
v4=vec4(5,8,6,-7)                               - BUG!!! (line: 119)
ldvec4(10,-20,4,8)+2.0l                         - BUG!!! (line: 120)
vec4(10,-20,4,8)-2.0f                           - BUG!!! (line: 121)
dvec4(10,-20,4,8)*-2.0                          - BUG!!! (line: 122)
ivec4(10,-20,4,8)/2                             - BUG!!! (line: 123)
ldvec4(1,-2,3,4)+ldvec4(-2,1,0,-1)              - BUG!!! (line: 124)
vec4(1,-2,3,4)- vec4(-2,1,0,-1)                 - BUG!!! (line: 125)
dvec4(1,-2,3,4)* dvec4(-2,1,0,-1)               - BUG!!! (line: 126)
ivec4(1,-2,0,4)/ ivec4(-2,1,3,-1)
-- в последнем тесте падает по делению на ноль.

#17
13:46, 7 окт. 2005

all
Вообще, хочу сразу сказать, либу я выложил не для того, что бы похвастаться (хотя так может показаться на первый взгляд :-) ). Она вышла под лиценцией LGPL, и я, в принципе, могу рассмотреть любые предложения по её совершенствованию. И теперь эта либа не моя, а уже общая, и в неё запросто могут попасть имена авторов существенных добавлений/изменений.

zerg34
>ИМХО надо писать код так, чтобы юзерам (да и тебе самому) понятнее было. В твоем коде без поллитры не разобраться.
Ну, в код заглядывать было не обязательно :-). Да и сравни код slerp из статьи на gamasutra (ссылка у меня приведена в func.h) и то, во что я его переделал на скорую руку (slerp() в func.h).
А если имеешь в виду реализацию векторов/матриц, то такая туча дефайнов сделана для повышенной ошибкоустойчивости и сверхкраткости кода, и пока такой способ себя оправдывает, хотя... можно было получше задефайнить, но и так уже ошибки искать легче -- проверил один оперетор vector+vector и уже ясно, что остальные (-,*,/) будут работать, хотя в тест-системе всё-равно проверяются все. :-)

CyberZX
>умножение матриц у меня 81 такт занимает :)
it depends.
Во-первых, всё зависит от проца. Код от интел был заточен под P-III, я свой код тоже тестил на P-III и тем же способом измерял, что и интел, причём даже установка ключа /G7 (для P-4) приводила к ухудшению результата. На другом процессоре результат работы моего же кода и на других ключах компилятора будет другой.
А во-вторых, вообще-то это было из области "С++ vs asm". Задача была просто показать, что код под стандарт С++ (ведь он использовал только циклы и мог компилироваться на чём угодно) может работать не хуже, чем asm от профи.

cppguru
>На VC7.1 не компилируется (этот компилятор уже считается устаревшим..?)
Скорее наоборот, это у меня устаревший. Ну я по старинке VC++6 -ым пользуйюсь. А нафиг мне 7-ая студия? Visual Assist есть. Компилю только IC++. Что там так много нового добавилось? А если нет, тогда зачем оно надо? А насчёт мелкомягкого компилятора, то про его глюки на тривиальном коде я уже наслышан (и не только в 7.1, даже в более ранних есть), ещё и поэтому ставить не хочу.

А вообще почему не компилится, что выдаёт-то?

>На ICC8.1 в дебаге всё хорошо (видимо, это не показатель :), вылетает в релизе:
У меня в IC++7.1 абсолютно тоже самое. :-(

Ну ладно, покопался я немного. Ситуация значит такая. Если определить DISABLE_SWIZZLING, то тест-система компилиться не будет, т.к. кое-где используется Plane.xyz, где Plane - 4D-вектор. Если поменять Plane.xyz на vec3(Plane), и определить DISABLE_SWIZZLING, то в релизе IC++ ВСЁ работает нормально, без "багов".
С другой стороны, плясать можно и от другого. Определить DISABLE_VECTORIZATION (после этого ошибок станет меньше) и (!!!) в typedef.h вместо __forceinline константе INLINE назначить просто __inline, тогда тоже всё работает нормально без ошибок.
В последнем случае, можно вместо DISABLE_VECTORIZATION определить SUBVECTORS_SWIZZLING (казалось бы, ну какая тут связь), тогда тоже всё-работает и даже векторизуется, правда компилиться чуть подольше и... нихрена не инлайнится.
В общем, выбирай одно из трёх. В принципе, все три варианта одинаково хреновые, но... ничё больше я придумать не смог, IC++ категорически отказывается воспринимать код с циклами for(int i=0;i<4;i++) в сложных структурах данных.
Ладно, потом наверное заменю эти циклы на интринсики... а так не хотелось.

P.S. Хм. Я уже не знаю, то ли это я туплю, то ли компилятор. Только что скомпилил без #define DISABLE_VECTORIZATION (т.е. с включённой векторизацией). Всё прекрасно работает в релизе, да ещё и векторизуется + свиззлинг (неужели дело было только в __forceinline). Короче, если всё же это я опять туплю и нормально работать не будет, ставь #define DISABLE_VECTORIZATION. Так вроде должно работать... по крайней мере в IC++.

И ещё, скачай "новую" версию. Ссылка та же. Изменился лишь typedef.h, но в IC++ теперь работает в релизе (у меня).

#18
19:08, 8 окт. 2005

tav
>А насчёт мелкомягкого компилятора, то про его глюки на тривиальном коде я уже наслышан (и не только в 7.1, даже в более ранних есть), ещё и поэтому ставить не >хочу.
можно поподробнее о глюках при компиляции тривиального кода через msvc7.1? сейчас этот компилятор считается промышленным стандартом. качество генерируемого им кода не сильно отличается от ICC(так как его тоже разрабатывали инженеры Intel), зато скорость компиляции выше на порядок.
если твоя либа будет работать исключительно на ICC то проку от нее мало. так как вести разработку используя интеловский компилятор сложно

#19
23:32, 8 окт. 2005

tav
Что умеет твоя либа такого чего не умеет к примету моя, его и ... ??
С каой целью она создана??

Я к примету вполне удовлетворен вектором 3-Д, если надо чтото зделать в 2-д занулить одну координату.
Говорить для оптимальной скорости при 2-д совсем не приходиться поскольку для таких игрушек использование векторов происходит на мин-ом уровне.
Зачем эта универсальность? В большинстве случаев это токо оболочка.

Хотя...
Что у тебя есть для определения столкновений?

#20
17:23, 9 окт. 2005

all
В документацию добавлены описания конструкторов и выражения с типами библиотеки (сложение/вычитание/умножение векторов/матриц/кватернионов и т.д.).

CyberZX
>можно поподробнее о глюках при компиляции тривиального кода через msvc7.1?
Ну, к примеру есть совсем уж известная бага (и ты о ней прекрасно знаешь). И между прочим, сам же советовал использовать IC++. Или твоё отношение в нему изменилось?
И вообще, не надо говорить, что таких баг в VC7.1 по пальцам пересчитать, я про это услышал и мне этого достаточно, чтобы в подкорке сделались некие выводы. Человеку вообще свойственно рассуждать субъективно. И мне как-то накласть, что эту багу (я правда не уверен) MS давно уже исправило, а в IC++ тоже наверняка не всё без ошибок и т.д. и т.п. MS облажалась, так? Первое впечатление осталось? Ну и всё, и выбор "VC7.1 vs IC++7.1" я делаю в пользу известно какого компилятора.
>если твоя либа будет работать исключительно на ICC то проку от нее мало.
Ну так пусть хоть кто-нибудь объяснит мне русским языком, почему на VC7 либа не компилится!
>так как вести разработку используя интеловский компилятор сложно
Почему?

Breezy
>С каой целью она создана??
Упростить жизнь разработчиков. Повысить надёжность их кода (ведь если либа "принуждает" писать понятный и краткий код, ошибок будет меньше).
Я тоже пользовался своей прошлой либой, пока не понял, что это что-то... не то.
>Что умеет твоя либа такого чего не умеет к примету моя, его и ... ??
Ну, привожу на вскидку список функций (или их аналогов), которых наверняка у тебя нет:
wrap(x,minVal,maxVal)
reflect(V,Plane)
crossMat(n)
<все функции сравнения (isZero, lessThan, notEqual, any и т.д.)>
noise#
translatePlane(Plane,V)
reflectPlane(Plane,PlaneR)
lookAtMat(eye,center)
lookAtDirnMat(eye,dirn)
lookAtDirnMat(dirn)
rotate(angle,axis,vec)
projectionMat(Plane)
squad(p,a,b,q,t)

К тому же в либе есть документация. А ты знаешь много мат. либ. с полной документацией? У той же GMTL её читать довольно проблематично особенно касательно операций над типами данных, и дело не в языковом барьере, а в том, что в gmtlProgrammersGuide-0.0.5.pdf к примеру написано довольно мало, а в gmtlReferenceGuide-0.0.5.pdf просто перечисление всех функций, конструкторов и операторов. От перечисления функций, конечно никуда не деться, но вот конструкторы и операторы ИМХО у меня лучше описаны (по крайней мере в английской версии :-) ). А ведь главных барьеров при использовании чужих либ по сути два: документация (никто ведь не хочет копаться в чужом некомментированном коде) и надёжность, а точнее её отсутсвие. Вот сниму второй барьер, тогда может дело пойдёт. :-)

>Что у тебя есть для определения столкновений?
Это слишком специфичная задача чтобы выносить её в общую либу.

#21
18:14, 9 окт. 2005

tav
>А ты знаешь много мат. либ. с полной документацией?
Весомый аргумент :). Не знаю даже, но, допустим, я никогда не встречался с проблемой непонимания исходного кода математической библиотеки при отстутствии документаций. Хватало нескольких коментариев.

>писать понятный и краткий код
Увидел код и ужаснулся. Пролистал код Tmat2 и ужаснулся дважды :). С такими дефайнами я ещё не встречался.

#22
20:30, 9 окт. 2005

tav
>И вообще, не надо говорить, что таких баг в VC7.1 по пальцам пересчитать, я про это услышал и мне этого достаточно, чтобы в подкорке сделались некие выводы
я исхожу из практических соображений. я очень плотно работаю с MSVC7.1 и могу сказать тебе точно таких багов действительно можно посчитать по пальцам лично я на практике с ними вообще не встречался. а вот с багами и глюками ICC7.1 приходилось частенько встречатся. особенно задолбал это zombie state :E
msvc7.1 это современный компилятор, который является промышленным стандартом в разработке программ на С++. поэтому если пишешь либу, то надо в первую очередь сделать так, что бы она работала на этом компиляторе. если придется отказатся от каких-то крутых фич ICC, то юзай условное компилирование, благо у С++ очень богатые возможности в этом плане.
а про подкорку ты зря. программист должен оценивать инструментарий объективно. и знать какие плюсы и минусы ждут его при работе с тем или иным инструментом, а не полагаться на эмоции, основаных от первых впечателний. это не профессионально.

#23
12:29, 10 окт. 2005

tav
Советую не спорить с людьми (все равно это бесполезно), а доводить до ума свою библиотеку. Избавишься от глюков, проверишь все алгоритмы, протестируешь и все будет ок. Люди будут юзать.

#24
12:59, 12 окт. 2005

all
Ну, что сказать. Качайте новую версию. Исправил аж две строчки кода.

CyberZX
М-да...
Потратил тучу времени, поставил VS .NET.
В VC++7.0 всё прекрасно компилится и работает, но вот от VC++7.1 я такого не ожидал. Они там что, с ума посходили в MS. Такое чувство, будто весь код компилятора с нуля переписали. Никакой обратной совместимости. Вот в VC++7.0 -- правильный компилятор, даже warning-ов столько же по сравнению с VC++6 -- и там и там 18 (в 7.1 - 3 штуки), а вот 7.1.... отличается от 7.0 гораздо больше, чем 7.0 от 6.0, даже стандартные хидеры переписаны, ибо предыдущие их версии на 7.1 просто не компилятся...

Кстати о той баге "при компиляции тривиального кода". Она есть и в 7.0, и в 7.1. Странно, неужели в 7.0 её ещё не обнаружили, что и за год MS её так и не исправила...
>а вот с багами и глюками ICC7.1 приходилось частенько встречатся.
Можно поподробнее о глюках компиляции кода IC++. Чтобы он что-то компилировал и это работало бы неправильно.

zerg34
>Избавишься от глюков,
Какие глюки? О чём ты? :-)

cppguru
>На VC7.1 не компилируется (этот компилятор уже считается устаревшим..?)
Ага, можешь его считать устаревшим. :-)
Такой простой хак (даже в 7.0 всё работает), а 7.1 уже так постарел, что забыл как надо ето компилить. :-)

#25
16:56, 20 окт. 2005

all
Новая версия. Качать, as always, по ссылке из 0-го поста.
Переизобрёл кватернионы. Ох, не представляю как до них Гамильтон вообще додумался, особенно с этим половинным углом, ну да ладно.
А уж код для работы с ними из nebuladevice вообще стоит отдельного упоминания. Кто его писал интересно, ну просто какие-то монстры в математике. Я доолго тупил, пытаясь доказать почему же (ахтунг!) прибавление длины кватерниона к его компоненте w уменьшает угол его поворота ровно в два раза. Но, тем не менее во всем разобрался. Сначала даже сам написал свою реализацию, но потом как начал сравнивать с тем, что было в nebuladevice... короче, посмотрел, а потом заново переписал и в принципе в некоторых местах (напр. в shortestArcUnitQuat) получилось вроде даже лучше, чем в небуле.
И ещё. Доработал тест-систему. Теперь вектора/матрицы/кватернионы тестируются практически полностью, остаются только функции.
Ну и проверил на 5 компиляторах (см. 0-й пост).

#26
15:41, 27 окт. 2005

all
Не понимаю, почему все так равнодушно к этому относятся. Как будто есть лучшие альтернативы. Тогда чем "лучшие"? И почему я о них ничего до сих пор не знаю? :-)

Я эту либу, между прочим, не просто так стал делать. Я действительно искал удобный, переносимый, надёжный вариант. Но таковых не нашёл. Всегда что-то... не нравилось в архитектуре других либ. Ведь мат. либа - это не просто набор поддерживаемых функций и классов с перегруженными операторами. Важна ещё и их организация.
Архитектура HandyML основана на GLSL. И таким образом, основу HandyML составляют:
1. Жесткий контроль приведения типов. Запрещены все неявные преобразования типов. Все преобразования должны быть заданы явно через конструкторы.
Таким образом, нельзя писать vec4 v=0; А нужно так: vec4 v=vec4(0); Так же не происходит автоматических преобразований в функциях и операторах, что исключает неоднозначности, ведь "mat4 m2=5+m;" не равносильно "mat4 m2=mat(5)+m;".
2. Унифицированность арифметических операторов. Большинство операторов работают покомпонентно, за небольшим исключением, что упрощает их запоминание и наглядность кода. В частности, все бинарные операторы с одинаковыми операндами дают результат, имеющий тот же тип, что и операнды, без исключения.
3. Отсутствие функций-членов в классах-типах библиотеки (за исключением методов доступа к множеству компонентов, напр. xyz()). ИМХО, free-функции (вроде length()) улучшают восприятие кода.
4. Результат своей работы функции всегда выдают в виде возвращаемого значения (void-функций в либе вообще нет). Это даёт более гибкий механизм для работы с функциями. Напр. функции интерполяции (lerp, slerp или squad). Простая задача - найти интерполированное значение цвета для точки (x,y) внутри квадрата с цветами в его вершинах (a,b,c,d). В HandyML это делается просто: lerp(lerp(a,b,y),lerp(d,c,y),x). А теперь реализуйте её в GMTL например, где lerp принимает 4 аргумента: lerp(result,t,from,to). Удобно?

И ещё. По поводу пункта 2. Простой пример - расчёт освещения вершины/пикселя (напр. для текселя лайтмепа или пикселя
при рейтрейсинге) с использованием HandyML:

vec4 resultColor=mtlEmission+mtlAmbient*lightModelAmbient;
for each light do:
{
    vec4 lightDirn=normalize(lightPos-pixelPos),
         eyeDirn=normalize(eyePos-pixelPos);
    float D=max(dot(normalize(eyeDirn+lightDirn),pixelNormal),0);
    float lightDist=distance(pixelPos,eyePos);

    resultColor+=(mtlAmbient*lightAmbient
                +mtlDiffuse*lightDiffuse*max(dot(lightDirn,pixelNormal),0)
                +mtlSpecular*lightSpecular*(D/(mtlShininess-mtlShininess*D+D)))
                /(lightConstAtten+lightDist*lightLinearAtten+lightDist*lightDist*lightQuadAtten);
}
resultColor=min(textureColor*resultColor,1);
Тут, в принципе принят ряд упрощений, в частности используется альтернативный коэффициент зеркального отражения, предложенный Блинном, а также аппроксимируется возведение в степень по методу Шлика.
Более "точно" значение коэфициента зерк. отражения можно считать так: pow(max(dot(-reflect(lightDirn,pixelNormal),eyeDirn),0),mtlShininess)

Кстати, о других либа. Вот взять D3DX в частности. Я, конечно понимаю, что это не только мат. либа, там много другой функциональности. Но если не ошибаюсь там нельзя использовать оператор умножения для вектора и матрицы и для двух векторов. А уж всякие D3DXVec3LengthSq. Это же элементарно не удобно. Однако ей очень многие пользуются - я постоянно вижу на форуме примеры с использованием D3DX для математики. Но ведь такой код сильно "расползается" и становится очень трудно с первого взгляда его понять. Названия в верхнем регистре, да еще и без разделения слов (вроде D3DXQUATERNION) очень плохо зрительно воспринимаются. Вообще в D3DX очень много дизайнерских и архитектурных просчётов, а дизайн библиотеки (особенно математической) играет большую роль. Время больших ЭВМ давно прошло и сейчас компиляторы могут то, на что раньше и на ассемблере старались не тратить время. Отладка кода занимает около 90% времени, а его написание и разработка всего лишь 10%. Я лишь предлагаю улучшить этот коэффициент. Зачем тратить впустую время на поиск опечаток и ошибок в громоздком и ненаглядном коде?
И к тому же, если нужно напр. в g_pd3dDevice->SetTransform передать мировую матрицу, что мешает делать так: "mat4 matWorld; g_pd3dDevice->SetTransform( D3DTS_WORLD, (D3DMATRIX*)&matWorld );" А можно вообще в класс матрицы из HandyML добавить оператор приведения к типу D3DMATRIX* и писать ещё проще.

#27
15:41, 27 окт. 2005

CyberZX
>msvc7.1 это современный компилятор, который является промышленным стандартом в разработке программ на С++. поэтому если пишешь либу, то надо в первую очередь сделать так, что бы она работала на этом компиляторе.
Посмотрим, что будет с выходом скажем VC++9.0. Тогда уж сразу говори не о 7.1. а о "последней" (или "наиболее распространённой") версии компилятора, а то насчёт "промышленного стандарта" я сильно сомневаюсь, и особенно насчёт совместимости старого кода на новых компиляторах от MS.

>качество генерируемого им кода не сильно отличается от ICC(так как его тоже разрабатывали инженеры Intel), зато скорость компиляции выше на порядок.
Кстати нифига. Замерил время компиляции тест-системы (через Build Timing -> Yes). И для 6-ой вижалки через опцию "/y3".
Вот 6-я вижалка компилирует код как раз на порядок быстрее VC++7.1. VC++7.0 компилирует немного быстрее VC++7.1, а вот IC++7.1 компилит даже быстрее VC++7.0, и фору VC++7.1 может дать довольно существенную и это притом (!!!), что IC++ векторизовал тучу кода с 4D-векторами и матрцами. В логе билда просто куча сообщений LOOP WAS VECTORIZED.
>так как его тоже разрабатывали инженеры Intel
Видимо Intel их уволила, а MS подобрала подешёвке.
Шутки шутками, конечно, но в разработке харда такие люди сидят, что нам софтовикам до них, как до Луны пешком, и если обнаружится ошибочка в стомиллионно-транзисторном кристалле, там не то что голову, а яйца оторвут со всеми потрохами кому надо и кому не надо. А MS такой, извиняюсь, "ширпотрёб" выпускает, как будто на распродажу, а средств у них уж поболе чем у Intel. Вот что значит монополия, совсем распустились.

#28
18:07, 27 окт. 2005

tav
Если тебя интерисует вот список ф-й которые я использую для векторов

class VECTOR3D
{
public:
	float x;
	float y;
	float z;

	void Set(float newx,float newy,float newz);//47

	void Add(float ax,float ay,float az);
	void Add(VECTOR3D *pAddVector);//78
	void Add(VECTOR3D AddVector);//78
	void Add(VECTOR3D *pVector1,VECTOR3D *pVector2);//100
	void Add(VECTOR3D Vector1,VECTOR3D Vector2);//100
	void Sub(float sx,float sy,float sz);
	void Sub(VECTOR3D *pSubVector);
	void Sub(VECTOR3D SubVector);
	void Sub(VECTOR3D *pVector1,VECTOR3D *pVector2);
	void Sub(VECTOR3D Vector1,VECTOR3D Vector2);
	void Mul(float k);//78
	float Mul(VECTOR3D *pMulVector);//62
	float Mul(VECTOR3D MulVector);//70
	void Cross(VECTOR3D *pVector1,VECTOR3D *pVector2);//векторное умножение[110]
	void Cross(VECTOR3D Vector1,VECTOR3D Vector2);//векторное умножение[125]
	void Div(float k);//делить данный вектор на k[95]
	void Invert(void);

	void Projection(VECTOR3D *pNVector,VECTOR3D *pPVector);//проекция PVector на NVector
	void Projection(VECTOR3D NVector,VECTOR3D PVector);//проекция PVector на NVector

	float Mod(void);//модуль вектора[200]
	void Unit(void);//преобразовать в единичный вектор[220]
	//угол между данным вектором и указаным
	float Angle(VECTOR3D *pVector);//угол между данным и указаным вектором[300]
	float Angle(VECTOR3D Vector);//угол между данным и указаным вектором[280]
	//разложение vec в базисе bvecx,bvecy,bvecz возврашает дескриминант
	float FactorBasis(VECTOR3D *bvecx,VECTOR3D *bvecy,VECTOR3D *bvecz,VECTOR3D *vec);//определение vec в базисе bvecx,bvecy,bvecz [700]
	float FactorBasis(VECTOR3D bvecx,VECTOR3D bvecy,VECTOR3D bvecz,VECTOR3D vec);//определение vec в базисе bvecx,bvecy,bvecz [675]
	//пересечение линии и плоскости
	bool CrossLinePlane( LINE3D *line,PLANE3D *plane);//точка пересечения линии и плоскости[300]
	bool CrossLinePlane( LINE3D line,PLANE3D plane);//точка пересечения линии и плоскости[406]
	//проверка находиться ли точка внутри или вне треугольника(вызывать после CrossLinePlane)
	bool InOutTriangl(VECTOR3D *TPoint1,VECTOR3D *TPoint2,VECTOR3D *TPoint3,VECTOR3D *TNormal);//1000
	bool InOutTriangl(VECTOR3D TPoint1,VECTOR3D TPoint2,VECTOR3D TPoint3,VECTOR3D TNormal);//1000
	bool InOutTriangl(VECTOR3D *TPoints,VECTOR3D *TNormal);//
	//поворот вектора
	void Rotate(VECTOR3D *RVector,float angle);//поворот данного вектора относительно другого[2250]
	void Rotate(VECTOR3D RVector,float angle);//поворот данного вектора относительно другого[2250]

	bool CrossSegmentTriangl(VECTOR3D *SPoint1,VECTOR3D *SPoint2,VECTOR3D *TPoint1,VECTOR3D *TPoint2,VECTOR3D *TPoint3);//тест пересечения отрезка и треугольника[1250]
	bool CrossSegmentTriangl(VECTOR3D SPoint1,VECTOR3D SPoint2,VECTOR3D TPoint1,VECTOR3D TPoint2,VECTOR3D TPoint3);//тест пересечения отрезка и треугольника[1325]

	void Mul(MATRIX4x4 *m,VECTOR3D vec);//220
	void Mul(MATRIX4x4 *m,float mx, float my,float mz);//
};
#29
12:42, 28 окт. 2005

Breezy
Перенеси, please, длинные строки в своём коде на несколько строк, а то всё форматирование съехало -- страница расширилась.

Вообще конечно, у тебя удобством как-то не пахнет. Почему решил без операторов делать? ИМХО, очень не удобно.


all
Сделал новый класс Taabb, а по сути даже два новых типа: aabb и rect. Никто не смотрел ещё в новой версии либы? Ну как вам дизайн?
Только вот не знаю что делать с типами aabb, а то "ldaabb" выглядит как-то странно.

Страницы: 1 2 3 Следующая »
ПроектыФорумОцените

Тема в архиве.