Чт, 17 Янв 2019
Механоиды 3
Приветствую Вас Гость | RSS
Главная страница | Регистрация | Вход
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
  • Страница 2 из 3
  • «
  • 1
  • 2
  • 3
  • »
Форум "Механоиды 3" » Рабочий раздел. » Графика » Графика: 3D модели и OpenGL (свой движок)
Графика: 3D модели и OpenGL (свой движок)
smt005Дата: Ср, 24 Июн 2009, 01:50 | Сообщение # 41
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Ну, если интересно, можете видео посмотреть.

Как наверно заметилт, все объекты кроме самой локации из М2, на горизонте даже вышки есть! wink
Причём для группы деревьев и камней используются одна и таже модель.

Почему мало кто проверял работоспособность проги которую я выкладывал, которая в конце предыдущей страници ?! angry

Или мало кому интересно ?

Прикрепления: v2.avi(487.5 Kb) · v3.avi(507.9 Kb)
 
PA3UJIbДата: Ср, 24 Июн 2009, 03:25 | Сообщение # 42
1 Поколение
Группа: Основной состав
Сообщений: 105
Замечания: 0%
Статус: Offline
Да, треугольнички эти работают.
Может дашь исходники. вместе глянем в чем трабла?
 
МиксДата: Ср, 24 Июн 2009, 06:33 | Сообщение # 43
1 Поколение
Группа: Основной состав
Сообщений: 80
Замечания: 0%
Статус: Offline
Глайдер и камера тормозят. Кстати, в первой демке тоже такое было, но я подумал, что это нормально. Увеличение скорости в конфиге помогает. Но камера летает как-то далеко. Ставлю расстояние камеры 10 - камера смотрит на крышу глайдера. Скрины прилагаются. Мой конфиг:
0.1 float ini_Speed;
0.01 float RotateSpeedGlader;
3 float HeightGlader;
20 float DistCamera;
0.001 float RotateSpeedCamera_f;
0.001 float RotateSpeedCamera_q;
Прикрепления: 4903883.jpg(81.3 Kb) · 3921512.jpg(100.1 Kb) · 5660113.jpg(60.6 Kb)


 
smt005Дата: Ср, 24 Июн 2009, 11:44 | Сообщение # 44
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (Микс)
Ставлю расстояние камеры 10 - камера смотрит на крышу глайдера.

Так и должно быть, сделаю возможность настраивать. Камера смотрит на глайдел по направлению + сдвиг вверх.
 
smt005Дата: Ср, 24 Июн 2009, 11:58 | Сообщение # 45
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (PA3UJIb)
Может дашь исходники. вместе глянем в чем трабла?

Такие строки, это самопальный СейвЛОГ, как делается настоящий не знаю.
if ( NoOffLog > 0 ) SaveLoag("Render.h RenderScene(Start Load) Proces", (GLfloat)Proces);

Добавлено (24 Июн 2009, 11:58)
---------------------------------------------
В каментариях ошибок много, поэтому распрашивай.

Прикрепления: Kop_Fysix.part0.rar(1024.0 Kb) · Kop_Fysix.part0.rar(1024.0 Kb) · Kop_Fysix.part0.rar(1007.4 Kb)
 
PA3UJIbДата: Ср, 24 Июн 2009, 17:21 | Сообщение # 46
1 Поколение
Группа: Основной состав
Сообщений: 105
Замечания: 0%
Статус: Offline
3 файла с одним и тем же именем?
 
smt005Дата: Ср, 24 Июн 2009, 18:17 | Сообщение # 47
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
На форум нельзя загружать файлы больше 1 мегабайта, я разделид их на три части.
При загрузке они переименовались.
Переименуй их:
Kop_Fysix.part01.rar
Kop_Fysix.part02.rar
Kop_Fysix.part03.rar
 
PA3UJIbДата: Ср, 24 Июн 2009, 18:49 | Сообщение # 48
1 Поколение
Группа: Основной состав
Сообщений: 105
Замечания: 0%
Статус: Offline
У меня только один качается всегда, который 1008 Кб размером.

Добавлено (24 Июн 2009, 18:49)
---------------------------------------------
Еще и скорость 3Кб/с всего...

 
smt005Дата: Ср, 24 Июн 2009, 19:43 | Сообщение # 49
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Лана, пока забей, я сейчас перейду на заготовку инициализации проги NeHe. Это то что у тебя заработало.
Quote (PA3UJIb)
Да, треугольнички эти работают.

Добавлено (24 Июн 2009, 19:42)
---------------------------------------------

Quote (smt005)
Еще и скорость 3Кб/с всего...

как я тебя понимаю....

Добавлено (24 Июн 2009, 19:43)
---------------------------------------------

Quote (PA3UJIb)
У меня только один качается всегда, который 1008 Кб размером.

Ага, у меня тоже - глюки форума.
 
KrogothДата: Ср, 24 Июн 2009, 20:48 | Сообщение # 50
5 Поколение
Группа: Основной состав
Сообщений: 553
Замечания: 0%
Статус: Offline
Залей на файл-хостинг какой-нить.
 
Frozen_LightДата: Чт, 25 Июн 2009, 00:07 | Сообщение # 51
4 Поколение
Группа: Доверенные
Сообщений: 194
Замечания: 0%
Статус: Offline
Quote (PA3UJIb)
У меня только один качается всегда, который 1008 Кб размером.

