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

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

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

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

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

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

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

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

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

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

Получилось написать прогу которая использует шейдеры. Осталось только изучить сами шейдеры.

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

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

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

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); //Не забудь закрыть файл, когда всё из него загрузил!

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

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

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

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

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

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

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

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

};

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

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

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

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

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

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

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

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

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

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

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

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

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