Версия для печати :: 3D-Engines - .::Russian Blood Community Forum::. [4]

Мысли хорошие, в сущности хороши не столько мысли сколько желание. Ну да по порядку.

Цитата:

Вообще, я просто предлагаю диллетантски, ламмерски и вандальски извратить ДФДюк, сперев оттуда все, что можно. А то с нуля уже доделалась тройка незатейливых комманд, рухнув в пучину безысходности.

Сомневаюсь в верности такого подхода. Blood всё же не Duke. И не в смысле игры. Архитектурные ньюансы, аи и многое другое.

Цитата:

Кроме всего этого у меня в голове бродит миллиард идей, как преобразить графику Blood'а в порте (т.е. улучшить polymost).

Плохая идея. Я имею ввиду улучшать полимост. Уровень знаний у нас не тот Улыбка

На изучение когда всего polymost уйдет больше времени, чем на создание собственного рендера. Загляни в исходники и поймёшь о чем я.

Цитата:

У меня все время вертелась мысль сгладить затенения на карте, то есть, если создать так называемые размытые края секторов. Естественно, это будет относиться к премыкающим друг к другу поверхностям на углу менее 30 градусов. Это бы не потребывало добавлять источники света, как в Переливании, оставив виденье картинки самого автора, но вместе с этим сделав картинку менее угловатой. Соответственно, это не будет распрастраняться на текстуры пола-потолка-стен, это просто будет карта затенения, которая будет вычисляться не лучами, пущенными от источника света, а расстояниями до более светлых секторов. Еще я бы хотел добавить динамические источники света и динамические тени В варианте без md2-моделей это бы делалось растягиванием по полу текстуры монстра, повернутом по отношению к источнику света (выстрелу). И, в третьих, я бы добавил рисование текстур стен шейдерами, но я об этом имею очень маленькое представление...

Сменить систему освещения в Blood простым наскоком не получится, тем более не получится это сделать используя polymost (либо будет достаточно ресурсоемко). В Blood освещение посекторное. Я так понимаю ты хочешь интерполировать цвет вершин между секторами добиваясь сглаженных оттенков. Только это бессмысленно imho. Дизайнеры уровней и так старались компенсировать "ступенчатость" текущей системы освещения увеличением количества секторов. Может быть немного улучшишь вид. Ещё не факт, что вообще улучшишь.
Растягивать спрайт в качестве тени это нонсенс, поверь. В спрайте не присутсвует информации о геометрии объекта, будет смотреться очень убого. Несколько непонятен термин "рисование" стен шейдерами. В этом нет особой необходимости по той простой причины что шейдеры всё ещё не так уж и распростронены. Фрагментные (пиксельные) шейдеры имеют смысл только при сложных спецэффектах или скажем при попиксельном освещении. Нарисовать текстуру можно и используя обычный модуль мультитекстурирования видеокарты (функциональность DX 7 и ниже).

Цитата:

Я сейчас, так сказать, просто дал обзор своих задумок, потому как у них есть множество нюансов, все из которых я продумал. Например, затенения не будут распрастраняться на слайд-сектора, так как они уедут, а вычислять новое положение карт теней кто будет? Хотя можно сделать пару снимков теней дя статических положений, чтобы ламмер не мог быстро отличить слайд-стену-ловушку, а во время движений можно просто использовать угловатые затенения на самом слайде - итак ведь движется!

Не ясна фраза "карты теней". В Blood нету лайтмапов если ты об этом. Сам подумай - лайтмапы расчитываются не в реальном времени (обычно с использованием некислых алгоритмов вроде radiosity), а при компиляции уровня (См. всяческие Кваки, Анриалы, Серьезные семы и им подобные). В Blood как я уже говорил посекторное освещение с небольшим набором возможностей в довесок. Цвет сектора задается изначально и может изменяться эффектором.

Цитата:

Предупреждаю, это все - мои проблемы. Как видите, они уже не такие безбашенные, как в начале темы... Хотя те задумки я еще не забыл То, что для их воплощений я пока полный чайник, я отрицать не буду. C++ изучу, как только куплю книжку. Все никак, но как только, так начну испытывать свои идеи. Других прошу не нагружать мозги своими задумками! Я просто решил поделиться мыслью, и больше ничего.

"а щас будет общий" (с) кабан
Э нет, брат, теперь это уже не только твои проблемы. В смысле того, что ты это озвучил, собирай шишки и лавры. На счет изучения С++ не горячись Улыбка

Его изучить нельзя Улыбка

И вообще главное expirience Улыбка

