Изучаю DromEd

[Zontik]

Не совсем так. От количества брашей зависит, конечно, но гораздо больше - от корректного их размещения. Движок разбивает всю геометрию на ячейки (те самые cells), причем делает это не самым очевидным образом. (В редакторе есть команды, позволяющие посмотреть это разбиение прямо в игровом режиме - show_сells и еще какая-то, можно поискать в списке команд - последняя даже более удобная, но я ее сейчас не вспомню.) Скажем, так: многогранная призма (цилиндр по классификации DeomEd), уткнувшись "круглой" стороной в плоскость, разбивает эту плоскость, как камень - зеркало. Любые поверхности, состыкованные неровно (не вплотную прилегают сторонами друг к другу) провоцируют кучу мелких, почти невидимых ячеек, которые тем не менее тоже участвуют в итоговом подсчете.
Что с этим делать? Ну, прежде всего - не допускать. Не замахиваться на Lord Alan's Factory c первой попытки. При каждой портализации контролировать количество ячеек (оно показывается в текстовом окне с бегущими строчками среди множества других параметров) и мысленно сопоставлять с количеством уже построенного. Если станет ясно, что ресурсов может не хватить - умерить аппетит, пока не поздно. Предельное количество указано в документации к New Dark.
Ну и традиционное, с чего следовало бы начать - два элементарных совета.
1. Никогда не выключать выравнивание по сетке! Без сетки браши только кажутся расположенными ровно, а на самом деле между сторонами везде будут почти невидимые зазоры и тысячи ненужных ячеек.
На самом деле выравнивание можно и нужно иногда отключать (ненадолго!), но для понимания, как и когда, нужно наработать хороший опыт с включенной сеткой.
2. Строить грамотно. Не пронзать пирамиды цилиндрами. Избегать соединений там, где они не нужны, лучше оставлять небольшие зазоры между брашами там, где игрок не подлезет посмотреть. Не допускать торчащих хвостов (если воткнул цилиндр в куб, смотри, чтобы он не коснулся противоположной стенки: визуально разницы не будет, а число ячеек внезапно возрастет). Если колонна стоит возле стены - лучше ей не прикасаться к этой стене, если это не принципиально с архитектурной точки зрения. Мелкую детализацию оставить на потом, и если на этом последнем этапе ресурсов не хватит - выполнять ее объектами.
Ну и на всякий случай 3. Использование мультибрашей, особенно масштабных, почти всегда приводит к критическому возрастанию числа ячеек, так как очень часто при их использовании выравнивание по сетке слетает, а отследить эти ошибки потом почти нереально. Лучше не использовать их вообще, а если уж без них никак - обязательно предохраняться: сохранение в отдельный файл, проверка выравнивания до и после, сравнение количества ячеек до и после, и если хоть что-то пошло не так - немедленный откат к прежней версии. Пожалей свои время и нервы.
А, ну да, забыл самое очевидное. Размер сетки меньше 12 не используй вообще, а лучше удерживаться в рамках 13. Если не выставляется браш - переключись на 12, выставь его, затем немедленно вернись к 13. Это гарантирует, что потенциально проблемный браш у тебя будет только один этот, а не все последующие. В самом трудном случае можно просто выставить координаты вручную, и это даже лучше, чем выравнивать по сетке, но не дай бог включить потом такую вручную выставленную координату в мультибраш.
Думаю, этого тебе пока хватит.
Если же успел словить ошибку и уровень уничтожать жалко - используй команду, подсвечивающую браши, которые не выравнены по сетке. Команду не помню, к сожалению, но чтобы найти ее в общем списке команд, хороший английский не нужен. Проверяется при этом соответствие размеру сетки, выставленному на момент запуска команды. "Неправильные" браши загоняй на место. Еще один ресурс - уменьшение количества сторон цилиндров и пирамид. Где было 16, сделай 10. Разница будет потрясающая. Если все это не поможет - тогда только радикальное сокращение карты.

[Force]

