Не понял. Как раз могу задать встречный вопрос - вы все что , всерьез решили отдельными полигонами рисовать ?!!! Народ, кто всерьез моделированием занимался, спецэффекты для голливуда делал - ну скажите им ! У меня слов нет.
Если вы не в курсе откуда у NURBS берутся текстурные координаты то в форуме рассказать места не хватит. Опять же я не выпендриваюсь, мы затеяли грандиозный проект по масштабам уровня ждалкера и наукоемкость должна быть большая. Даже NURBS - устаревшая технлогия, нам нужно генерировать эти NURBSы на лету в зависимости от изменений скелетной модели. Я уверен что в конце мы придем к некоторой программе которая на основе данных вроде меню выбора RPG персонажа, вроде того - тощий/жирный - 30%, низкий/высокий - 10 %, Злой/добрый (в смысле угловатый / закругленный) - 70%, смелый/трусливый - (изгиб позвоночника, разворот плеч ?) ну и так далее. Программа сформирует скелет, (ну это наверно просто). Потом нарастит кожу (NURBS). Как так "нарастит" ? Точно не знаю . Нарпимер по графу сочленений скелета найдет листья сделает конечности и пойдет
внутрь до тех пор пока не наткнется на сочленения. Пусть пока это будет что то вроде сосиски - в конечности общая точка потом просто цилиндрической формы урпавляющие точки. Самое сложное - сшить в местах сочленений. Да ладно, как нибудь прорвемся . В итоге будет гладкая сосиска - многоножка. Вот здесь и начнется - на этапе формирования скелета мы разумеется зададим где голова и прочее. На основе этого надо гладкие NURBS цилиндры превратить в голову кисти рук ног. Наверно нужно что то вроде неких шаблонов, к примеру 3D текстуру головы под которую подгоняются упр точки. Хотя такой сложный объект как голова и лицо наверно надо делать тщательней, может вторичный псевдо скелет затем Metaball и в конечном итоге NURBS.

AST_GL Обязательно взгляну в понедельник. Скриншот с чайником сильно впечатлил, решпект. FPS не очень Давайк нам игру делать !
Кстати я заявку на http://sourceforge.net отправил ! Запарился отвечать на кучу вопросов - типа к какому классу программ принадлежит проект, да какая лицензия, да почему не присоединился к другим похожим проектам а свой открыл.