Нет, книжку конечно купи, учи. Но это только начало большого пути imho. Я могу сказать о себе - я не знаю С++ так, как хотел бы его знать. Хочу очень легко ориентироваться во всех design pattern'ах без справочноый литературы, хочу... хочу... Вобщем вот Улыбка

"а язык учи, пригодится" (c) особенности национальной охоты

Всё чем мы тут занимаемся - не более чем теоретика кайфа Улыбка

Нужно брать, и пробовать, решать возникшие проблемы. Главное, чтобы желание не пропало.

Цитата:

А на счет движка своего Blood я могу сказать, что там есть две вещи, требующие напрягание мозга. Во-первых, это заполнение полигонами секторы в форме Г или еще более извращенной (бывают "мастера", делающие всю карту одним извилистым и израненным вкроплениями-выступами сектором), хотя JM, я думаю, знает 9 или 100 способов, как это делать. Но вторая гораздо более сложная - это пересоздание секторов во время игры там, где ездят слайды, ротэйты и патч-секторы. Без этого можно обойтись, если передвигаемый сектор выступает из пола, но если какому-то дураку вздумается накорякать в полу яму (например, в лодке, плывущей по реке, дно ниже, чем уровень воды), то придется делать boolean-вычетания (говорю терминами 3ds max'а), а это, думаю, будет требовать ресурсов. В Полимосте перерасчет делался раз в 3-4 кадра, и меня это жутко взбесило.

С полигонами я думаю проблем не возникнет. Точно говорю. Если бы я собрался и потратил суммарно часов 15, у меня уже был бы готовый простейший рендер Blood уроней. Ну это конечно только слова. Можете воспринимать скептически, можете игнорировать - воля ваша Улыбка

Не нужно никаких вычитай, не усложняй. Я честно говоря не вижу вообще никакой проблемы. Более того, если в Build использовались сектора и порталы (в терминах игростроения, а не телепорт в какую то локацию) для того, чтобы разгрузить рендер и чтобы это всё работало с приличным фпс на тогдашних машинах, то сейчас на видеокарте даже уровня GF2 весь уровень Blood можно отрисовать методом грубой силы без использования каких либо алгоритмов и оптимизаций. Никаких тебе BSP, Octree, ляпота Улыбка

Те или другие могут появиться потом, для оптимизации контроля столкновений. Ну да это уже другая история.

Мои мысли я изложил уже давно - сделаю (если сделаю) гляделку уровней Blood, а дальше будет видно. Из наиболее близких задач для меня - превращение 2d гемоетри уровней в честное 3d и максимальная оптимизация результата (не самая сложная задача), конкертирование текстур и создание т.н. атласов текстур для оптимизации всё того же рендера и минимизации переключения текстур (также не сложная задача, при условии того, что я не буду искать способ создания оптимальных аталасов, при которых переключения текстур на уровнях будет сведено к минимуму. На самом деле такую задачу решить невозможно(если использовать заранее созданные статические атласы, потому что на разных уровнях текстуры в секторах скомбинированы по разному) Решение проблемы - можно создавать оптимальные атласы при загрузке уровня - это не сложно).

Освещение пока менять не собираюсь. Контент вероятнее всего тоже. Я программист а не моделлер. У меня нет возможности создать нормальные качественные модели и текстуры.
Технически поддержку тех же Md2 добавить не проблема. Хотя зачем нам кейфрейм анимация ? "Скелетка" (mdl, md5mesh/md5anim) будет гораздо рациональнее. Тем более есть готовые классы-наработки. Такой вот компот.

Что ж, скажу со всей ответственностью, что я в душе - дизайнер (дизайнего всего вообще). Обращаться с изорражениями и рассчитывать цвета - моя вторая специальность... поддерживаю

В 3ds max я протратил кучу времени в основном на освещения, создания текстур и т.д., так что я в этом, конечно, не спец, но нужное направление найду.

Если я когда-нибудь займусь всем этим (рассчет затенения), то уж точно подойду именно к этому со всеми стараниями... Я не хочу перекроить трудоемкую работу картостроителей, я хочу наоборот улучшить и облегчить им задачу, и ни одно затенение не пропадет даром, все будет на виду, а все тени-свет я подгоню эксперементально. Вообще, я действительно вижу реальную картинку, которую не так уж и сложно получить. Хотя повторюсь, можешь не забивать себе голову этим, это мои замыслы, которые вряд ли кто-то сделает с таким же усердием, что и я (ввиду незаинтересованности в этом Улыбка

). Но если все-таки решишь сделать рендер уровней, пожалуйста, оставь там возможность наложения карт теней (хотя бы ввиде пустых строчек). А уж их рассчетом займусь я когда-нибудь...

Цитата:

Blood всё же не Duke. И не в смысле игры. Архитектурные ньюансы, аи и многое другое.

Какие, например? Если ты имешь ввиду сам движок, то я разницы не заметил, потому как все элементы игры (зеркала, этажи) присутствуют везде. Мне очень интересно.

Цитата:

Нужно брать, и пробовать, решать возникшие проблемы. Главное, чтобы желание не пропало.

Бывало, я и программированием страдал, так что знаю... А рассуждаю я об этом с мыслью "о черт, ну и достанется же мне!" (C)

Цитата:

Точно говорю. Если бы я собрался и потратил суммарно часов 15, у меня уже был бы готовый простейший рендер Blood уроней. Ну это конечно только слова. Можете воспринимать скептически, можете игнорировать - воля ваша

Была когда-то бесплатной прога "Соло на клавиатуре" (печатанье), так вот там говорилось, что занимаясь по 5 часов в день, можно пройти курс за неделю. Мы с братом проходили год... Главное, знать, как делается (мы же с Чармедом все-таки сделали того бота-профессора в редакторе карт - я знал, как это делается, но приступил к созданию месяца через 4, но получилось же?), а то, что готово через полгода (имеется ввиду версия 1.0 без багов), то, считай, готово уже сейчас Улыбка

Последнее уточнение. Я прекрасно знаю, что в Blood поплоскостное освещение, а что в Build есть карты теней - это конечно же полная глупость. Под рассчетом теней в реальном времени я имел ввиду свои навороты... Я замышляю сделать сглаженныое затенение, а при перемещении движущихся/меняющих цвет секторов lightmaps (карт теней на моем языке) придется рассчитывать заново, но ведь рассчет обычно проводится во время загрузки уровня... Есть игрушка, WORMS 3D, там есть возможность разрушения мира, а еще там тени в виде банальных карт. Так вот, при взрыве чего-нибудь, тени перерассчитываются 1 точка за 1 кадр. Это выглядит немножко стремно (хотя многих такое варварство устраивает), так что я и предложил такой подход к движущимся секторам. Все положения можно просчитать при загрузке, а во время игры переключать "снимки" (говорю диллетантским языком, поскольку ни одного оператора не знаю).

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

Мое личное мнение на счет моделей: пока тоже можешь не делать, так как никто еще ничего не сделал, и проверить можно будет разве что на Калебе Трансфужена, Гордоне или на Думе. смех

В этом просто нет смысла (imho), так что не грузи себя. Ах, да! У меня в milkshape до сих пор торчит мой собственный Калеб с числом полигонов где-то 4000 (то есть, можно смело сохранять в md2, если, конечно, я доделаю анимацию). Уж во что это дело сохранить, мне как-то все равно, так что скелетная, покадровая, мне по-фигу...

Хочу рендер!!!

(Добавление)
Кстати, я давно хотел спросить. Растяжение текстур происходит относительно трех точек каждого из полигонов (если разместить координаты полигона, а затем его растянуть, получается растянутая штучка). Так вот, нельзя ли как-нибудь сделать так, чтобы текстура растягивалась относительно четырех вершин прямоугольника (или относительно двух противоположных линий этого четырехугольника)? Я замышлял такую штучку в начале этой темы, как размытые тени реального времени, и то, что меня беспокоило, это то, что для создания границ света-тени требуется градиентное размытие именно на основе четырехугольников (линия свет-тень при размытии должна образовать четырехугольник). Если попробовать соединить два полигона, образовав из них квадрат, и попробовать присвоить правым точкам белый цвет, а левым - черным, то так тоже можно... Но если объект находится под углом по отношению к источнику света, такие линии превращаются в произвольную трапецию (две стороны-границы направлены в направлении буквы "V" друг к другу), то градиентное размытие между этими линиями превращается в букву "Г" (на стыке полигонов). Это смотрится просто ужасно... А можно ли сделать "правильное" размытие в прямоугольнике? (я имею ввиду аппаратно, хотя, если есть возможность сделать это программно без ощутимой траты ресурсов, то скажи, как...) Я имею ввиду, можно или нельзя, и за счет чего? Только, пожалуйста, не надо критиковать это в отношении траты ресурсов, я и сам знаю, что над оптимизацией и урезанием "заетости" такого движка придется посидеть очень и очень долго.