Тут стоит сказать, что Zontik в основном говорил про полигоны - минимальные единицы отрисовки, из которых состоит геометрия. Чаще всего это треугольники, но иногда они могут быть и четырёх-, пяти- и т.д.-угольными. Главное правило их формирования - то что они являются выпуклыми геометрическими фигурами. Треугольники выпуклые всегда, поэтому их чаще всего и используют для отрисовки. При помощи треугольников можно визуально представить геометрию любой сложности, всё зависит лишь от их количества . Надо сказать, что в Thief полигоны всё-таки чаще являются четырёхугольными.

А вот ячейки - cells - это множество полигонов, образующих выпуклый же объем. Иными словами, упрощенно, твой уровень разбивается на полигоны до тех пор, пока эти полигоны не сформируют группы выпуклых объемов, которые потом используются движком для отрисовки и отсечения невидимых частей уровня. Почитай в инете общие статьи на тему формирования bsp-деревьев для уровней. Не обязательно понимать всё досконально, хотя бы самое главное - это даст серьезный профит в качественном улучшении твоих трудов.

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

[Zontik]

Точно! Полигоны! Сразу же вспомнил ту вторую команду - show_poly или что-то очень похожее.
Но большой ошибки тут нет, ибо экономишь полигоны - меньше становится ячеек. К тому же разбиение на полигоны худо-бедно можно себе представить и даже порой предсказать, а вот с ячейками... нужно знать намного больше.
Хотя и это не будет лишним, потому что именно на основе ячеек формируются маршруты передвижения AI и система видимости тумана. Но тут у меня, увы, пробел в образовании. Методику объединения полигонов в ячейки я понимаю очень поверхностно.

[Force]

Методику объединения полигонов в ячейки я понимаю очень поверхностно.

Выпуклый объем - это такой объем, все полигоны которого могут быть видны из любой его точки. Иными словами - пустой куб/параллелепипед/сфера - это выпуклый объем. Но стоит в таком кубе поставить колонну посередине - он становится невыпуклым и требует разбиения на части - ячейки (cells), чтобы соблюдалось вышеописанное правило.

Теоретически любая ниша, неровность в стене, формирует как минимум одну дополнительную ячейку. Если геометрия слишком сложна и формируется множество выпуклых объемов, будет формироваться не одна, а целая куча ячеек. Ещё мне не известно про ограничения на размеры самих ячеек в Thief. Может статься так, что слишком большие ячейки разбиваются на более мелкие и ещё по каким-то критериям.

Кстати, поправка. Сейчас проверил команда для показа ячеек:
show_cell - показывает полигоны из которых состоят ячейки; окрашенные одним цветом полигоны принадлежат одной ячейке.
команда для показа полигонов:
show_poly

[Zontik]

Force, я так понял, субтрактивная геометрия здесь в приоритете? Потому что если у нас твердый куб, висящий в воздухе, а внутри у него воздушная колонна - тут я с трудом понимаю, что в данном случае считать объемом. Или тут два объема (не считая еще воздушного, в котором висит этот куб)?
Когда объем воздушный внутри твердого тела - тут все как-то умозрительно. А когда наоборот?

[Danielol]

Это исчерпывающие ответы. Спасибо Вам всем большое! Просто я был удивлён, когда почти достроил достаточно интересный и детализированный (в своём воображении) уровень почти наполовину и узнал об ограничении жёцким путём :-) Не мог долго понять какой тогда смысл давать в редакторе такое огромное пространство при такой малом запасе ресурсов. А можно поподробнее о некотором трюке с параметром time для экономии cells, если вам не трудно? Или ещё вопрос : а движок от дума, на котором пилят сейчас миссии более объемный в этом плане? Мне интересно создавать разную необычную и детальную архитектуру уровней. Такие отграничения обескураживают...

[Force]

Zontik

Force, я так понял, субтрактивная геометрия здесь в приоритете?

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

Когда объем воздушный внутри твердого тела - тут все как-то умозрительно. А когда наоборот?

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


Danielol

Мне интересно создавать разную необычную и детальную архитектуру уровней. Такие отграничения обескураживают...