Кривой двиг? Модели лежат в сис. памяти? Не используются вертексные array'и? Скачай пример моего двига (ссылку смотри в моих предыдущих постах) - сам увидишь. Фпс смотри Fraps'ом.. Если есть 3DS Max - сделай любой объект (да хоть сверхдетализированный чайник) на 3 млн. полигонов и экспортируй (сперва надо положить мой плагин в папку плагинов 3DS Max'а) его в x3d-файл, а затем просмотри моим вьюером. Будет как минимум 30фпс!

Смотрится очень неплохо. Думаю таким и должен быть наш движок. Максимум полигонов - минимум гемороя с текстурами и всяким там маппингом. Но вопрос в другом - какова производительность твоего движка по полигонам/сек. Нам нужны тысячи полигонов в модели и сотни моделей на карте. Представь что если в пике игровая видеокарта отрисовывает 100-200 млн полигонов в секунду, то нам нужен именно такой порядок >10^8 полигонов/сек. А сколько может твой движок?


1. Качай - там все в примерах.
2. Если начнем с конца получим слишком много проблем к началу На самом деле реальных проблем 2 - АИ и физика т.к. графический движок ( хоть какой-то ) можно состряпать 1 челу за месяц. Дело в том, что вся графика и вся логика будет произростать из физики. Графическая модель будет добавкой к физической, а никак иначе.

Ты про дизайн уровня или про перемещение объектов по ландшафту?

А что по скорости?

Что до названия проекта ... назовем его Sunrise ака восход, а игру назовем ... а хз как мы ее назовем. Ваши предложения с учетом сюжета и классификации?



Вот что будет по архитектуре:
По размерам карты... Нужен алгоритм запаковки/распаковки объектов в памяти. Грузим все запакованным - по мере необходимости пакуем/распаковываем те или иные объекты. Мир без загрузок. Памяти (озу) минимал - 300, норм 550 Мб, кул - 700 Мб. при отсутствии памяти на лету распакорвываем->обсчитываем->запаковываем объекты.( минимум свопа - он в любом случае будет тормознее самой злостной перепаковки ) затем распаковываем другие и т.д. Объекты пакуются по-умному. Чем обобщеннее инфа тем легче ее выкусить из архива и только для получения самых мелких деталей нужно распаковывать все.
Все геометрические представления работают по типу N-патчей. Приблизился объект - больше порядок, отдалился - меньше. Причем все подсчитанно так, что на меньший уровень объект перейдет только тогда, когда это действительно не ухудшит его визуальный вид.
Мапы очень большие. Предусмотрены сектора и предсекторные зоны. Сектор рисуется только тогда, когда человек либо в нем, либо в предсекторной зоне.
С физикой гораздо тяжелее. На карте присутствует несколько персонажей, которым "позволено" вносить изменения в структуру объектов ( это персонажи-действующие лица ). В тех секторах (и предсекторных зонах) , где они есть физика считается полностью. В остальных секторах упрощенно - только перемещение объектов, отсутствие взаимодействия между ними класса "модифицирование геометрии".
Полный геомод, возможное разрушение любых объектов. Реальные дыры от пуль а не черные пятна.
Человеческое тело состоит из нескольких объектов, тела персонажей очень детализированны вплоть до костей. Потеря той или иной функциональности происходит по факту разрушения какой-то части тела ( перелом пулей кости, прострел сердца ). Все энергитические атаки имеют физическую интерпретацию, выражаясь в огненных шарах, прожигающих плоть и взрывающихся при столкновении с той же стеной.
Взрывы рождают объект ударная волна и тепловая волна, которые быстро расширяясь производят изменения объектов с которыми сталкиваются.
Каждый физический объект имеет ряд свойств, среди которых геомертическая его форма.
Могу еще многое обрисовать ...

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

All случайно попал на интересный физический движок http://continuousphysics.com/Bullet/ Называется он Bullet и разрабатывается бывшим разработчиком Havoc.
Использует lcp solver из ODE. Демки мне понравились, скачал - буду разбиратся.

Ну я так в общем то и думал. Я вообще тут о кишках подумываю ... Уж их-то точно автоматом надо будет делать

И еще: ПОЛИГОНОВ БУДЕТ БОЛЬШЕ 1 МЛН. Это я вам сразу говорю. Поэтому соответственный и двиг нужен.
Вообще в сценах наших в жаркие баталии в раздроблением местности кол-тво полигонов будет достигать десятков миллионов, но большинство из них будет в неотрисовываемых местах ( внутри домов, за спиной и так далее )
Добавлено спустя 1 минуту, 49 секунд

А X1800 XT рендрит ... 1,25 МИЛЛИАРДА полигонов в секунду. А через 2 года каждая третяя игровая машина будет такой ... Так что не жалеем полигонов и пишем НОРМАЛЬНЫЙ двиг.

Пока ещё не качал (dialup ), но скачаю, заценю.

Насчёт кривости, я бы так радикально не отзывался.
Когда ты дойдёшь до сложных эффектов, связанных с прозрачностью, отражением или свечением, то FPS упадёт у тебя раза в четыре. Если в моём движке выключить сглаживание, свечение и воду, то FPS поднимается раз в пять.

Почему? Сейчас обьясню:
Каждый кадр рендерится в 4 прохода:

1) рендеринг сцены втекстуру разрешением 512 х 512.
Эта текстура нужна для реализации преломления в воде. Она накладывается на плоскость воды с умножением на текстурную матрицу с обратным перспективным преобразованием + с помощью шейдера добавляется рябь.

2) рендеринг сцены отражённой относительно плоскости воды сцены в текстуру разрешением 512 х 512.
Эта текстура нужна для реализации отражения в воде. Она накладывается на плоскость воды с умножением на текстурную матрицу с обратным перспективным преобразованием + с помощью шейдера добавляется рябь.

3) рендеринг бликов, света сцены сцены в текстуру разрешением 128 х 128.
Эта текстура нужна для реализации сияния (HDR glow effect). Она накладывается на вьюпорт с использованием Alpha blending-а и шейдера размытия (bluring).

4) финальный рендеринг сцены

В рендеринге каждого прохода нужно держать включённым бампмэппинг. (сильный удар по скорости).

Наверное демонстрация разных шейдеров на чайниках тоже fps не прибавляет.

Если выключить в моём движке все шейдерные эффекты и рисовать всё только с лайтмапами, то скорость на моей конфигурации >> 100fps. Только с шейдером бампа и спека ~45-65 fps.
Вот так вот.

С водой это сложно ... согласен. Но все же криво. В фаркрае все летает ...

AST_GL

1,2,3,4 - нужно. 5 - нет, т.к. это лишние 12 байт на вертекс, а бинормаль можно найти из кросс-продукта с тангентом.
Кстати твой двиг случаем не на GUNgine основан? Да еще: юзай VBO (ARB_vertex_buffer_object). И еще написав на GLSL шейдер, можно проверить на конкретной видяхе будет ли он работать программно (супер-тормоза), либо аппаратно (быстро, особенно если используется VBO).
Кстати у тебя случаем не выделенка? Если да, то закинь (исходящий трафик как правило не тарифицируется) плиз свою дему на мой ящик (espsoft@e1.ru), а то мне качать накладно, у меня за 1Мб трафика дофига берут, а мой ящик - относится к бесплатной сети. Если надо я могу тебе куда скажешь выслать примеры своего двига (чтобы с бесплатного трафика тебе качать) - исходящий трафик-то не тарифицируется


1250000000 / 10000000 = 125 fps при 1 направленном источнике света, что неплохо, но я то имел ввиду от 5 и более источников света (либо модели с бампом, спекуляр-мапом и 1 источником света на модель), в результате получим те же самые 50fps, что и на GF7800 GTX

