Войти
ПроектыФорумУтилиты

Amateur 3d engine - Sateney engine v0.1 (2 стр)

Страницы: 1 2 3 Следующая »
#15
19:19, 25 авг. 2005

NuGA
Интерполяцию анимации? :) Да не делал... Как-то не показалось важным, а потом и вообще вылетело из головы... Спасибо добавлю...


#16
22:16, 25 авг. 2005

И ещё: жуткий z-fighting. Во всяком случае у меня. У тебя zNear и zFar не сильно оптимистично поставлены?
Линейную интерполяцию делать в любом случае, сильно дёрганый афроамериканец какой-то без неё )
А вообще всё это напомнило мне мои потуги трёхлетней давности ) Пророчествую: проект ты этот не закончешь, надоест, но опыта наберёшся неплохо )
Хотя судя по той методичности, с которой ты на форуме планы свои отписываешь, всё может быть.
Щаз исходники посмотрю, ещё покритикую )
ЗЫ: ты забыл стадию "Половое Созревание" добавить :)

#17
23:13, 25 авг. 2005

Vadun
>И ещё: жуткий z-fighting

Честно говоря первый раз услышал про данный эффект :) Порылся в сети и нашел:

Z-fighting is a phenomenon in 3D rendering which occurs when two or more coplanar primitives have the similar values in the Z buffer (usually caused by floating point round-off errors), causing random parts of the primitives to be rendered. Z-fighting is reduced by the use of a 32-bit depth buffer, or a W-buffer.

И Z-fighting - проблема "моргания" изображения, когда выводятся coplanar planes используя разные вершины.

Эт, я так, может быть кому-нить тоже поможет =)

>У тебя zNear и zFar не сильно оптимистично поставлены?

Ну так это... zNear = EPS (1e-3f), zFar = 200

>А вообще всё это напомнило мне мои потуги трёхлетней давности ) Пророчествую: проект ты этот не закончешь, надоест, но опыта >наберёшся неплохо )

Хех, было бы это три года назад, может быть и не закончил бы... А сейчас... Мне уж 19 почти... :) Бум стараться...

>Хотя судя по той методичности, с которой ты на форуме планы свои отписываешь, всё может быть.

Ага :) Вот кста уже добавил 2-хмерные вектора и переделал соответствующие классы, начал консоль колбасить =)

>Щаз исходники посмотрю, ещё покритикую )

Ждемс :) Вот как раз исходники это очень интересно - т.к. комменты к бинарникам уже были.. А к исходникам, ты первый по-видимому будешь...
>ЗЫ: ты забыл стадию "Половое Созревание" добавить :)

Хе-хе :) Так получилось просто, в стиле Толстого... Сначала было "Добавление фичей" и "Добавление фичей2" =)

#18
23:20, 25 авг. 2005

Исходники довольно красивые, молодец.
Имхо, немного перестарался с классами. Класс IRender (и сабклассы) я бы выкинул к чёртовой матери, вместо них оставил TextureManager, FontManager и т.п., а весь ренедринг производить непосредственно вызовами OpenGL команд. Или ты собираештся D3D рендерер реализовывать?
Ещё пару советов: 1) при проверке bboxa на пересечение с фруструмом учитывай всякие coherencies ) Вот превосходная статья на эту тему: http://www.cg.tuwien.ac.at/studentwork/CESCG/CESCG-2002/DSykoraJJelinek/ . У меня скорость в статическом режиме возрастала в разы. Минус - заметный скачок на малый (относительно) ФПС при быстром вращении мышкой :) (все эти когеренция не срабатывают).  Правда он был заметен только в Debug режиме )
2) забей на текстурные шрифты! FreeType рулит нипадецки. Я себе его встроил, не жалуюсь, очень, очень красиво, а по скорости - на том же уровне (фактически вместо одной текстуры он у меня делает 255 ) а затем в случае необходимости (если юникод появляется), ещё доделывает ) причём все параметры динамически менять можно, грузить файлы шрифтов и т.п. - одним словом - сказка :)

#19
23:39, 25 авг. 2005

Vadun
>Исходники довольно красивые, молодец.