Если прям чтобы совсем почти без ограничений, то можно взять UE5, включить там Nanite и лепить столько сколько вздумается, ограничиваясь только местом на жестком диске.

Но, по-чесноку, настоящая крутизна появляется только когда ограничения есть, любые, не обязательно технические. Так что могу посоветовать изучить соответствующую "матчасть". С другой стороны, если работа делается только "в стол", то можно и не изучать, а тыркаться, пока не надоест, чтобы забросить потом.

[Danielol]

Спасибо. А не укажете ли на годный гайд по созданию объектов из Дромеды (Export world rep). Гайд на ttlg ведет в пустоту. http://www.ricebug.net/Tutorials/Exporting.html  - ссылка мертва.
https://www.ttlg.com/forums/showthread.php?t=140162 - ссылки в теме мертвы. Хотелось бы упаковать перилы (и некоторые другие браши) объект для экономии ресурсов.
Да, я застрял. Я мог только открыть в Anim8tor дверной проем ( air brush, снаружи solid brush)и это показалось победой, но больше я прямо ничего не смог открыть, нужен подробный гайд, хелп гайз. Convert World Rep to Model (Using New Dark's Terrain Export Feature) by Jason Otto - Вот типо этого гайда я искал если подробнее.

[Zontik]

понадобится минимум шесть ячеек для каждой грани этого куба с каждой внешней стороны

А разве по углам/ребрам ячейки могут не образовываться? Я так понимаю, что шесть никак не минимум, у меня получается 18 (шесть ограничивающих по граням и 12 по ребрам между этими ограничителями). Но даже если смотреть в плане, все равно там 8 ячеек, не считая центральной.
Где я ошибаюсь?

настоящая крутизна появляется только когда ограничения есть

Абсолютно верно!

А можно поподробнее о некотором трюке с параметром time для экономии cells

Time - это индикатор порядкового номера браша. Допустим у нас есть воздушный куб с твердой колонной внутри, как на примере выше. Сначала строится куб (time=1), затем колонна (time=2). Если затем поменять эти параметры местами - 1 присвоить колонне, а 2 - кубу, то после портализации колонны в 3D-мире не будет - ее растворит куб, появившийся позже.
Без понятия, как это можно использовать для экономии. Могу только предположить, что в случае соприкасающихся поверхностей деление на ячейки может происходить чуточку по-разному в зависимости от порядка появления этих поверхностей. Но вряд ли эта экономия может оказаться существенной.

А не укажете ли на годный гайд по созданию объектов из Дромед

Не уверен, что такой вообще существует. Я пользовался этим ного раз, правда, давно, и, по-моему, все там достаточно очевидно. Ну или почти все.
Во-первых, желаемое место надо выделить брашем типа Area, нажать кнопку Me Only и портализировать.
Во-вторых, это место должно быть со всех сторон окружено воздухом. То есть если экспортируешь "дверной проем" (зачем? Это же просто дыра!)Ю стены вокруг не должны мешать.
Ты можешь экпортировать, к примеру, кирпич, но при этом он не должен лежать на полу. Пол придется убрать или приподнять кирпич, иначе поверхность, по которой они соприкасаются, не будет принадлежать исключительно кирпичу после экспорта. Скорее всего, будет просто большая плоскость, выступающая за пределы кирпича и ограниченная стенками Area.
Ну и третье. Надо понять, что после экспорта в тот же Анимэйтор в любом случае экспортируются границы Area (внешние границы экспортируемой области). То есть перед тобой будет просто большой, разбитый на части полигонами, параллелепипед. А то, что тебе действительно требуется, расположено у него внутри. Внешние стенки придется удалять вручную.
Четвертое идет бонусом. Разбиение на полигоны может оказаться совершенно изуверским, иногда это можно поправить, но не всегда стоит тратить на это время.
Вопросы текстурирования не затрагиваю, там тоже были какие-то подводные камни, но если имена текстур корректные (в формате 8.3 без кириллицы и пробелов) и все они находятся в нужных местах - ничего не слетает. Ты же ведь помнишь, что Анимэйтор глотает далеко не все графические форматы? Как и Дромед. Поэтому нужно искать точку пересечения.
Последнее.
Простые объекты вроде перил проще сделать в том же Анимэйторе с нуля, чем мудохаться с многократным экспортом, а в финале еще намучаться с позиционированием готового объекта на уровне. И получится это на порядок изящнее.

[Danielol]

понадобится минимум шесть ячеек для каждой грани этого куба с каждой внешней стороны

А разве по углам/ребрам ячейки могут не образовываться? Я так понимаю, что шесть никак не минимум, у меня получается 18 (шесть ограничивающих по граням и 12 по ребрам между этими ограничителями). Но даже если смотреть в плане, все равно там 8 ячеек, не считая центральной.
Где я ошибаюсь?

настоящая крутизна появляется только когда ограничения есть

Абсолютно верно!

А можно поподробнее о некотором трюке с параметром time для экономии cells

Time - это индикатор порядкового номера браша. Допустим у нас есть воздушный куб с твердой колонной внутри, как на примере выше. Сначала строится куб (time=1), затем колонна (time=2). Если затем поменять эти параметры местами - 1 присвоить колонне, а 2 - кубу, то после портализации колонны в 3D-мире не будет - ее растворит куб, появившийся позже.
Без понятия, как это можно использовать для экономии. Могу только предположить, что в случае соприкасающихся поверхностей деление на ячейки может происходить чуточку по-разному в зависимости от порядка появления этих поверхностей. Но вряд ли эта экономия может оказаться существенной.

А не укажете ли на годный гайд по созданию объектов из Дромед

Не уверен, что такой вообще существует. Я пользовался этим ного раз, правда, давно, и, по-моему, все там достаточно очевидно. Ну или почти все.
Во-первых, желаемое место надо выделить брашем типа Area, нажать кнопку Me Only и портализировать.
Во-вторых, это место должно быть со всех сторон окружено воздухом. То есть если экспортируешь "дверной проем" (зачем? Это же просто дыра!)Ю стены вокруг не должны мешать.
Ты можешь экпортировать, к примеру, кирпич, но при этом он не должен лежать на полу. Пол придется убрать или приподнять кирпич, иначе поверхность, по которой они соприкасаются, не будет принадлежать исключительно кирпичу после экспорта. Скорее всего, будет просто большая плоскость, выступающая за пределы кирпича и ограниченная стенками Area.
Ну и третье. Надо понять, что после экспорта в тот же Анимэйтор в любом случае экспортируются границы Area (внешние границы экспортируемой области). То есть перед тобой будет просто большой, разбитый на части полигонами, параллелепипед. А то, что тебе действительно требуется, расположено у него внутри. Внешние стенки придется удалять вручную.
Четвертое идет бонусом. Разбиение на полигоны может оказаться совершенно изуверским, иногда это можно поправить, но не всегда стоит тратить на это время.
Вопросы текстурирования не затрагиваю, там тоже были какие-то подводные камни, но если имена текстур корректные (в формате 8.3 без кириллицы и пробелов) и все они находятся в нужных местах - ничего не слетает. Ты же ведь помнишь, что Анимэйтор глотает далеко не все графические форматы? Как и Дромед. Поэтому нужно искать точку пересечения.
Последнее.
Простые объекты вроде перил проще сделать в том же Анимэйторе с нуля, чем мудохаться с многократным экспортом, а в финале еще намучаться с позиционированием готового объекта на уровне. И получится это на порядок изящнее.

Да, у меня всё получилось, правда один раз перед сном. Я сделал следующее:
-Создал перила в дромеде
-Экспортировал в .obj (появился mtl и obj.)
-Открыл Anim8tor и экспортировал то что сохранилось Дромедой.
-Очистил от лишних точек.
-Конвертировал в 3.ds (пока не трогал текстуры)
-В папке Tools (Thief 2) Создал батник, конвертирующий 3ds в .e
"C:\Games\Thief2\Tools\3ds to bin\3ds\Workshop\N3ds2e" 123.3ds
Pause
"C:\Games\Thief2\Tools\3ds to bin\3ds\Workshop\bsp" 123.e - как рекомендовал в своем мини гайде один наш товарищь.
-Вот следующий пункт я сделал один раз, как то удачно написав правильный exe-шник перед сном, а потом забыл и файл переписал неудачно. В общем подскажите команду как конвертировать из .е в .bin - Вообще из головы вылетело. Какие правильно вписать хоть убей не помню.
-Но продолжим. Используя гайд по добавлению своих предметов в Дромеду:

Спойлер

"1. Create a Obj folder within your Thief 2 main directory
2. Create a txt and txt16 folder within the Obj folder you created
3. Place the bin file in the Obj folder
4. Place the gif or pcx file for the object in the txt16 and/or txt folder within the obj folder
5. Open DromEd
6. Open the Object Hierachry
7. Expand physical heading
8. Locate what group this new item would be considered, IE adding a new chair you'd expand physical(-7)/furniture(-10)/chair(-17)
9. With the heading highlighted in this case chair, click Add
10. Type in the name of the new object and click Ok, this will create a new object under the chair(-17) main grouping
11. Open the properties for your new object (double click).
12. Add-Shape-Model Name = type in the name of the bin file you added to the obj folder without the file extension. IE newchair.bin you'd type newchair
13. Click OK
14. Create new object as you would a standard object in game. Some adjusting might be needed to make the object look the way you want it, size and such.
15. Once the new object is added to your Object Hierarchy you'll need to save your modified gam file.
16. Goto to File then to Save Gamesys and save your new gamesys file. MyGam.gam as an example.
17. Now set your FM to use your custom gam by typeing the following in the command window
'set_gamesys MyGam.gam' then enter
you'll notice that Dark.gam has changed to MyGam.gam at the buttom of the DromEd window.
18. Save you mis file as normal.
19. I'd suggest saving mis files in an order in case a modification doesn't work the way you want it. You can always go back to a previous save. miss1_1-miss1_2-miss1_3 and so on."

[свернуть]

И у меня получилось. Но мои перила (её видимая модель) находится дальше её фактического физического (как бы это сказать) тела. То есть то что не обойти в одном месте, а её визуально видимый образ кагбэ правее и выше, чтоли. Я помню что ты (а может а не ты)писал о том что можно как то манипулировать свойствами скелета модели, чтобы поставить её на место. Хотя может и нет. .
-Далее текстуры. Тут я поргорел. Для миссии я брал текстуры в формате dds. Anim8tor их не использует. Поэтому мои перила просто ярко-белые без всего. (в аниматоре их тоже не видно) Может быть если бы я создал перила в Дромеде и присвоил им текстуры формата .gif то информация, записанная в файлы obj и mtl при экспортировании из Жромеды была бы корректно схавана Anim8tor.
Я по-маленьку двигаюсь вперед и решаю какие-то задачи, но сейчас вся принципиально новая информация из каши затвердела до тупика, и мне не помешала бы помощь, а именно:
1) Подскажите пожалуйста вторую команду по конвертации из .е в .bin Желательно с примером, потому что я тупой и "не програмист" )
2) Ну с текстурами я разберусь, попробую разные форматы текстур и разные текстуры впринципе. Потому что в гайде wr-export_obj.doc у парня прошло всё идеально. И у него там нормальные хорошие текстуры. (Он там домики показывал как конфертировать из Дромеды и обратно)  Я явно не там держу текстуры и не того формата. А что mtl файл? Для чего он?
3) Подскажите, почему у меня готовый объект находится в состоянии, когда его визуальная часть в одном месте, а физическая невидамая в другом, чозафихня....