Потому что сохранился на форуме только один файл.
Quote (PA3UJIb)
Еще и скорость 3Кб/с всего...

Некие глюки укоза. Браузер качает отвратительно, даунлоад-мастер - с сильными скачками в скорости.


Я полон оптимизма. Человечество преодолело законы морали, почему бы ему не преодолеть законы физики?
 
МиксДата: Чт, 25 Июн 2009, 09:39 | Сообщение # 52
1 Поколение
Группа: Основной состав
Сообщений: 80
Замечания: 0%
Статус: Offline
Я даунлоад-мастером качаю. Как только скорость падает (а это почти мгновенно), я жму паузу и снова запускаю закачку. Помогает. smile

 
smt005Дата: Пн, 06 Июл 2009, 02:10 | Сообщение # 53
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Вот, только код, если интересно копаться в чужом коде.

Сейчас я перехожу на другую основу (инициализация).

Добавлено (06 Июл 2009, 02:10)
---------------------------------------------
happy
Получилось написать прогу которая использует шейдеры. Осталось только изучить сами шейдеры.

Frozen_Light, как с помошью щейдеров смешивать текстуры?

з.ы.: ты GLSL используеш ?

Прикрепления: KopEnginev.1.rar(18.6 Kb)
 
Ize_g0reДата: Пн, 06 Июл 2009, 15:23 | Сообщение # 54
1 Поколение
Группа: Доверенные
Сообщений: 35
Замечания: 0%
Статус: Offline
smt, есть неплохой урок по шейдерам, вот:
Прикрепления: step1.pdf(766.4 Kb)



Deep inside... With stones in hand...
From the mind... ...he plays light's end
 
МиксДата: Пн, 06 Июл 2009, 15:34 | Сообщение # 55
1 Поколение
Группа: Основной состав
Сообщений: 80
Замечания: 0%
Статус: Offline
Очень интересно smile А Xors3D только для C++? Или C# тоже (не спрашиваю уж про бэйсик)?

 
smt005Дата: Пн, 06 Июл 2009, 15:44 | Сообщение # 56
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Спасибо конечно, но я использую OpenGL и мне надо использовать GLSL а не HLSL.
 
PA3UJIbДата: Пн, 06 Июл 2009, 15:57 | Сообщение # 57
1 Поколение
Группа: Основной состав
Сообщений: 105
Замечания: 0%
Статус: Offline
немного иная система передачи параметров, несколько других функций и можно перевести из HLSL в GLSL.
 
Ize_g0reДата: Пн, 06 Июл 2009, 16:30 | Сообщение # 58
1 Поколение
Группа: Доверенные
Сообщений: 35
Замечания: 0%
Статус: Offline
... что еще раз выявило отсутсвие понимания предмета у smt ...
//негодует
Микс, угу, только для плюсов...



Deep inside... With stones in hand...
From the mind... ...he plays light's end
 
smt005Дата: Пн, 06 Июл 2009, 17:34 | Сообщение # 59
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Сами шейдеры ещё пока даже не изучал.
 
Frozen_LightДата: Пн, 06 Июл 2009, 17:58 | Сообщение # 60
4 Поколение
Группа: Доверенные
Сообщений: 194
Замечания: 0%
Статус: Offline
Quote (smt005)
Frozen_Light, как с помошью щейдеров смешивать текстуры?

Я? О_о
Я этим не занимаюсь вообще))))


Я полон оптимизма. Человечество преодолело законы морали, почему бы ему не преодолеть законы физики?
 
smt005Дата: Пн, 06 Июл 2009, 18:22 | Сообщение # 61
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (Frozen_Light)
Я? О_о

Упс, извини, я тебя с Ize_g0re перепутал. wacko biggrin
 
Ize_g0reДата: Пн, 06 Июл 2009, 20:25 | Сообщение # 62
1 Поколение
Группа: Доверенные
Сообщений: 35
Замечания: 0%
Статус: Offline
Ну, у меня по альфе в шейдере смешивается, сиди и кури, переводи в алгоритм... Урок что я кинул очень здорово мозги по шейдерам вправляет...


Deep inside... With stones in hand...
From the mind... ...he plays light's end
 
YandersenДата: Вс, 12 Июл 2009, 05:33 | Сообщение # 63
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
Quote (smt005)
А что ты можеш сказать про физику? Пиши всё что знаеш?
Чессгря, я имел в виду не физику-физику, а игровое моделирование физики - ну, там, столкновения, вектора падающий-отражённый, пересечение линий и плоскостей (треугольников), генерация нормалей туда-же, проекции всякие и т.п. - т.е. геометрия, векторная алгебра - то, что в игродельи требуется для деланья "физики".
Quote (smt005)
Quote (Думаю сделать ПРИМЕРНО так:)
...