Сенкс, стараимси :) В конце каждой (правда она всего одна пока была :) я оставляю время на рефакторинг - т.е. на причесывание кода, удаление отладочного кода, доделывание мелочей и т.п. :)

>Класс IRender (и сабклассы) я бы выкинул к чёртовой матери, вместо них оставил TextureManager, FontManager и т.п., а весь ренедринг >производить непосредственно вызовами OpenGL команд. Или ты собираештся D3D рендерер реализовывать?

Конечно. (грустно) Даже думаю перейти на него совсем в будущем (ну это где-то 4-5 итерация ориентировочно :) Принял такое решение после прочтения вот этой ветки :(. Особенно втыкать на топик 143.

За советы спасибо, обязательно их приму к сведению(даже записал в текстовик :). А вообще на данный момент, принял решение как можно больше использовать сторонних библиотек (в искодных кодах которые), для минимизации времени разработки, типа glew, libjpeg и т.п. Потом надеюсь написать что-нить аналогичное самостоятельно...

#20
23:46, 25 авг. 2005

Ещё пару замечаний:
1) ссылка на libsdl левая ) www.libsdl.org - вот, где сила
2) В bool Engine::Init()
                                                                                  V - ноль тут лучше не ставить ) 0.1 вполне нормально пойдёт
mainCamera = new Camera(vec3f(0,0,-3), 0,0,0, 60,0, 200,800,600);
После этого zFighting прекратиться
3) md2 - не очень актуальный сейчас формат... ничего предложить не могу, т.к. в этом не шарю...
4) Может я чего-то не понял, но мне кажеться, что ты текстуры хранишь по два раза - один раз в Texture::data, другой раз в OpenGL'е, когда gluBuild2DMipmaps вызываешь. Вообщем, делай нормальный TextureManager и всё разруливай умными указателями (так как сейчас точно не пойдёт).

Ну пока всё ) Консоль я бы не спешил делать. Вначале лучше скриптовый движок встроить (lua пойдёт в самый раз, если по-advanced и по-гемморней, то Python), а весь ввод консоли потом уже на него переправлять ) Так красиво получается ) Хотя может скриптовый движок здесь - это уже излишество...

#21
23:55, 25 авг. 2005

> А вообще на данный момент, принял решение как можно больше использовать сторонних библиотек (в искодных кодах которые), для минимизации времени разработки, типа glew, libjpeg и т.п.
Это правильно, так и надо. Зачем изобретать велосипед?
> Потом надеюсь написать что-нить аналогичное самостоятельно...
А вот этого лучше не делать ) libjpeg, например, по сложности, имхо, не один движок заткнёт. Хотя, как знаешь )

#22
0:02, 26 авг. 2005

Vadun
>Ещё пару замечаний:
>1) ссылка на libsdl левая ) www.libsdl.org - вот, где сила

Fixed.

>2) В bool Engine::Init()

Fixed.

>3) md2 - не очень актуальный сейчас формат... ничего предложить не могу, т.к. в этом не шарю...

Хехе, да уж - только вертексная анимация... Для склетной щас вообще имхо стандартного и/или распространенного нету... Ну кроме .x, конечно...

>4) Может я чего-то не понял, но мне кажеться, что ты текстуры хранишь по два раза - один раз в Texture::data, другой раз в OpenGL'е, когда >gluBuild2DMipmaps вызываешь. Вообщем, делай нормальный TextureManager и всё разруливай умными указателями (так как сейчас точно не >пойдёт).

А вот за это спасибо... Дал пищу для размышлений :) Я просто еще не очень с OpenGL знаком (и тем более не знаком с директ3д :). А умные указатели это типа std::ptr? И чем они вкратце отличаются от простых (можно ссылку :)?

>Ну пока всё ) Консоль я бы не спешил делать. Вначале лучше скриптовый движок встроить (lua пойдёт в самый раз, если по-advanced и по->гемморней, то Python), а весь ввод консоли потом уже на него переправлять ) Так красиво получается ) Хотя может скриптовый движок здесь >- это уже излишество...

Луу я планировал :) но чуть позже... А вот насчет "ввод с консоли" - это т.е. логику консольных комманд на скриптах написать?

#23
0:05, 26 авг. 2005