А по скорости OpenGL быстрее, только недавно скандал был на тему, майкрософт решила в висте запускать опенГЛ через ДиректХ, то есть искусственно замедлять его.

кажется здесь обсуждалось:
http://www.opengl.org/discussion_boards ... 2;t=000001
и на оверах было.

Все же хорошо что есть человек, который на практике знаком с шейдерами, многопроходным рендрингом и т.п. Присоединяешься?
Добавлено спустя 2 минуты, 3 секунды
BaBL, а с чего ты взял что OpenGL быстрее? По большому счету дело не в АПИ а в железе. Но все же что проще АПИ OGL или D3D???

Alex-scat Д3Д проще, конечно же, но ОпенГЛ все же быстрее, это не я взял, это на примерах разных игр видно. Да и офф сайт опенгл полистай, там цифры есть



Нурбсы - хорошо, но со времен Ку3 я их не видел =/ Картинка будет красивой, но Вы уверены что сейчас они будут быстро обрабатываться? По-моему про них уже забыли производители видео

Потолочной полигональной производительности видеокарты хватит с запасом. Вопрос в поцессоре. Надо сразу многопоточную делать т.к. через 2 года уже 4-хядерники будут ... А это тебе не шутки.
Добавлено спустя 3 минуты, 49 секунд

Хорошо, тогда вопрос ставлю по-другому: кто уже сейчас умеет неплохо программить под АПИ OpenGL или D3D ( в т.ч. не только меш вывести а еще и эффекты современные, типа тех же шейдеров, многопроходки )???
Так и выясним, какой апи заюзать

Да, это уже предметный подход =) Скорее всего победит Д3Д.


У меня руки до Директа и Опена как-то не дошли, жалею об этом. Остановился на написании приложений офисной направленности, а потом вообще в веб ушел и сейчас тут прогаю. Так что если будет нужен сайт поддержки - пишите =) При условии что художника/дизайнера добудете

Кстати, жалко что у НВ ТруФорм нету ... а то почти нахаляву Н-патч 4-ого порядка имели бы ...

Ну не быстрее конечно. Но и не медленнее. Если вам инетресно я могу написать как они работают в подробностях и с исходниками OpenGL, чтобы было понятно что ничего кроме как растеризации треугольников они не умеют делать. Вот придумали еще шейдры, это значит есть возможность немного поизвращяться с основными данными перед растеризацией и во время определения но к API это никакого отношения не имеет. А DirectX API только ленивый не ругал . Опять же - найдите DirectX на Apple OSX или *BSD/Linux.

OpenGL для начинающих легче.
To BloodyWerewolf:
1. VBO в движке есть
2. Нет на GunEngine мой двиг не основан. Я юзаю туже модельку, что и он. Модель эта очень распространённая в сети.
Из GUN engine у меня только класс String. Окно написано на Winapi и основано на окне Nehe.

STTS, а где больше глюков. Ну то есть ты написал на своей тачке отладил а на других тачках какие-то глюки ... С каким движком так чаще бывает и почему? Д3Д или ОпенГЛ??

Глюков больше на Direct3D. Потому что я считаю за глюк невозможность запустить программу под MacOS или Линуксом без Wine'а. На самом деле по глючности они одинаковы.
Только что выкроил время и поглядел ODE ( библиотеку с открытым кодом по физике связаных жестких тел) . Пример просто ошеломил - особенно тот с падающими друг на друга шарами и кубами. Сразу захотелось с ним поиграться. Почитаю документацию, может как раз нам с чего нибудь подобного начать ? Непонятно как потом эти пляшущие кубы заставить менять скелет.

STTS, ты его конечно поисследуй ... для сравнения. Я же уверен что он абслоютно не отвечает необходимым нам требованиям начиная от скорости. И потом, возможен ли в этим движке пробой одним предметом другого или девормация? А как там с поддержкой воды?

Давайте определимся, что мы хотим отождествить с объектом:
- это однородное вещество с какими-то характеристиками ( плотность, температура, упругость, порог ломкости, пластичность, мягкость, поверхностное натяжение и т.д. )
- с физическими координатами границ
- с заданным агрегатным состоянием
- с возможным напряжением материала ( т.е. как если подсогнуть прутик )

Границы:
- граница может быть только между объектом и объектом
- на границе объекты могут быть "склеены" - с каким то коеффициентом сила/площадь

Возможное влияние на объект:
- векторы сил, приложенные в заданных местах, давление на границу
- термическое воздействие

При взаимодействии объектов:
- вычисляются вектора сил и давлений на объект, в связи с чем он изменяет свое геометрическое положение и свои границы. Может измениться натяжение, плотность и т.д.

Физический движок ( по крайней мере иерархию объектов ) напишу я сам.

По идее это кажется все?
Предлагайте, а то я тут распинаюсь - да уже сяду писать. До уровня какой-никакой работоспособности его за 2 недели довести можно... А там на физические объекты начнем наворачивать графику, звуки и т.д.