Такие мысли у меня: "свой" формат нужен для того, чтоб было удобно и быстро грузить модель в память; в "своём" формате есть только те данные, которые нужны "твоему" двиглу для рисовки модели, и в наиболее удобном для чтения виде. Т.е. структура файла должна быть максимально приближена к структуре в памяти, куда данные о модели будут скопированы из файла. Учти, прочитать метровый файл разом во много-много раз быстрее, чем по кусочкам, по несколько байт, циклом. Это было АБВГД. Моё ИМХО ещё такое: файл модели должен содержать в себе ВСЁ, т.е. быть независимым. Т.е. я считаю, картинки текстур и описания материалов также нуна пихать в тот же файл, что и геометрию модели. Иногда это может быть не так экономично, как использование одной текстуры несколькими моделями, но зато избавит тебя от возможности словить багов. Вообще, ИМХО, такие ситуации редки - в большинстве случаев каждая модель юзает свой индивидуальный скин, а современное железо уже достаточно вместительно, чтобы плюнуть на такие мелочи, как несколько дубляжных картинок в редких случаях.
Дальше. Массивы вершин. С одной стороны, иногда удобно в плане наглядности разделить эти массивы по типам (отдельно массив нормалей, отдельно массив цветов, отдельно вершин...), но... Как я уже говорил, прочитать 1 мег целиком быстрее, чем 5 раз по 200к. Это раз. Во-вторых, если паковать все данные в один interleaved массив, работать будет быстрее. И три - универсальность. ИМХО, все модели должны содержать одинаковые типы массивов, которыми рисуются. Или ты собираешься каждый раз при рисовке очередной модели проверять, какие данные она содержит, и, соответственно, енаблать или дизаблать те или иные типы массивов? А затем ещё и каждый из них описывать? Я предлагаю остановиться на смешанных массивах. Если аттрибуты вершин запаковать в класс (структуру), это физически НИЧЕГО не изменит (в плане быстродействия - в памяти это те же стиснутые вместе флоаты), но в своём коде ты сможешь легко обращаться к отдельным аттрибутам вершины не менее удобно, чем если бы они были в разных массивах, а не в меше. Не бойся страшных классов - они не тормозят (я, помню, сначала интуитивно пытался избегать классов, думал, они тормозить должны biggrin ).
Я думаю так. Нуна сперва определиться с тем, какие данные модели мы собираемся юзать (в наиболее общем варианте, чем ты обычно пользуешься?). Без координат вершин мы нифика не нарисуем ваще; без нормалей тоже никуды; текстурами в наши дни кроют всё, так что массив координат текстуры в 99.9% нужон. А вот цвет... Как считаешь, юзает ли кто-то интерполяцию так сильно, чтобы отвести лишних 4х4=16 байт/вершину под цвет? ИМХО, массив цветов ни к чему уже. Итого, я голосую за смешанный массив, содержащий
координаты текстуры,
координаты нормали,
координаты вершин.
Всё, ИМХО. Материал отдельно, для всех вершин модели общий. Тут согласен пока?
Теперь насчёт количества координат. Насчёт текстуры - я не уверен. Мне-то двух всегда хватало, но как насчёт мультитекстурирования...
Зато, думаю, спорить насчёт 3-х координат нормали и вершины, ты не бушь, верно?
Выходит тип смешанного массива примерно такой:
GL_T?F_N3F_V3F.
Заглянем в мануал (или сюда) - какие наиболее подходящие типы там разрешены?
GL_T2F_N3F_V3F - наиболее подходящий, ИМХО.
Однако, возможно, всё же необходимо 3 координаты текстуры иметь в массиве? Если так, то массивы придётся указывать отдельно, бо нет такого типа смешанного массива, который 3 координаты текстуры имеет. Но нужно ли это в реале?..
Предлагаю помозговать. А пока добуду-ка я свои свеженькие версии хеадеров с описаниями класса материала и текстуры, чтоб тебе код облегчить... wink


[Беженец со Скаев]

Сообщение отредактировал Yandersen - Вс, 12 Июл 2009, 05:38
 