п.с
Сделал таки перила сам, получилось без лишних шальных точек на объекте. Столкнулся с тем что объект не хочет употреблять .dds текстуры, переименованные в .gif, видимо я не такой хитрый как думал Продолжаем пытки )

[Danielol]

Update
Я таки разобрался со всеми пунктами, которые меня беспокоили в предидущем посте. Остался один вопрос. Всё конвертируется, все текстуры где надо и т.п
Почему у меня рисунок объекта в одном месте, а в его "скелет" в дргуом (но рядом)? Я думал это от того что я размещаю объекты не в тех разделах иерархии и его модель просто не подходит к тем типам объектов в иерархии, свойства которых он получает. Но нет, если я засуну объет в перила или в окна - без разницы. Видимая часть в одном месте, невидимая в другом.
Я снова что-то пропустил...?


update
Проблема решена, я нашел заметку http://web.archive.org/web/20071030160559/http://www.thief-thecircle.com/dromed/displaysubject.asp?titleID=64&title=Importing%20Custom%20Objects&sub=Objects
"Objects Off-centre?

If when you import things into thief, they actual graphics seems to be off centre from the object box then this means that your 3ds model was not centred properly. I have just worked this out, and have gone through and re-addressed all my files.

To fix this, in 3d-studio, group the objects, and then right click on the move icon. This should pop up a dialogue box, in it, change the co-ordinates to 0,0,0. Then export, and bsp as normal. De-dah, no more off centre things."
Теперь и куб и его текстурка где надо.

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