Vadun
>Это правильно, так и надо. Зачем изобретать велосипед?

С одной стороны так то оно так... Но вот с другой стороны... Нафиг тогда получается весь двиг писать? Не проще ли взять Огра или ку3?

>А вот этого лучше не делать ) libjpeg, например, по сложности, имхо, не один движок заткнёт. Хотя, как знаешь )

Ну я ж не собираюсь переписывать оде или луа :) Так мелкие "заимствования" :)

ЗЫ: о! у мя ровно на 6000 ид больше :)

#24
1:05, 26 авг. 2005

>А умные указатели это типа std::ptr? И чем они вкратце отличаются от простых (можно ссылку :)?
Ну вообщем да: http://en.wikipedia.org/wiki/Smart_pointer
Посмотри в сторону boost: http://www.boost.org/libs/smart_ptr/smart_ptr.htm
В кратце: они сами следят за тем кто объект использует, и когда пользователей больше не остаётся, он его удаляет. Причём всё это прозрачно для программиста, "хороший" умный указатель от простого в плане интерфейса почти не отличаеться.
Я использовал, например, так: TextureManager грузит текстуры и хранит их у себя в std::hash_map как экземпляры класса TextureData (содержит ID, параметры, если надо, ссылку на файл откуда загрузили, чтобы иметь возможность перегрузить). А экземпляры класса Texture имеют один только член - TextureData* Data. Перепределены copy-constructor, operator=, деструктор таким образом, чтобы Texture вовремя вызывал AddRef и Release. Фактически это уже умный указатель (или хендлер, хрен знает :) ).
>Не проще ли взять Огра или ку3?
Ну проекты такого уровня сильно много содержат деталей, которые хотелось бы сделать по-другому...
>А вот насчет "ввод с консоли" - это т.е. логику консольных комманд на скриптах написать?
Я делал так: консоль в движке - это аналог интетпретатора python.exe по функциональности. (можно lua.exe сделать). Всё, что хочу, делаю доступным для Питона. Саму консоль, кстати, делал как gui скрипт ) т.е. двиг о консоли ничего даже и не знает, всё на уровне Питона. Двиг только экспортирует в питон классы, функции и т.п. А вот на Питоне уже чудеса можно творить. Сделал, например, remote console, чисто на Python, через sockets. Скрипты рулят )

#25
21:47, 26 авг. 2005

Vadun
За ссылки спасибо, посмотрим :)

>В кратце: они сами следят за тем кто объект использует, и когда пользователей больше не остаётся, он его удаляет. Причём всё это >прозрачно для программиста, "хороший" умный указатель от простого в плане интерфейса почти не отличаеться.

А чем это отличается от reference counting'a?

>Я использовал, например, так: TextureManager грузит текстуры и хранит их у себя в std::hash_map как экземпляры класса TextureData >(содержит ID, параметры, если надо, ссылку на файл откуда загрузили, чтобы иметь возможность перегрузить). А экземпляры класса Texture >имеют один только член - TextureData* Data. Перепределены copy-constructor, operator=, деструктор таким образом, чтобы Texture вовремя >вызывал AddRef и Release. Фактически это уже умный указатель (или хендлер, хрен знает :) ).

Ну ты мою структуру уже видел, добавлю, что как раз для текстур и для мешей сделан референс каунтинг:

class Texture
...
	int 	refCount;
public:
	Texture*			Retain() { refCount++; return this; }
	int				Release() {if (--refCount < 1) { delete this; return 0; } return 1; }

А вот куда вставить std:ptr, честно говоря, не представляю, если только заменить вообще все указатели? У тя как сделано?

Кста, насчет OpenGL - поглядел, вроде все правильно, полная версия текстуры хранится в Texture::data, а в OpenGL генерятся mipmap текстуры, т.е. меньше по размеру...

>Ну проекты такого уровня сильно много содержат деталей, которые хотелось бы сделать по-другому...

Согласен. Вот и сторонние библиотеки хочется сделать самому...

