Sidebar

Новые компиляторы уровней для Quake3

  • Наступило лето и у нас стартовал конкурс с призовым фондом в $120!
    "De-Make It!" Summer Contest.

Делаете ли вы карты для Quake3

  • Да, делаю

    Голосов: 3 17.6%
  • Нет, Quake3 меня никогда не интерисовал

    Голосов: 14 82.4%

  • Количество людей, принявших участие в опросе
    17
Команда форума
VIP
28.03.2010
15 328
253
83
Награды
4
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
Новые компиляторы уровней для Quake3

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

Slux

Administrator
Команда форума
Администратор
20.06.2006
5 890
114
63
Награды
3
32
/dev/tty0
wiki.csm.dev
  • Золотая медаль 311
  • Tux
  • Серебряная медаль 311
Почему нету пункта "Хотелось бы попробовать"? А то меня вот ку3 как-то и интересует, но я не делаю под него карты. Когда-то делал что-то под Nexuiz, если это считается.
 

xDShot

Well-known member
20.12.2010
1 836
47
48
Награды
0
Санкт-Петербург
Дядя Миша сказал(а):
в q3map2 никто и не пытался разобраться, я тут с краю копнул - ёпте...
Аргументировано

[ADDED=xDShot]1547684738[/ADDED]
https://github.com/TTimo/GtkRadiant вот там кстати ведется разработка q3map2 компилятора (слились с проектом GtkRadiant). Можно им туда предложить изменения :drink:
 
Последнее редактирование:

Cybermax

Супер Модератор
Команда форума
Супер Модератор
11.03.2008
2 590
28
48
Награды
0
Раньше когда карту делал под ХЛ заодно версию под Nexuiz собирал. Если справлюсь с прокрастинацией, то продолжу эту порочную практику.
 

crystallize

Active member
06.06.2014
1 505
21
38
Награды
0
Делал под Q3 ещё в 2004 в UberRadiant (кстати где он) но не нашёл в списке энтитей info_player_start и бросил. :)
 
Команда форума
VIP
28.03.2010
15 328
253
83
Награды
4
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
Вообще говоря, существует ненулевая вероятность, что я их недоделаю, если решу свою задачку раньше. В ку3 много несуразностей, в частности вот браши эти там ни к селу ни к городу. Потом эти сурфейсы, которые могут оказаться чем угодно, как планаром, так и целой моделькой на пол-уровня. Ку3 вообще писался в очень большой спешке там очень многое недоделано. Прямо как на советском заводе в конце месяца :)
 
Команда форума
VIP
28.03.2010
15 328
253
83
Награды
4
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
2 nemyax: коллизия по брашам весьма ненадёжна, я уже рассказывал.
Игрок норовит в них застрять.
 
Команда форума
VIP
28.03.2010
15 328
253
83
Награды
4
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
2 nemyax: у где-то в этой теме. Да ты не ленись, перечитай всю. Я её сам иногда с удовоольствием перечитываю. Хорошая тема.

[ADDED=Дядя Миша]1547834276[/ADDED]
Вообщем есть у меня такое предположение. Что халфовский BSP уже изначально готов к полоноценной колоизации, ака Doom3. Причём оно там даже оптимальнее, чем в Doom3. Причём любая карта годится изначально. Если это подтвердится экспериментально, то смысл в разработке полностью отпадёт.
 
Последнее редактирование:

Qwertyus

Well-known member
13.08.2009
1 363
26
48
Награды
1
  • Xash медаль
2 Дядя Миша:
А что это даст по сравнению с тем, что есть сейчас?
 

nemyax

тндайпц тра
Команда форума
Модератор
30.07.2015
643
24
18
Награды
0
Колоизацию мешей путём их бспефикации?
 

GNU/Hurt

Maïté
05.03.2014
1 092
23
38
Награды
0
2 Дядя Миша:
>полоноценной колоизации, ака Doom3
Оно не будет строить клипхуллы часами? А то я когда каньон из треугольных брашей компилил, даже отрубил нахрен колоизацию что бы меньше ждать.
 
Команда форума
VIP
28.03.2010
15 328
253
83
Награды
4
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
q3map2. Фрагменты прекрасного
Код:
				qboolean ext;


				/* ydnar: extended sun directive? */
				if ( !Q_stricmp( token, "q3map_sunext" ) ) {
					ext = qtrue;
				}
я сперва даже не понял что мне так глаз резануло. В актуальном SVN тоже самое. Ну да, может мелочь, но сколько еще там таких мелочей.
 

nemyax

тндайпц тра
Команда форума
Модератор
30.07.2015
643
24
18
Награды
0
Как говорят православные, либо восклицательный сними, либо qfalse надень.
 

Ayk

Member
15.09.2012
195
11
18
Награды
0
Оффтоп
 

nemyax

тндайпц тра
Команда форума
Модератор
30.07.2015
643
24
18
Награды
0
Оффтоп
 
Команда форума
VIP
28.03.2010
15 328
253
83
Награды
4
Кубань
  • Золотая медаль 215
  • Серебряная медаль 214
  • Золотая медаль 221
  • Cat