[Zontik]

По-моему, команда должна выглядеть примерно так:
bsp model.e model.bin
Это необходимый минимум, знающие товарищи советуют еще добавлять какие-то параметры для лучшего распределения света на модели, и в принципе описание этих параметров (довольно скудное) имеется в самом bsp.exe (если запустить ее без параметров или со специальным параметром на запрос помощи: -help или что-то вроде того).

И у меня получилось. Но мои перила (её видимая модель) находится дальше её фактического физического (как бы это сказать) тела.

Решения:
Вариант 1. Прямо в Анимэйторе сместить начало координат в центр модели. Сейчас он, по всей видимости, где-то далеко.
Вариант 2. Отредактировать физические свойства модели в Дромеде: свойство Physics > Model. Там есть не только размеры, но и смещение. Вот последним и пользуйся. В помощь - специальный пункт в меню Дромеда, позволяющий отобразить контуры физической модели на экране.
И отмечу также, что всякие косые объекты типа перил очень невыгодно делать на стороне. Потом по таким перилам съехать уже не получится, поскольку физ. модель будет четко обозначенным параллелепипедом, и нижний край перил физически окажется точно на той же высоте, что и верхний. Или модель надо заранее разворачивать в 3D-редакторе под нужный угол, а потом ставить ее наискосок. Я так делал однажды, больше не хочу.