>Сделал так: консоль в движке - это аналог интетпретатора python.exe по функциональности. (можно lua.exe сделать). Всё, что хочу, делаю >доступным для Питона. Саму консоль, кстати, делал как gui скрипт ) т.е. двиг о консоли ничего даже и не знает, всё на уровне Питона. Двиг >только экспортирует в питон классы, функции и т.п. А вот на Питоне уже чудеса можно творить. Сделал, например, remote console, чисто на >Python, через sockets. Скрипты рулят )

Понятно (ну насколько я могу это понять, так как пока о скриптах имею смутное представление :) Ну ты извращенец! :) Имхо консоль должна быть ближе к движку, чем это можно сделать из скрипта. Т.е. консоль - это инструмент разработчика и служит для управления движком (являясь его частью). Т.е. это как бы своеобразная лазейка внутрь движка/игры.  Хотя да,  консоль на скриптах -  это красивое и элегантное решение...

ЗЫ: кста, почему ты питон все-таки взял? Неужели настолько надо ООП? Ведь и фаркрай и нивал и еще куча других игр используют луа... Да и быстрее она раза в 2 среднем (http://www.unigine.com/products/unigine_v0.32/compiler_benchmark/)

#26
22:39, 26 авг. 2005

> А чем это отличается от reference counting'a?
Ну вообщем smart pointer - просто идиома (или паттерн), а reference counting - один из методов его реализации (я только его правда и знаю :) ) Референс коунтинг у тебя есть, только его надо ручками "запускать", т.е. допустим есть текстура (лежит в классе Mesh, к примеру), а мы хотим ту же текстуру в другом меше использовать. С твоей реализацией:
Mesh* m1, m2;
....
if (m1->texture) m1->texture->Retain()
SAFE_DELETE(m2->texture)
m2->texture=m1->texture

C реализацией через смартпоинтеры:
m2->texture=m1->texture :)
Всё возню с Retain и Release он сделает сам. К тому же не надо будет в деструкторе меша SAFE_RELEASE(texture) делать ) это сделает деструктор поинтера.
stdшными и boost'овскими _ptr'ами сам никогда не пользовался ) Обычно реализовую сам. Хотя это не правильно, надо будет boost поюзать...
>У тя как сделано?
У меня все классы содержат не Texture* а просто Texture ). А вот этот класс уже содержит указатель на TextureData* и граммотно управляет им через AddRef и Release. То же самое надо делать с мешами, звуками и вообще всеми данными. Но мне кажеться что этот подход не самый удачным, пахнет изобретением велосипеда.... ЗЫ: содрал из Serious Engine SDK )
>Кста, насчет OpenGL - поглядел, вроде все правильно, полная версия текстуры хранится в Texture::data, а в OpenGL генерятся mipmap текстуры, т.е. меньше по размеру...
Добавь в OGLRender::TextureUpload в самый конец theTexture->GetData().clear() (кстати тоже глюк, объявляй GetData как const std::vector<byte> GetData() const) и всё замечательно отображаеться. При вызове gluBuild2DMipmaps данные копируються полностью (1-й мип-уровень), картинка уменьшаються, копируеться (во 2-й уровень) и т.д. А ты хранишь по два раза...
>Имхо консоль должна быть ближе к движку, чем это можно сделать из скрипта.
А у меня через скрипты доступен самый нижний уровень движка ). Если захотеть, можно подписаться на обработку событий мыши, например, либо отрисовки окна ) Я вообще намеревался что-то такое гибридное сделать, полу-С++/полу-Python.
>ЗЫ: кста, почему ты питон все-таки взял? Неужели настолько надо ООП?
Нет, можно было бы всё и через Луа делать, но как я уже говорил, у меня тесная интеграция, а ООП код С++ биндить в не очень-то OOП Луу не хотелось... К тому же с Питоном поставляеться широчайшая библиотека и в сети куча дополнительных штук есть. Да и язык до жути красивый и функциональный, по функциональности он Луу далеко переплёвует ). Минус один - тормоза.
Если в скриптах реализовывать только игровую логику (триггеры всякие, вроде: нежал кнопку - открылась дверь) (а во многих играх так и сделано), то Луа здесь рулит. ООП здесь не нужно совершенно.

#27
13:41, 28 авг. 2005

Vadun
Понятно. Только у меня не совсем так:

m2->texture = m1->texture->Retain(); // т.е. присваивание идет одновременно с референс каутингом
Кроме того не учитывается, что у меня все члены обычно "в привате" :)

>C реализацией через смартпоинтеры:
>m2->texture=m1->texture :)

У меня не намного сложней :) Хотя ты прав, надо будет попробовать.

>Всё возню с Retain и Release он сделает сам. К тому же не надо будет в деструкторе меша SAFE_RELEASE(texture) делать ) это сделает >деструктор поинтера.

Однако, у своего метода есть как-минимум один плюс - ты точно знаешь, что делает твой код :)

>У меня все классы содержат не Texture* а просто Texture ). А вот этот класс уже содержит указатель на TextureData* и граммотно управляет >им через AddRef и Release. То же самое надо делать с мешами, звуками и вообще всеми данными. Но мне кажеться что этот подход не самый >удачным, пахнет изобретением велосипеда.... ЗЫ: содрал из Serious Engine SDK )

Интересная архитектура, однако я пока не хочу с ней экспериментировать. Вот и шрифт, работает, но хотелось бы получше(не по функциональность, а по реализации)... Делал, делал, нихрена не работает, плюнул и оставил так как есть.

>Добавь в OGLRender::TextureUpload в самый конец theTexture->GetData().clear() (кстати тоже глюк, объявляй GetData как const std::>vector<byte> GetData() const) и всё замечательно отображаеться. При вызове gluBuild2DMipmaps данные копируються полностью (1-й мип->уровень), картинка уменьшаються, копируеться (во 2-й уровень) и т.д. А ты хранишь по два раза...

  Получается что этот член (std::vector<byte> data) только для загрузки? И после создания мипмаппинговых текстур его можно удалять?

>А у меня через скрипты доступен самый нижний уровень движка ). Если захотеть, можно подписаться на обработку событий мыши, например, >либо отрисовки окна ) Я вообще намеревался что-то такое гибридное сделать, полу-С++/полу-Python.

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

>Нет, можно было бы всё и через Луа делать, но как я уже говорил, у меня тесная интеграция, а ООП код С++ биндить в не очень-то OOП Луу

См. выше. :) В играх, имхо, скорость является имхо одним из основных приоритетов.

#28
14:10, 28 авг. 2005

virtul
> Однако, у своего метода есть как-минимум один плюс - ты точно знаешь, что делает твой код :)
Ну более или менее опытный C++ кодер тоже знает когда деструкторы членов класса вызываются ;)
>Интересная архитектура, однако я пока не хочу с ней экспериментировать. Вот и шрифт, работает, но хотелось бы получше(не по функциональность, а по реализации)... Делал, делал, нихрена не работает, плюнул и оставил так как есть.
Могу выслать исходники своего FreeType класса. Правда там не всё красиво сделано...
>Получается что этот член (std::vector<byte> data) только для загрузки? И после создания мипмаппинговых текстур его можно удалять?
Не можно, а нужно ) Но оставляй в классе указание источника, откуда загружена тесктура. Это может понадобиться при пересоздании ogl контекста. Опять же, делай менеджер )
>Если во время разработки проекта такая связка рулит, то вот при подходе к мастеру такая архитектура это сакс точно.
Ну не совсем, мне кажеться... Если я говорю "можно подписаться..." не означает, что нужно ) Просто гибкость есть, в случае чего может пригодиться. Я стараюсь чтобы Питоновский код исполнялся не по кадрово, а только в случае событий (пока заботал только UI) Вот скриншот консольки моей http://www.vadun.nm.ru/2.jpg (обрати внимание на шрифты ;) )

#29
19:08, 28 авг. 2005

>Могу выслать исходники своего FreeType класса. Правда там не всё красиво сделано...

Буду очень благодарен :)

>Не можно, а нужно ) Но оставляй в классе указание источника, откуда загружена тесктура. Это может понадобиться при пересоздании ogl >контекста. Опять же, делай менеджер )

Ага :) Вот только будет ли это работать на glTexImage2d?

>Вот скриншот консольки моей http://www.vadun.nm.ru/2.jpg

Симпатично :)

>(обрати внимание на шрифты ;) )

Готично :)

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

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