Я пока отложил разработку непосредственно компиляторов, но темы в любом случае близкие, поэтому писать буду сюда. Очевидно основная задача - разобраться в том, что в форматах перспективное, а что можно смело выбросить на свалку истории. Парадокс в том, что некоторые вещи, появившиеся уже во второй кваке, к третьему дууму уже выбросили, как ошибочные, а некоторые - вернули обратно. Так например, третий дуум не колоизирует с брашами. Почему - я уже писал, нормальной коллизии по брашам невозможно получить в принципе из-за неопределённости порядка обхода сторон. В случае с трейсом по плоскости дерева это условие соблюдалось автоматически. Для брашей нам бы пришлось каждый раз сортировать стороны брашей при обходе трассы с разных сторон, что дополнительно бы замедлило и так весьма небыструю трассу. То есть смысла в этом никакого. Единственное взаимодействие дуум3 с брашами - это поинт-контентсы. Да и то лишь потому, что дуум по быстрому строит аксиальное BSP дерево, которое ничего не режет, а старается подобрать плоскости таким образом, чтобы ничего резать и не пришлось. Причина тоже очевидно - дерево строится в момент загрузки карты (один раз), и долго ждать построения утомительно, там же претензия на почти реалтайм-редактирование. Поэтому оно там не слишком оптимальное. Ну в любом случае быстрее линейного перебора, конечно. Для рендер-моделей тоже строятся маленькие аксиальные деревца по тому же принципу. Таким образом потребность в сохранении брашей отпадает полностью - поинт-контентсы у нас и так уже есть и с ними нет никаких проблем. Второе условие - полигонам нужны рёбра и их индексация (сурфэджы), чтобы определить какому из двух полигонов принадлежит данное ребро. Копии там делать крайне нежелательно, ведь в общее ребро пишется информация кэша, чтобы не проверять его дважды. И - это тоже у нас есть в наилучшем виде. Рёбра и их индексы, которые вообще-то использовались для софтварного рендерера. А теперь они пригодятся для физики. Так же у ребра допускается не более двух полигонов, но это всегда соблюдалось автоматически. Довольно большая часть кода в том же дууме отвечает за то, чтобы сконвертировать патчи или тримешы в полигоны, найти их внутренние рёбра и как-то их пометить. Я у себя решил эту задачку более удобным способом - я не рассматриваю патчи и тримешы как отдельный класс объектов. Я просто конвертирую их полигоны в несолидные брашы, у которых CSG потом просто выкидывает пять сторон, оставляя только нужную. Таким образом на вход BSP они уже попадают среди обычных полигонов и ничем для него не отличаются. У них точно так же есть своя плоскость, как и у обычных планарных фейсов. Единственное но - пожалуй к таким объектам неплохо бы иметь уникальный идентификатор, по которому их можно будет в дальнейшем сгруппировать в единый меш, например для VBO. Но это тоже решается элементарно - через groupid в моём расширении формата. Собственно для того и создавался. Таким образом для полигональной колоизации в формате HLBSP уже присутсвует весь необходимый набор данных. Разве что рёбрам надо построить нормали, это быстро и делается при загрузке карты. В качестве основного дерева для поиска полигонов мы будем использовать видимый хулл, а клипноды просто выбросим на свалку истории. Правда вместе с клипнодами исчезнут и клип-брашы. Их можно будет перенаправить в видимый хулл с texinfo == -1, например. Клипы это в любом случае детальные брашы, как вы понимаете.
Ну и наконец последний, неочевидный момент, который позволит выкинуть половину китайского кода - детальные фейсы надо отфильтровать в лиф, а не класть их на фейковую ноду для совместимости с голдсорсом. Потому что детальные брашы в китайском варианте способствуют разбуханию дерева, с чем китаец боролся чисто китайскими методами - написал функцию его оптимального построения, которая сама по себе строит весьма небольшие деревья. Но его мотивация понятна - если бы он спустил детайлы в лиф, как это когда-то пытался сделать автор ZHLT, то они бы просто не рисовались, или в лучшем случае - не коллидили.

[ADDED=Дядя Миша]1548420255[/ADDED]
ЗЫ. наверняка у многих возник вопрос, почему это коллизия с брашем - ненадёжная, а коллизия с полигонами из этого браша - надёжная. Потому что браш рассматривается именно как набор плоскостей и коллизия происходит с ними. Это быстро, но из-за неопределённости порядка сторон на три стороны браша у нас всегда приходится точная коллизия, а еще на три стороны - застревание в пределах эпсилона. Для борьбы с этим явлением в коде физики ку2 и ку3 ввели так называмый OVERCLIP. Внешне это проявляется так - вы не сможете прижаться даже к аксиальной стене, вас всё равно от нее оттолкнёт. Поэтому в том же ку3 можно "идти на месте", уперевшись в стенку. А от более сложных конструкций типа тех же тримешей, игрока вообще отталкивает аки мячик, что создаёт иллюзию "динамичности" физики :)
 
Последнее редактирование:
  • Like
Reactions: [email protected]

Донат - Операционные расходы

Итого
1 171.00 $
Цель
1 300.00 $
Донат завершается:

Доноры Красавчики

Новые сообщения

Пользователи онлайн

Нет пользователей онлайн.