Далее текстуры. Тут я погорел.

Промежуточный файл в формате *.е - на самом деле обычный текстовый, так что ты можешь просто на промежуточном этапе поменять расширения на желаемые.
Можно поменять их даже в OBJ, yо это уже только в HEX-редакторе.
Ну и понятно, что файлы в соответствующем формате также должны быть в наличии.

Столкнулся с тем что объект не хочет употреблять .dds текстуры, переименованные в .gif

Надо же, оказывается, изменение расширения не превращает текстовый файл в фотографию?! Добро пожаловать в реальный мир.
Про MTL точно не помню, но это точно такой же текстовый файл с описанием материалов. Возможно, расширения можно поменять и там. То есть необходимости менять формат файлов в самом Дромеде, по сути, нет.
Немного запоздал с советами, но, может, они помогут внести окончательную ясность.

[Force]

Zontik

А разве по углам/ребрам ячейки могут не образовываться?

Зачем, если можно просто расположить их "внахлёст"?

[Zontik]

То есть отдельно "уголки", отмеченные у тебя на рисунке, образовываться не должны - они пристыковываются к одной из соседних ячеек?
Логично. А в DromEd это именно так и работает?

[Force]

Zontik

То есть отдельно "уголки", отмеченные у тебя на рисунке, образовываться не должны - они пристыковываются к одной из соседних ячеек?

Ну, они не пристыковываются, процесс обычно идет в обратном направлении: геометрия разбивается до тех пор, пока не останутся только выпуклые объемы. А рисунок - да, некорректный в этом плане.

А в DromEd это именно так и работает?

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