YandersenДата: Вс, 12 Июл 2009, 07:43 | Сообщение # 64
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
Вона хеадер с классом материала. Класс содержит все параметры материала - цвета ambient, diffuse, specular, emission, shininess-параметр, а также простенькие функции (с синтаксисом, близким к глевскому) по вводу этих параметров. Есть функции по передачи всех параметров материала, а также записи/чтения всей структуры в/из файл(а). Ничего сложного, в общем. Универсальненько так.
Вот насчёт функций чтения-записи поподробнее щас расскажу. Я такой подход практикую: я рассматриваю файл как набор последовательно идущих кусков (chunk'ов), каждый из которых содержит свой тип данных и относительно независим - читается-пишется своей функциовиной. Вот к примеру, в TMaterial моём есть функции LoadFromChunk и SaveToChunk для загрузки (чтения) / записи из /в файл(а) данных материала. Т.е. когда ты доходишь до области файла, где - ты знаешь - начинаются данные о материале, ты просто запускаешь "MyMaterial.LoadFromChunk(CurrentlyOpenedFile);" и не паришься - функция знает, как грузить данные - она начитается из файла, заполнив MyMaterial данными, и сместит позицию чтения-записи на начало следующей области. Вручную делать ничего не надо - просто знай, в каком порядке ты записывал chunk'и, и в том же их грузи. Такой вот подход я практикую. Немного наглядней полезность этого метода видна при загрузке картинки - размер картинки в файле может быть разным, поэтому, чтобы не париццо, разбирая формат файла, пишешь функциовину, которая знает своё дело. Я щас дополирую хеадер Textures.h и его тоже выложу.
Прикрепления: Materials.h(11.7 Kb)


[Беженец со Скаев]
 
YandersenДата: Вс, 12 Июл 2009, 18:41 | Сообщение # 65
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
А вот и он - см. в прикреплении.
Я выбрал как стандарт хранения пикселов в TEX-картинке - RGBA, 4байта/пиксел. BMPшки - это 24-битные BGR картинки, с 54 байтами требухи в начале и дурацким равнением рядов под 4-байтную кратность, отчего грузить их - сплошное удовольствие, а ещё если учесть кривую поддержку A-канала, который, ИМХО, для текстуры очень важен... В общем, я решил "свой" формат для файла с текстурой применять - *.TEX. Там 4 байта первых - это unsigned int, ширина (размер по горизонтали) картинки в пикселах, затем идут 4 байта unsigned int - высота картинки (размер по вертикали) в пикселах, ну и потом, ряд за рядом, строки пикселов картинки, каждый пиксел - 4 байта (RGBA). Ничего проще быть не может.
Ну, в общем, в хеадере описаны функции по загрузке картнки из *.BMP и *.TEX, а также функции по переконвертированию форматов, записи/чтению так что парится не нуна.

Добавлено (12 Июл 2009, 18:41)
---------------------------------------------

Quote (Yandersen)
Я такой подход практикую: я рассматриваю файл как набор последовательно идущих кусков (chunk'ов), каждый из которых содержит свой тип данных и относительно независим - читается-пишется своей функциовиной.
Смотри, как оно работает:
допустим, ты создаёшь файл модели. Решил назвать его "MyModel.mdl". И решил устроить его так: сначала в нём должна идти картинка текстуры, за ней описание материала, и потом геометрия. Картинка, которую ты хочешь юзать для текстуры, пусть будет "Skin.bmp". Выдрать картинку из bmpэшки и всунуть в твой файл тебе поможет класс TTexture. Вот как это всё делается:

TMaterial Mat; //Создаём класс, хранящий настройки материала (по-умолчанию будет содержат все OpenGLевские дефолтные значения)
//Конфигурим параметры материала
Mat.SetAmbient3f( 0.8, 0.5, 0.1 ); //Цвет материала в тени
Mat.SetDiffuse3f( 0.6, 0.3, 0.1 ); //Цвет освещённого материала
Mat.SetSpecular3f( 0.2, 0.2, 0.2 ); //Цвет бликов
Mat.SetShininessi( 5 ); //Сфокусированность бликов
TTexture Tex; //Создаём класс текстуры; его волшебные возможности нам скоро понадобятся :)
//Создаём пустой файл модели
FILE* ModelFileHandler = fopen("MyModel.mdl","wb");
//Итак, сперва в файле модели мы решили сохранить картинку текстуры, которая торчит щас в файле "Skin.bmp"
Tex.BMPtoChunk("Skin.bmp", ModelFileHandler); //Выдираем картинку из BMPэшки и пихаем в наш файл
//За картинкой, мы условились, должно идти описание материала модели
Mat.SaveToChunk(ModelFileHandler); //Пишем все параметры в файл
... //Тут сам пиши код, как геометрию буш сохранять
fclose(ModelFileHandler); //Не забудь закрыть файл, когда всё в него записал!

И обратно - когда будешь загружать этот файл, в том же порядке модель и грузи:

//Открываем файл модели
FILE* ModelFileHandler = fopen("MyModel.mdl","rb");
//Первой в файле модели идёт картинка текстуры - грузим её оттуда своей функциовиной
Tex.LoadFromChunk(ModelFileHandler); //Картинка будет загружена в видюху и зарегена в OpenGL
//За картинкой, мы знаем, идёт описание материала модели
Mat.LoadFromChunk(ModelFileHandler); //Грузим параметры материала из файла
... //Тут сам пиши код, как геометрию буш грузить
fclose(ModelFileHandler); //Не забудь закрыть файл, когда всё из него загрузил!

Вот так. Удобно, а? wink

Прикрепления: 4461945.h(11.6 Kb)


[Беженец со Скаев]

Сообщение отредактировал Yandersen - Вс, 12 Июл 2009, 18:44
 
smt005Дата: Вт, 14 Июл 2009, 14:11 | Сообщение # 66
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (Yandersen)
Чессгря, я имел в виду не физику-физику, а игровое моделирование физики

Я тоже, нах мне НЕигровая физика ?

Quote (Yandersen)
прочитать метровый файл разом во много-много раз быстрее
Знаю.

Quote (Yandersen)
картинки текстур и описания материалов также нуна пихать в тот же файл
Нет, текстуры однозначно должны быть отдельно. Так можно будет использовать любые изображения, что облегчит редактирование. Не знаю как тебе, но мне, отдельно загружать текстуры удобней. К томуже, JPG фозможно быстрее загружается чем твой и другие форматы.
Quote (Yandersen)
но зато избавит тебя от возможности словить багов.
Какие баги? Сейчас у меня загрузка текстур отдельно, никаких багов.

Quote (Yandersen)
современное железо уже достаточно вместительно, чтобы плюнуть на такие мелочи,
Ты говориш что хочеш сделать универсальный движок (тени...) для всех компов, и говориш что компы сейчас мощьные, определись наконец что ты хочеш сделать.
Скорость загрузки важна только в случае, если модели загружаются в процессе работы, и это актуально только при "пипец" большой локации. К тому же, придётся работать с многопоточностью, и формат файла возможно придётся полностью менять.

Quote (Yandersen)
Тут согласен пока?
Согласен.
Quote (Yandersen)
я рассматриваю файл как набор последовательно идущих кусков
Я тоже так расматриваю.

Quote (Yandersen)
Вот так. Удобно, а?
Да, кроме совмещения в файле текстуры и геометрии.

Добавлено (13 Июл 2009, 23:16)
---------------------------------------------
Получилось у меня смешивать текстуры!

Вот ссылка как это делать.
http://www.clockworkcoders.com/oglsl/tutorial8.htm

Добавлено (14 Июл 2009, 14:11)
---------------------------------------------
Кто нибудь в матрицах разбирается?

Не могу понять как инвертировать матрицу 4х4.

 
YandersenДата: Вт, 14 Июл 2009, 18:43 | Сообщение # 67
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
Quote (smt005)
Не могу понять как инвертировать матрицу 4х4.
ПОНЯТЬ?! Это невозможно. biggrin К счастью, у мну есть хорошая книжка по матре, так что обожди немного, я функциовины тебе напишу.


[Беженец со Скаев]
 
smt005Дата: Вт, 14 Июл 2009, 20:20 | Сообщение # 68
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
О, давай, инвертирование матрици, это наверно последний шаг перед созданием тени с использованием шейдеров.
 
YandersenДата: Вт, 14 Июл 2009, 21:16 | Сообщение # 69
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
Книжка у мну письтатая - "Конспект лекций по высшей математике (Том1)" Дмитрия Письменного. Шикарная вещь - простая и всёвключающая, очень советую.
Почти готово. Составляю хеадер с макросами и inline-функциями по умножению, вычислению детерминантов и обратных матриц для матриц 2-го,3-го и 4-го порядков. На все случаи жизни, такскать. Подожди чуток, я уже скоро. wink


[Беженец со Скаев]
 
smt005Дата: Вт, 14 Июл 2009, 21:29 | Сообщение # 70
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Поспешил ты, уже не горит. Я использовал чужой код из примера, принцип инвертирования не понял Но работает. biggrin Но думаю когда нибудь пригодится твой хидер.

Лучше объясни как всё это работает и как работает твой хидер (НЕ как им пользоваться...).
Я в твоих хидерах нифига не понимаю.

 
YandersenДата: Вс, 19 Июл 2009, 17:01 | Сообщение # 71
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
Quote (smt005)
Я в твоих хидерах нифига не понимаю.
Там будет функция InvertMatrix4x4 с двумя аргументами - первый - матрица, которую нуна инвертировать, а второй - указатель на матрицу, куда результ записать.
Т.е. если у тя есть две матрицы
float A[16];
float I[16];
То чтобы посчитать инверсную матрицу запишешь так:
InverseMatrix4x4(A,I);
И матрица I будет инверсной матрицей для матрицы A, что тебе и нуна. Пока что работают правильно функции по инверсированию матриц 2-го и 3-го порядка, но 4-го пока неправильный результ даёт. В хеадере уже есть функции по умножению матриц и считанию определителей.
З.Ы.: считается, что матрицы записаны по столбцам, как в OpenGL. Завтра закончу хеадер, сегодня время уже нет - на работу пора, сорь.

Добавлено (19 Июл 2009, 17:01)
---------------------------------------------
smt005, ты уже определился с форматом графических данных, которые использовать для рендеринга? Я тут прежде чем с тенями ковыряться, хочу сначала иметь модельку для рендеринга, желательно гружёную из файла. Хотелось бы придти с тобой к одному формату файла. Ну, как минимум, пока что только к одному формату хранения и отображения аттрибутов вершин.
Ты знаешь, я люблю код классами писать, да в хеадеры паковать. Так вот щас я пишу класс TSurface для загрузки, хранения, записи, отображения графических данных модели. Однако хочется в стандартном русле поработать - давай определимся с нашим форматом модели.
Мы твёрдо решили использовать массивы для хранения данных, верно? Но какие - отдельные для каждого аттрибута или один смешанный? Смешанный быстрее и работать с ним проще. Но мы имеем ограниченный набор возможных способов паковки аттрибутов вершин - см. glInterleavedArrays. С другой стороны, используя независимые массивы для каждого вида аттрибута, мы можем настроить каждый массив по-своему, однако это дольше, поскольку каждый из используемых массивов придётся Enableать и описывать отдельно при рендеринге.
Я бы всё же рекомендовал смешанный массив, однако какой тип выбрать?
Нужно учитывать, что на данный момент скорость отрисовки уже зависит не столько от крутости видюх, способных рендерить графику со всеми наворотами за один такт, сколько от пропускной способности шины - другими словами, скорость определяется по большей части объёмом данных, идущих на видюху, которая тупо простаивает, ожидая пока все аттрибуты очередной вершины сколлекционируются. Так что чем меньше аттрибутов вершин мы пошлём, тем быстрее модель будет отрисована. Поэтому выбранный тип паковки аттрибутов вершин не должен включать нагрузочных аттибутов (как четвёртая координата вершины или текстуры, массив флагов и т.п.). С другой стороны, без некоторых аттрибутов мы не обойдёмся.
smt005, какие аттрибуты ты юзаешь? Учти, пока что не существует массивов мультитекстурных координат (как смешанных, так и отдельных), даже в OpenGL 2.1.
Я тя слушаю внимательно. wink


[Беженец со Скаев]
 
smt005Дата: Вс, 19 Июл 2009, 18:05 | Сообщение # 72
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (Yandersen)
smt005, ты уже определился с форматом графических данных, которые использовать для рендеринга?

Я уже сделал конвертор из OBJ в 3DK(назвал так свой формат biggrin ) !

Quote (Yandersen)
как минимум, пока что только к одному формату хранения и отображения аттрибутов вершин.
Да, на данный момент НЕ надо делать навороченый формат типа MAX...

Quote (Yandersen)
Но какие - отдельные для каждого аттрибута или один смешанный?
Смешанные, это хорошо НО на данный момент надо использовать отдельный. Т.к. данные этих массивов могут понадобится для других целей, например для физики (в данный момент так у меня).
Quote (Yandersen)
сколько от пропускной способности шины
Можно использовать статический буфер, когда дынные загружаются один раз и храняться всё время в видюхе.

Quote (Yandersen)
как четвёртая координата вершины или текстуры
Это ещё что такое, что за четвёртая координата?

Quote (Yandersen)
Учти, пока что не существует массивов мультитекстурных координат
Я поигрался с мультитекстурированием, каждая новая текстура очень сильно нагружает видюху и надо будет думать как лучше делать текстурирование. Но это не скоро!.............

Quote (Yandersen)
какие аттрибуты ты юзаешь?
Вот так я делаю.
Прикрепления: model.txt(4.6 Kb)
 
YandersenДата: Вс, 19 Июл 2009, 19:30 | Сообщение # 73
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
Quote (smt005)
class CFace // индексы вершин полигона ( из трёх вершин )
{
public:
int v1,v2,v3;
};

Т.е. ты жёстко ограничился только одним типом примитивов - треугольниками. Видимо из соображений облегчения просчёта физики.
Quote (smt005)
CVertex3 * VerBuffer = new CVertex3[iVertex+1];
CVertex3 * NormBuffer = new CVertex3[iNormals+1];
CVertex2 * TextBuffer = new CVertex2[iTextures+1];
CFace * FaceBuffer = new CFace[iFace+1];

А нафига "+1" везде? Запасы на чёрный день? happy
Quote (smt005)
Смешанные, это хорошо НО на данный момент надо использовать отдельный. Т.к. данные этих массивов могут понадобится для других целей, например для физики (в данный момент так у меня).

Quote (smt005)
class CVertex3 // - координаты вершины и нормалей
{
public:
float x,y,z;
};

class CVertex2 // - координаты текстур
{
public:
float u, v;
};


О, т.е. могу предположить, что ты мог бы быть удовлетворён форматом GL_T2F_N3F_V3F для смешанного массива, но просто тебе лень писать макрос, достающий нужные для просчёта физики координаты вершины требуемого элемента из общей массы.
Скажу так: наиболее простое и удобное решение всех проблем - юзать два массива индексов. Сам понимаешь, многополигонную модель рендерить треугольниками - не решение. Поэтому один массив индексов можно юзать для рендеринга, пихнув в него все вершины, упаковав их в оптимальном порядке в GL_POLYGONы и GL_TRIANGLE_STRIPы. А второй массив индексов должен содержать расфасованные по три индексы - для просчёта физики. Кстати, для физики можно вообще не все вершины модели юзать, а выборочные.
Итак, самое важное я у тя выяснил - ты, условно говоря, юзаешь GL_T2F_N3F_V3F. Я буду на это ориентироваться. wink


[Беженец со Скаев]

Сообщение отредактировал Yandersen - Вс, 19 Июл 2009, 19:31
 
smt005Дата: Вс, 19 Июл 2009, 20:25 | Сообщение # 74
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (Yandersen)
жёстко ограничился только одним типом примитивов - треугольниками.
А нах мне больше сейчас. Сейчас задача не в оптимизации!
Quote (Yandersen)
упаковав их в оптимальном порядке в GL_POLYGONы и GL_TRIANGLE_STRIPы
Если хочеш заняться сильной оптимизацией, почитай статьи. Хотя бы одну, например во это. http://www.gamedev.ru/articles/?id=20124

Quote (Yandersen)
А нафига "+1" везде?
Забыл удалить, были глюки ...
 
YandersenДата: Вс, 19 Июл 2009, 23:21 | Сообщение # 75
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
И самое главное - где деструкторы, освобождающие память? Ты ведь юзаешь new - где delete?! Утечки памяти творишь, низзя так потребительски к ней относится - запрашивать, но не отдавать обратно, причём такие количества. angry
Использование классов ведь вот чем хорошо: при уничтожении экземпляра класса автоматически вызывается его деструктор - функция такая особая. Вот в неё и прописывай удаление всех массивов, указатели на которые твой класс хранит. К примеру:

class MyClass{
public:
unsigned int ItemsCount; //Количество элементов в массиве
float *Items; //Массив
float F3[3]; //Статический массив
MyClass(){ //Конструктор класса
ItemsCount = 0;
Items=NULL;
}
~MyClass(){ //Деструктор класса
delete[] Items;
}

};

Конструктор класса (функция ничего не возвращает и должна называться так же, как класс) - вызывается автоматически при объявлении нового экземпляра класса или при его создании с помощью оператора new. В эту функцию пиши код, выставляющий начальные значения, иначе все члены класса будут содержать рандомные значения (мусор).
Деструктор класса похож по синтаксису на конструктор, только никаких аргументов принимать не может, и перед названием имеет значок "~". Он автоматически вызывается перед тем, как объект класса будет уничтожен. Учти: если не пропишешь в деструктор удаление массивов, они так и останутся в памяти - автоматически компиллятор их не удалит, если ты это не пропишешь. Обрати внимание на пример выше: там "Items" - указатель на массив, находящийся где-то в памяти, его ты обязан удалить сам. Но "F3" - тоже массив, однако известной длины - такие массивы находятся прямо в классе, как и все остальные его члены, поэтому о нём тебе заботиться не надо - он будет удалён вместе с самим классом.


[Беженец со Скаев]
 
smt005Дата: Пн, 20 Июл 2009, 00:49 | Сообщение # 76
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (Yandersen)
И самое главное - где деструкторы, освобождающие память? Ты ведь юзаешь new - где delete?

Я как ты заметил, я ПОКА забиваю на оптимизацию...

Конструкторы, деструкторы, это для меня как для тебя "шадоуМап".

 
YandersenДата: Пн, 20 Июл 2009, 23:54 | Сообщение # 77
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
Quote (smt005)
Я как ты заметил, я ПОКА забиваю на оптимизацию...
surprised Какая оптимизация нах?! Ты глюки творишь!!! Это основы, низы, как Техника Безопасности - это в первую очередь знать надо! Да за такое программеры с работы летят! Ты же у себя дома, когда открываешь холодильник пожрать себе чё-нить достать, ты ведь его потом закрываешь, а не открытым оставляешь? Не важно, щикалатку ты оттуда добыть хочешь, или тарелку супа.
Quote (smt005)
Конструкторы, деструкторы, это для меня как для тебя "шадоуМап".
Да коммон! Что тут сложного - прописать в классе функцию, называющуюся так же, как класс, с преффиксом "~", и там delet'нуть все что new'нул. dry Не, smt005, так пахабно низзя программить - конструкторы и деструкторы - это очень важно, хотя и очень просто. Ты должен привыкнуть машинально ими пользоваться. В С++ есть вещи намно-о-ого сложнее, хотя совсем не обязательные.
Не отмахивайся, типа, "а поф". Раз не хочешь литру прочитать по С++, чайников вроде меня слушай. Привыкай писать классы правильно - делай по шаблону. Решил написать класс MyClass, пиши сразу шаблон:

class MyClass{
//Тут будет "личное" содержимое класса - хорошим тоном считается скрытие всего лишнего
public:
MyClass(){ //Дефолтный конструктор (автоматически вызывается при создании класса)
//Тут будет код, прогоняемый сразу после создания класса
}
~MyClass(){ //Деструктор (автоматически вызывается перед уничтожением класса)
//Тут будет код, подметающий говно, разбросанное классом во время работы
}
//А тут будут все остальные функции, доступные пользователю класса - "интерфейс класса"
};

Ты ж учти, в твоём классе модели находятся всего лишь "ярлычки" на то место в памяти, где оператор new создал массив. Массивы не в твоём классе находятся, а вне его. Так что когда твой класс будет удалён, все ярлычки - единственные путеводные ниточки, связывающие его с массивами, будут отрезаны, а массив так и останется торчать где-то в памяти, пока ты комп не перезагрузишь! И так сколько раз ты будешь свою эгоистическую прогу запускать, каждый раз будет сжираться память, и после закрытия проги не возвращаться обратно. И когда у тебя открытие виндусовой папки растянется на пару минут, и ты, злобный, нажмёшь ctrl-alt-del чтобы якобы выяснить, "какого вируса я уже подхватил?!", ты обнаружишь, что из твоих - сколько там - 4-х гигов памяти занято 5, и выпучишь на это зенки. Вот что значит твоё "забиваю на оптимизацию". angry
Массивы - вещь опасная. Везде, где юзаешь указатели (название со звёздочкой "*"), настораживайся. Помни, new и delete всегда должны быть парными, как glBegin и glEnd, как fopen и fclose, как число взлётов и посадок. На это НЕЛЬЗЯ забивать. Конечно, когда ты хочешь суть показать, лишь интерфейс класса, к примеру, тебе не нужно никого посвящать в технические подробности, описывая какой твой класс правильный и всё за собой чистит, какой ты добросовестный программер - "вот, убедитесь, конструкторы-деструкторы у меня на месте" и т.п. Не, это не то, что кто-то должен видеть. Но в реальном коде быть обязано! Не забывай про delete.


[Беженец со Скаев]

Сообщение отредактировал Yandersen - Пн, 20 Июл 2009, 23:59
 
smt005Дата: Вт, 21 Июл 2009, 00:54 | Сообщение # 78
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (Yandersen)
Это основы
Не надо быть таким предсказуемым и лечить меня.
Quote (Yandersen)
Да за такое программеры с работы летят!

На данном этапе я не программер, даже не домашний. smile
Quote (Yandersen)
Не отмахивайся, типа, "а поф"
Я те говорю, С++ особо не изучал, тормозов и глюков у меня никогда небыло а все мои силы и желания были пущены на познание OpenGL.
Если бы были глюки и тормаза, тогда другое дело...

В данный момент, после понятия того как делаются тени и работают шейдеры, хочу разобраться с PhysX. После этого можно писать движок, и тогда придётся более тщательно изучать C++.
Но учитывая то что простых примеров в инете нет, а от тех кто разобрался в PhysX нет помощи, придётся самому его изучать, а для этого придётся получше узнать С++

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

 
YandersenДата: Вт, 21 Июл 2009, 02:02 | Сообщение # 79
1 Поколение
Группа: Доверенные
Сообщений: 196
Замечания: 0%
Статус: Offline
Кстати, smt005, вот ещё интересный момент, об который ты, возможно уже спотыкался. Насчёт конструкторов.
Ты, случайно, не пробовал упрощать себе жизнь, писуя класс для хранения аттрибутов вершины? Скажем, TVertex, описывая его примерно таким простым способом:

class TVertex{
public:
float T[2];
float N[3];
float V[3];
};

Ну, к примеру, для того, чтобы сделать смешанный массив "TVertex Vertexes[100];", но чтобы можно было легко и удобно обращаться к отдельным аттрибутам вершины, типа "float vx = Vertexes[13].V[0];". Если пробовал, то, скорее всего, получал ошибку компиллятора, что, типа, он не может найти какой-то там дефолтный конструктор. Дело в том, что такой закон в С++: при создании массива из элементов написанного тобой класса, для каждого из них, по закону, должен вызываться конструктор. Если его нет (а ты, как я знаю, не имеешь привычки их в класс пихать happy ), то компиллер встаёт в позу - "нет вот, напиши мне конкретно, что я должен делать, отведя кусок памяти под свежий класс". Чаще всего, он прав - ведь отведённая под класс память содержит беспорядочные данные, так что все члены твоего класса будут содержать рандомную дребеду, и в большинстве случаев даже необходимо выставить всем членам класса дефолтные значения от греха подальше. Но в случае простого класса, как в нашем случае, где никакие "значения по-умолчанию" нам нафик не нужны - мы сами их потом введём, когда понадобится, или из файла загрузим вообще - конструктор нам тут как бы и не нужен. Но тупой компиллер нас всё равно не пустит дальше, пока ему конструктор не покажешь. Ну так придётся его наипать немножко - написать пустой конструктор. Типа "слушай приказ: нифика тут особого мне не делай smile ". Т.е. вот как наш класс вершины должен выглядеть, чтоб из него можно было массив составить:

class TVertex{
public:
float T[2];
float N[3];
float V[3];
TVertex(){} //Вот он наш пустой конструктор, который требует компиллер
};

К слову сказать, деструктор этому классу не нужен - никакого мусора класс вокруг себя не создаёт, так что ничего "экстра" удалять не надо, а соответственно, и деструктор вписывать незачем.

Добавлено (21 Июл 2009, 02:02)
---------------------------------------------

Quote (smt005)
з.ы.: если бы я занимался изучением С++, я бы давно забил на всё от скуки. А сейчас имею хорошее представление OpenGL и у меня появился стимул изучать С++................
Наверное, я изврат - мне даже интересно было Брюса Эккеля читать... dry
Ну так я ж на тя не давлю, типа, вот, ты обязан почитать про С++, а то пипец всему. Я тоже зрел на прочтение долго. И читал долго по моим меркам - неделю целую, каждый день. Но тебе, может, и не обязательно на это время убивать - всегда есть я и Разужиб, которые тя просвятят по вопросу, если возникнет. А я ещё буду ловить за руку, если дела некомпиллеруугодные творить на моих глазах будешь. happy
Кстати, вот ты говоришь, "нифика в моих хидерах не сечёшь". Ну так просто я пишу их так, чтобы пользование продуктами, в этих хидерах описанных, было бы для программера-пользователя не сложнее, чем функциями OpenGL, однако написание их самих требует некого уровня знания С++ - "использования всяких кривых значков и непонятных функций". smile


[Беженец со Скаев]

Сообщение отредактировал Yandersen - Вт, 21 Июл 2009, 02:07
 
smt005Дата: Вт, 21 Июл 2009, 03:39 | Сообщение # 80
Admin
Группа: Администраторы
Сообщений: 936
Статус: Offline
Quote (Yandersen)
Ты, случайно, не пробовал упрощать себе жизнь

Quote (Yandersen)
Скажем, TVertex, ...........

Quote (Раньше делал вот так:)

// --- ВЕРШИНЫ ------------------------------------------------------------------------
class TVertex
{
public:
// - вершины
GLfloat GetVer(int i) {return Vertex[i];}
void SetVer(int i2, GLfloat Ver) {Vertex[i2] = Ver;}
private:
GLfloat Vertex[3]; // - вершины
};

Т.е. примерно то что ты предложил, но в дальнейшем я перешёл на то что есть.
.x, .y, .z легче воспринимаются по сравнению с [0], [1], [2].
К тому же я это перенял с примеров wingman.org.ru, а там чувак любит классы сильнее чем ты. smile

Quote (Yandersen)
всегда есть я и Разужиб
Разум? Он вообще походу отошёл от програмирования по направлению игр. И на форуме последний раз он появлялся уже не помню когда.

Добавлено (21 Июл 2009, 03:39)
---------------------------------------------
Личные сообщения посмотри.....

 
Форум "Механоиды 3" » Рабочий раздел. » Графика » Графика: 3D модели и OpenGL (свой движок)
  • Страница 2 из 3
  • «
  • 1
  • 2
  • 3
  • »
Поиск:


Хостинг от uCoz