-
Программа-просмотрщик ресурсов движка Dark Engine.
Не требует установки и предварительной настройки. Может размещаться в любом удобном месте системы. Поддерживает OpenGL 3.2 (есть режим совместимости с OpenGL 2.1), а значит, может работать даже на старых компьютерах, на системах Windows и Linux.
(http://forcesw.com/static/files/556/599/158491990599556.jpg) (http://forcesw.com/static/files/440/087/158491990087440.jpg) (http://forcesw.com/static/files/488/066/158491990066488.jpg) (http://forcesw.com/static/files/327/160/158491990160327.jpg) (http://forcesw.com/static/files/722/218/158491990218722.jpg) (http://forcesw.com/static/files/561/270/158491990270561.jpg) (http://forcesw.com/static/files/966/391/158491990391966.jpg) (http://forcesw.com/static/files/841/462/158491990462841.jpg)
Где скачать
Ссылки на скачивание всегда будут доступны:
— на моём сайте forcesw.com (http://forcesw.com/rus)
— в этой теме форума
— на форуме TTLG (https://www.ttlg.com/forums/showthread.php?t=150408) (eng)
Актуальная сборка:
Thief 2: The Metal Age 20th Anniversary build (http://forcesw.com/deviewer_thief2_20th_anniversary.zip) 2020‒03−28 13:00 MSK (UTC+3:00)
Неактуальные сборки:
Thief: The Dark Project 21th Anniversary build (http://forcesw.com/deviewer_thief_21th_anniversary.zip) 2019‒11−30 23:55 MSK (UTC+3:00)
Thief: The Dark Project 20th Anniversary build (http://forcesw.com/deviewer_thief_20th_anniversary.zip) 2018‒11−30 12:58 MSK (UTC+3:00)
Последние изменения
2020‒03−28 13:00 MSK (UTC+3:00) Thief 2: The Metal Age 20th Anniversary Build
+ улучшен механизм определения каталогов с ресурсами игры. Теперь миссия, расположенная внутри любой директории игры, легко находит путь к ресурсам.
+ улучшен механизм поиска текстур для моделей. Добавлена поддержка вложенных каталогов по названию языка (правда, пока ищется только "english").
+ добавлена поддержка замещаемых текстур, описываемых параметром TxtRepl r*, где * - номер текстуры [0, 3].
+ увеличен максимальный лимит экспозиции (для повышения яркости клавишами + и -).
+ теперь в миссиях Thief 1 отображаются высокополигональные модели (при наличии).
+ добавлена поддержка открытия программы в нужном каталоге через передачу параметра в командной строке или перетаскиванием каталога на окно программы.
2020‒03−23 01:50 MSK (UTC+3:00) Thief 2: The Metal Age 20th Anniversary Build
+ добавлено отображение моделей персонажей (выражается благодарность Juliusz Kaczmarek aka PinkDot и Randy Sybel aka Shadowspawn).
+ затухание в шейдере переключено на квадратичное. Теперь свет затухает по законам физики, но от этого стало темнее.
+ клавишами "+" и "-" теперь можно менять яркость изображения в режиме свободной камеры.
+ исправлено наследование свойств объектной иерархии.
2020-03-06 14:00 MSK
+ уменьшен радиус SSAO и соответственно, bent normals. Последние теперь включены в финальную картинку, отчего она выглядит немного зашумленной. Отключить вклад SSAO и bent normals можно клавишей k.
+ увеличено значение FOV c 50 до ~74 градусов по вертикали, что соответствует FOV New Dark Engine.
+ переработано взаимодействие с объетной иерархией. Считываются свойства Render Type и Self Illumination, это позволило не рисовать лишние объекты миссии и исправило отображение теней от светильников.
+ исправлено смещение полигонов для обратного буфера глубины. Это предотвращает мельтешение теней (артефакты) при повороте или перемещении камеры.
2020-02-26 20:00 MSK
+ добавлена поддержка миссий формата New Dark Engine! Ура! Особая благодарность выражается Juliusz Kaczmarek aka PinkDot!
+ незначительно ускорена загрузка миссий
+ при открытии миссии, камера позиционируется в стартовой позиции
+ класс цвета переделан на хранение данных в векторе с плавающей точкой, это обеспечивает лучшую точность
+ отключено "залипание клавиш", для предотвращения накопления смещений камеры при управлении интерфейсом
+ увеличена яркость режима просмотра миссий
2020-02-17 23:00 MSK
+ добавлена поддержка цветных полигонов в моделях
+ исправлено отсечение пути к текстурам, находящимся в одном подкаталоге с открытой моделью (информация о текстурах, отображаемая на экране)
+ различные внутренние оптимизации
2020-02-05 23:30 MSK
+ исправлено отображение некоторых проблемных моделей, состоящих из нескольких костей
2020-01-14 15:00 MSK
+ исправлено отображение уровней на видеокартах AMD
+ отрефакторен рекурсивный обход BSP-дерева при открытии моделей, убрана рекурсия
+ исправлено падение программы при открытии некоторых старых или поврежденных моделей
+ откорректирована простановка доступных для выборки mipmap-уровней текстур
+ добавлена отладочная схема отрисовки
2020-01-04 00:55 MSK
+ исправлена ошибка вращения объекта сразу после его открытия, без предварительного движения мышью
+ исправлена ориентация некоторых объектов в миссиях, связанная с особенностью указания ориентации кватернионов в библиотеке GLM
+ исправлено построение AABB и OBB для объектов и их костей
+ шейдеры теперь умеют принимать на вход массивы данных
+ добавлена заготовка схемы отрисовки для дебажного вывода bounding boxes
2019-12-18 23:30 MSK
+ пути к ресурсам игры удаляются из программы, если мы выходим из каталога игры (чтобы ресурсы разных игр не перемешивались при загрузке)
+ исправлено падение программы при клике или скролле на странице ошибки при первом запуске
+ окно программы при запуске располагается по центру экрана
+ исправлено поведение клавиши PgUp, перематывающей список в самый конец, при нажатии в верхней части списка
2019-12-11 16:00 MSK
+ исправлена ошибка компиляции шейдера depth_tree на картах AMD
+ расширено логирование при ошибках поиска текстур для упрощения анализа логов
2019-12-10 15:00 MSK
+ исправлена распаковка нормалей моделей, теперь все объекты корректно освещаются источниками света
2019-12-06 15:00 MSK
+ закрытие дескриптора архива после выхода из него средствами интерфейса
Как запускать
Простой способ: запустить из папки, в которую была распакована программа, и при помощи интерфейса открыть каталог с нужным файлом модели или миссии на диске.
Продвинутый способ: программа принимает на вход путь открываемого ресурса, будь то объект или миссия. Таким образом открыть нужный файл можно четырьмя способами:
— из командной строки, указав путь к открываемому файлу, например так:
dark_engine_viewer_x64.exe "D:\Games\Thief 2 — The Metal Age\MISS13.MIS"— перетаскиванием файла на значок программы;
— перетаскиванием файла на открытое окно программы;
— созданием ассоциации расширений файлов моделей и миссий (BIN и MIS) с просмотрщиком и открыванием их двойным кликом прямо из Проводника.
Запуск на Linux и устаревшем оборудовании
Для старых видеокарт, не поддерживающих OpenGL 3, сделана специальная версия — LEGACY HARDWARE. Её функционал сильно ограничен, но пользоваться основными функциями просмотрщика она позволяет. Для её запуска используйте исполняемый файл dark_engine_viewer_legacy.exe.
Кроме того, есть и linux-сборка просмотрщика: dark_engine_viewer_x64. В настоящее время она работает в режиме LEGACY HARDWARE и так же весьма ограничена в плане графических возможностей, но в отличие от legacy-версии, со временем станет полнофункциональной.
Как пользоваться
Всё должно быть интуитивно понятно: интерфейс просмотра файлов прокручивается колесиком мыши, модели открываются по клику, перелистывание моделей «предыдущая/следующая» осуществляется стрелками клавиатуры, PgUp, PgDn, Home и End. Открытую модель можно приближать или отдалять от камеры колесиком мыши, вращать левой кнопкой мыши, перетаскивать — правой.
При открытии миссии, в правом верхнем углу программы появляется кнопка «Free camera mode», нажав на которую программа переходит в режим «свободного полета», управление в этом режиме осуществляется следующими клавишами:
WASD и стрелки — перемещение камеры, мышь — вращение по осям x и y
C — перемещение камеры вниз
SPACE — перемещение камеры вверх
SHIFT + клавиша перемещения — ускоренное перемещение
ESC — отображение интерфейса
ALT + ENTER — полноэкранный режим (HD Ready — 720p)
+/- — увеличение/уменьшение яркости
I — вкл/выкл освещение
K — вкл/выкл SSAO
O — вкл/выкл тени
P — вкл/выкл parallax occlusion mapping (выкл по умолчанию, требуется доработка)
U — вкл/выкл мягкие тени (выкл по умолчанию, требуется доработка)
Y — вкл/выкл контактные тени (выкл по умолчанию, требуется доработка)
Назначения цифровых клавиш (будут меняться в последующих сборках):
1 — вывод финального кадра со всеми эффектами (по умолчанию)
2 — вывод нормалей кадра
3 — вывод освещенности кадра
4 — вывод SSAO кадра
5 — вывод глубины кадра
6 — вывод искривленных нормалей кадра (bent normals)
7 — вывод глубины с добавлением карты высот
Эффекты, которые выключены по умолчанию — работают некорректно. Включение parallax occlusion mapping не покажет ничего, потому что у вас, скорее всего, отсутствуют карты высот для текстур. Но если вы захотите посмотреть как оно будет выглядеть, подложив необходимые текстуры, включите эффект клавишей P. При добавлении карты высот, добавьте к её имени постфикс «_h», кстати, для нормалей — это «_n», таким образом, если текстура называется bricks.pcx, то карта высот должна называться bricks_h.dds (формат текстуры может отличаться и быть любым, поддерживаемым игрой, не обязательно DDS, но DDS предпочтительнее), а карта нормалей — bricks_n.dds.
Поддерживаемые форматы текстур: DDS (только сжатые), PNG, TGA, PCX, GIF, JPG, BMP.
Вот вам, скриншот для затравки из предыдущей юбилейной версии программы:
(https://sun9-57.userapi.com/c857628/v857628878/10e9e7/FzlbHyvYRo0.jpg)
Эксперименты приветствуются! Публикуйте свои скриншоты!
Ограничения
В настоящее время программа поддерживает три формата моделей: BIN, MIS и OBJ.
Поскольку программа ещё в разработке, поддержка некоторых форматов реализована лишь частично.
BIN — поддерживаются как статические, так и динамические модели, расположенные в файлах obj.crf и mesh.crf соответственно.
MIS — поддерживаются миссии, сделанные как на оригинальном DromEd, так и на новом, расширенном для New Dark Engine.
OBJ — формат поддерживается на базовом уровне, без текстур
Планы развития
В глобальной перспективе просмотрщик должен превратиться в полноценный 3D-движок — Force Engine. Никто не собирается тягаться с Unreal Engine и Unity, моя личная задача состоит в том, чтобы создать на основе этого движка собственную игру.
Более близкие планы — это поддержка всех необходимых ресурсов Dark Engine, для оттачивания на них общих игровых механик, таких как физика, рендеринг, распространение звука, перемещение по уровню, взаимодействие с персонажами и предметами, искусственный интеллект. Всё это планируется реализовать с ресурсами Dark Engine, поэтому логично ожидать от этого проекта появления какого-то игрового прототипа, внешне похожего на Thief. Степень готовности этого прототипа будет обсуждаться с теми, кто проявляет интерес к проекту.
Планируется регулярная публикация обновлений. Поэтому я буду ждать ваших предложений по необходимому функционалу и коррекции приоритетов задач из списка TODO, который можно найти в этом сообщении чуть ниже.
Концепт, нарисованный Чужим, к которому мы сейчас подбираемся:
(http://chuzhoi.city/images/darkfate/bin-viewer-filelist.jpg)
Пожелания
Прошу сообщать о всех найденных ошибках, багах, пожеланиях и предложениях либо мне на почту: toforce@ya.ru, либо в прямо в эту тему, либо в тему просмотрщика на форуме TTLG (https://www.ttlg.com/forums/showthread.php?t=150408) (eng). Так же, если возникают любые другие вопросы — обращайтесь!
Приветствуется распространение информации о данном проекте всеми возможными способами! Я буду очень благодарен за любое упоминание Dark Engine Viewer и моего сайта forcesw.com (http://forcesw.com/rus) в соцсетях.
Благодарности
Я очень благодарен:
— участникам сообщества Dark Fate, без которых этот просмотрщик вряд ли был бы создан, их ники в алфавитном порядке: Boris3000, Chuzhoi, HellRaiser, Maxim, nemyax, Zontik и другим…
— разработчикам и программистам, занимавшимся реверс-инжинирингом оригинального Dark Engine, и запустившим проект Open Dark Engine, без которого идея с ресурсами Thief для Force Engine никогда не состоялась бы, их ники в алфавитном порядке: Telliamed, Volca и всех, кто был причастен к этому.
— Juliusz Kaczmarek aka PinkDot, который помог добавить в программу поддержку формата миссий New Dark Engine, а так же помог в расшифровке формата динамических MESH-объектов.
— Randy Sybel aka Shadowspawn за то, что помог разобраться как использовать расшифрованные данные, полученные из динамических MESH-объектов.
— всем, кто каким-либо образом консультировал, поддерживал и мотивировал меня, включая Vorob’а и мою супругу Татьяну!
Спасибо вам всем!
Авторское право
Используя эту программу, вы соглашаетесь с тем, что её автор не несёт никакой ответственности за возможный вред, причиненный оборудованию или программному обеспечению, напрямую или косвенно связанный с использованием данной программы. Целью автора не является заражение вашего компьютера или распространение вирусов, поэтому критически отнеситесь к возможным предупреждениям антивирусного ПО.
Выдержки из TODO (приоритет указан не в строгом порядке)
ОШИБКИ:
- некоторые модели возвращают пустые списки полигонов в своих костях (поврежденная модель). Возможно, следует изменить алгоритм чтения, чтобы учитывать ВСЕ части модели, даже неиспользуемые?
- на конских разрешениях (значительно больше разрешения монитора) интерфейс работает некорректно (разрешение программы не совпадает с запрашиваемым по конфигурации)
ДОРАБОТКИ:
- некоторые объекты, всё-таки, имеют неверную ориентацию: штурвал корабля в Shipping, сверло-бур в Cargo. Разобраться.
- добавить информацию о разрешении используемой текстуры для моделей
- раскрашенные цветом части модели имеют неправильную нормаль, из-за чего в режиме просмотра миссии с освещением выглядят абсолютно черными. Вернуть нормаль этим полигонам модели
- добавить в считыватель моделей информацию об освещенности некоторых частей объекта. Судя по всему, это потребует добавить светящиеся текстуры.
- клавиши общего функционала, разворот на полный экран и др. должны работать в любом режиме программы
- добавить клавишу BACKSPACE - открытие родительского каталога
- закрытие дескрипторов архивов и файлов после завершения работы с ними (загрузка уровней)
- linux: при запросе файла или каталога искать его без учета регистра
- linux: исправить падение при чтении каталога, к которому нет прав доступа (проверить в разных системах)
- обновление данных без перезагрузки интерфейса
- ошибку загружать без замены всего интерфейса
- уметь открывать программу с переданным архивом или каталогом
- добавить возможность в шаблоне проверять true/false для пустых/заполненных строк (с переходом на squirrel)
- убрать установку данных в шейдер отдельным методом схемы рендеринга (чтобы не переключать шейдер только для этого)
- можно сделать ленивую загрузку данных текстуры, отделив чтение заголовка от чтения данных цвета, это позволит избавиться от копирования памяти при использовании PBO, сразу читая данные в указатель видеопамяти, заодно можно будет выкинуть код, работающий без PBO
- собирать glad как отдельную библиотеку и подключать её к проекту
- позиционировать модель перед камерой с более презентативного угла (переместить камеру вправо и вверх)
- восстановить силуэты POM
- исправить отображение теней в режиме POM
- в зависимости от расстояния до объекта менять скорость скроллинга
- сделать hot-key, возвращающий вид в исходный
- вместо ошибок о неподдерживаемых типах текстур, выдавать default-текстуру
- потюнить автомасштаб при открытии модели когда дебажная отрисовка будет готова
- добавить тени для прожекторов (с переходом на кластерный рендерер)
- починить мягкие тени
- сейчас массив hullVertices кости содержат все вершины кости, надо высчитать из них только образующие convex hull (как вариант - использовать OBB - AABB в пространстве модели)
- подумать об отказе от ручной линеаризации цвета
- источник света, находящийся вблизи стены рисует черный квадрат на этой стене (слишком большая разница между точностью глубины источника и камеры? перемещать плоскости отсечения в зависимости от объектов в сцене?)
- LEGACY HARDWARE: каталоги с русскими именами не сортируются
- LEGACY HARDWARE: не отображаются каталоги, начинающиеся с точки
- добавить атрибут outline для шрифта
- выводить инфу об mtl файлах в интерфейсе
- цветами выделять текстуры из архивов/каталогов/дефолтную
- проверить что будет в критических ситуациях, когда шаблон вывода ошибки сам выводит ошибку
- стабильность, чтоб программа не падала при определенных значениях атрибутов интерфейса
- каждый элемент в прокручиваемом списке рисовать через буфер трафарета (только те кости, что попадают в область видимости)
- разрешить менять размер окна, при этом интерфейс не должен масштабироваться, а должен раздвигаться?
- модель при таскании правой кнопкой перемещается не точно по курсору мыши
НОВЫЕ ФИШКИ:
- запись и чтение конфигурационного файла
- эффекты в режиме просмотра моделей
- направленный источник света
- изменение настроек программы средствами интерфейса
- создание тестовых миссий для демонстрации возможностей движка
- переделать работу с полигонами неба: не удалять их, а выводить кубмапу неба в них
- поддержка прозрачных цветов в палитре (первый цвет) и правильная отрисовка полупрозрачных полигонов
- добавление поддержки squirrel
- переделать шаблонизатор на использование squirrel, отказавшись от самописной логики
- кубмапы для фона просмотра модели на выбор (светлая/темная)
- если список использованных текстур не влезает в экран, выводить кнопку, открывающую всплывающую панель с прокручиваемым списком
- velocity и motion blur
- сохранение скриншотов
- поддержка анимированных текстур
- отображение джойнтов, вхотов, нормалей, костей скелета
- разбиение уровней на octree и загрузка только ближайших кусков
- генерация вокселей для небольших ячеек octree
- кластерный рендерер
- отказаться от кубмапы тени и использовать текстурный атлас (с переходом на кластерный рендерер)
- генерировать reflection probes в текстурный атлас
- GI
- pbr
- поддержка анимаций dark engine?
- добавить поддержку спецификации glTF
УДОБСТВА КОДА/РЕФАКТОРИНГ:
- отрефакторить менеджер команд и их обработку, сейчас слишком всё запутано и неудобно
- получать все синглтоны (менеджеры ресурсов) прямо по месту использования и не хранить ссылки на них в объектах? Или переделать всё на впрыскивание объектов?
- привязывать текстуры к шейдерным юнитам
- сделать bind-guard'ы для всех привязываемых ресурсов, это упростит код
- отделить исключения для вывода ошибки от фатальных исключений, закрывающих программу, чтобы избавиться от бесконечного цикла вызова ошибки из ошибки
- подумать над единобразием места конвертирования путей функцией formatAsPath() и нужно ли оно или достаточно оставить только в функции path()?
- добавить в шаблонизатор проверку условия true/false через оператор (не понадобится с переходом на squirrel)
- Uniform Buffer Object
ПОДУМАТЬ, НУЖНО ЛИ:
- если текстура была загружена в одном режиме (clamp/repeat), она не загрузится в другом
- прерывать выполнение команды при вызове другой (если их не может быть запущено несколько)?
- если пользовательский ввод не привел к изменениям - не перерисовывать кадр? Перерисовывать частично?
- adaptive shadow bias?
- скриншот с прозрачным фоном (?)
P.S.
Сообщение будет обновляться.
-
Супер! :up:
-
Бложики разработчиков — это круто!
-
Честно прочитал и попытался понять все, но особенно зацепило почему-то именно это:
лог файл должен всегда создаваться в каталоге программы
Отдельное спасибо за эту незначительную (казалось бы) мелочь!
-
Сообщение, перенесенное из первого поста
Приветствую всех, друзья тафферы! ;)
В этот радостный день, в 21-ю годовщину Thief: The Dark Project хотел представить вам результат своей годичной работы: ровно год назад я опубликовал первую публичную тестовую версию своей программы - Dark Engine Viewer. Теперь, спустя целый год, казалось бы, можно выкатить крутейший работающий билд с целой кучей новых фич, с реализацией всех хотелок и вообще...
Но я не буду. :o
Потому что я не успел подготовиться. Да и что греха таить, не успел реализовать всех пожеланий... Да что там, если запустить программу, вы не увидите там никаких существенных изменений относительно предыдущей версии.
В общем, я решил действовать открыто и теперь планирую выкатывать обновления регулярно, обсуждая, какую штуку приделать следующей. В сегодняшний знаменательный день начать мы не успеем, поэтому я буду менять этот первый пост по мере продвижения.
В моих планах первоочередная задача сейчас - переписать загрузку моделей, добавить поддержку моделей персонажей. Это довольно крупная задача. Следующая крупная задача - сделать интерфейс изменяемым динамически, а не как сейчас - загружать заново для каждой новой модели. Это позволит вводить текст и приделать наконец контрол для быстрого поиска.
Для самых нетерпеливых выкатываю не очень стабильный билд (http://forcesw.com/deviewer_thief_21th_anniversary.zip), исследуйте на свой страх и риск.
Ещё раз всех поздравляю с годовщиной! И да, сообщение скоро обновится! ;)
--------Оригинальное сообщение--------
Обновил TODO в первом посте и исправил несколько критических ошибок программы. Можно перекачать архив.
Хотелось бы сказать пару слов об изменениях последнего года, что не очень понятно из лога TODO (в который, кстати попадает не всё).
- Добавилась поддержка каталогов игры.
Это значит что можно открыть любую миссию прямо из каталога игры и увидеть все статичные объекты и текстуры. Ничего распаковывать для этого не требуется, ура! :) При этом динамически будут сгенерированы все лайтмэпы для всех источников света, если вы на них повернете камеру (сейчас это приводит к кратковременным тормозам). Это делается один раз за загрузку миссии, ВСЕ лайтмэпы кэшируются, поэтому дальнейший рендеринг должен быть быстрым. Из-за того, что генерируются ВСЕ лайтмэпы миссии, их размер выставлен в 256х256 пикселей, чтобы они гарантировано влезли в видеопамять. Вряд ли удастся посмотреть современные ФМки, поскольку (об этом уже неоднократно говорилось) разработчики New Dark Engine изменили формат миссий и держат его в тайне. Эта тема требует дальнейших исследований и разработки.
- Загрузка миссии осуществляется с отображением интерфейса и без индикатора загрузки, поэтому, если вам показалось что программа зависла, проверьте загруженность диска в диспетчере задач, скорее всего просто загрузка миссии занимает продолжительное время. После загрузки вы можете увидеть черный экран или нагромождение объектов - это нормально. Если вы видите в правом верхнем углу появившуюся кнопу "Free camera mode" - можете нажать её, это спрячет интерфейс и даст возможность повертеть головой. Если всё равно ничего не видно, возможно вы находитесь в неосвещённой комнате - нажмите клавишу "i", чтобы отключить освещение (по аналогии с режимом light_bright в DromEd'е).
- Программа принимает на вход путь открываемого ресурса, будь то объект или миссия. Например так:
dark_engine_viewer_x64.exe "D:\Games\Thief 2 - The Metal Age\MISS13.MIS"Разумеется, таким образом можно передать параметр, перетащив нужный файл на значок программы, либо на её открытое окно. В будущем добавится возможность передавать туда пути к каталогам или архивам.
Прошу сообщать о всех найденных ошибках, багах, пожеланиях и предложениях прямо в эту тему.
Об организации последующих билдов ещё предстоит подумать, скорее всего, они будут выкладываться отдельными архивами по мере добавления фичь, что потенциально может приводить к ошибкам ранее работающего функционала.
-
Исправлено падение программы в режиме LEGACY HARDWARE при попытке просмотра корня диска.
Архив юбилейной сборки в первом посте обновлен в последний раз. Дальнейшие его модификации не планируются. Сборки будут выпускаться в новых архивах.
-
разработчики New Dark Engine изменили формат миссий
То есть они и в компилятор уровней залезли?
-
nemyax
Да, они же чинили DromEd, расширяя ограничения, улучшая статические лайтмэпы и т.п.
У нас есть два варианта: попытаться реверснуть их новый формат (не думаю, что это шибко сложно) и надеяться, что они его больше не поменяют; либо самим компилировать уровни уже так, как нужно нам, приобретая целую гору преимуществ: можно будет убрать все существующие костыли - сейчас есть ворох дополнительных файлов для уровней и текстур, которые дёргаются во время каждой загрузки ресурсов, можно эту информацию интегрировать в откопилированный уровень в удобном для рендеринга виде, при этом не нужно будет портализовать миссию дромедом, все изменения будут видны сразу после сохранения, но это сложнее, надо найти этот код где-то в недрах доступных исходников (если он там есть) и попытаться разобраться в нём. Это CSG - constructive solid geometry.
-
Обновил первый пост, собрал там всю (вроде бы) актуальную информацию по разработке. Если кто что-то ещё вспомнит, скажите, добавлю.
Теперь сборки будут поставляться в обновляемом файле http://forcesw.com/deviewer_build.zip
Особая историчность версий, на мой взгляд, не нужна, поэтому архив сборки будет обновляться, и все желающие получать последнюю версию, должны будут перекачивать один и тот же архив.
-
Последние изменения
2019-12-10 15:00 MSK
+ исправлена распаковка нормалей моделей, теперь все объекты корректно освещаются источниками света
Обновил описание в первом посте. В архив сборки добавил readme на русском и английском языках. Буду признателен, если кто-нибудь, свободно владеющий английским, просмотрит английский текст на наличие ошибок! :yes:
-
Нифига-се - поддержка объёмных текстур :o :up:
Даа, глядя на обширный список "сделать", можно поразиться масштабам. А всё начиналось с утилитки для простых нужд.
Force, ты так скоро свой NewDark запилишь ;D
Вот бы ещё Вор поддерживал "окклужн" текстурки.
Концепт, нарисованный Чужим, к которому мы сейчас подбираемся
Хорошо получилось в итоге. До сих пор нравится получившийся минимализм. Я правда ещё не пробовал качать более поздние версии.
Поиск прикручен - это здорово. А ты вроде говорил, что такая мелочь потребует многих усилий.
Сходу просится в глаза кое-что, что хочу внести как предложение. Сущая мелочь. Но я не уверен, что это правильно и прям нужно, поэтому тут зависит от поддержки большинства. Ну и тебя, как автора, естественно. Если они видят, что это хорошо, то пусть.
Так вот: на твоём скрине с моделью Будды как раз выделено слева название модели. Но выделение можно улучшить чисто визуально для чёткого отделения от остального хаоса названий, если помимо этой серой полоски, шрифт названия будет красного цвета или жёлтого (но только таких цветов). Желательно такого же оттенка красного, как применённый для написания названий сторон текстур. Вот эти, где "BUDDHA_X - not found"
Это мелочь, чисто косметическая фишка, но глазу будет особенно удобно. Выделение же менять по цвету не надо. Только само название. Можно и такого же оттенка синего, как то же указание сторон текстур, но красный, а особенно жёлтый, исходя из серой гаммы всего остального - мне кажется будут лучше.
-
Даа, глядя на обширный список "сделать", можно поразиться масштабам. А всё начиналось с утилитки для простых нужд.
Ну, не совсем, для меня началось всё ещё в 2011-м... А мечта сформировалась так вообще в 2004-м... Утилитка была лишь поводом применить наработки и опубликовать результат, чтобы работать не "в стол".
Force, ты так скоро свой NewDark запилишь ;D
К тому и движемся ;). Хотя, по-любому, масштабы у меня поскромнее и цели немного другие. В первом посте всё написано.
Вот бы ещё Вор поддерживал "окклужн" текстурки.
Если ты про NewDark - то тут вопрос не ко мне. Если про DEViewer - то можно, если очень захочется. Вообще, PBR в планах и обычно там не используются оклюжн-текстуры, но сложности никакой нет, если что. Скажете - сделаем :).
Поиск прикручен - это здорово. А ты вроде говорил, что такая мелочь потребует многих усилий.
Не прикручен, в том то и дело, я писал, что это в ближайших планах:
Следующая крупная задача - сделать интерфейс изменяемым динамически, а не как сейчас - загружать заново для каждой новой модели, это позволит вводить текст и приделать, наконец, контрол для быстрого поиска, который так просил Максим :).
Сейчас я занялся поддержкой моделей персонажей. Только после этого возьмусь за интерфейс и поиск.
Но выделение можно улучшить чисто визуально для чёткого отделения от остального хаоса названий, если помимо этой серой полоски, шрифт названия будет красного цвета или жёлтого (но только таких цветов).
Красным нельзя - это цвет ошибки, синим вроде как планировалось отображать ресурсы из архивов (надо посмотреть, как это будет всё выглядеть). Бледно желтым - можно. Надо чтобы Чужой высказал свое мнение и доработал концепт, при необходимости.
-
Последние изменения
2019-12-11 16:00 MSK
+ исправлена ошибка компиляции шейдера depth_tree на картах AMD
+ расширено логирование при ошибках поиска текстур для упрощения анализа логов
Обновлен первый пост, добавлена информация о версиях linux и legacy, добавлены благодарности (как я умудрился их забыть? :eeeh:).
Chuzhoi призывается в тему для обсуждения предложения Максима по поводу цвета имени текущей модели в списке файлов.
-
Я пока не перерисовывал концепт, т. к. в цветах и деталях он довольно сильно отличается от программы, и ограничился редактированием скриншотов.
По мне, текущее имя файла и так достаточно хорошо видно. Но если общественность просит... В общем, я согласен, что если выделять, то только желтым:
(http://chuzhoi.city/images/darkfate/de-viewer-yellow-left.jpg)
(Я бы еще немного потемнее сделал информацию о текстурах и прочем - оставив верхнюю строчку на прежнем уровне яркости; это тоже отражено на скриншоте.)
Можно еще выделить имя файла в этой самой строчке:
(http://chuzhoi.city/images/darkfate/de-viewer-yellow-left-top.jpg)
(Xотя, по-моему, это уже излишество. Лишние цвета во вьюпорте ни к чему).
Буду признателен, если кто-нибудь, свободно владеющий английским, просмотрит английский текст на наличие ошибок!
Я, конечно, не носитель языка, но я прочитал пару полноразмерных книжек и чувствую себя вправе давать некоторые советы. В целом текст мне показался весьма грамотным и понятным, каких-то грубых ошибок вроде отсутствия -s в третьем лице ед. числа или вопиющей нехватки артиклей не просматривается.
Бросилось в глаза следующее:
creating an association of model and mission file extensions (BIN and MIS) with a the viewer
When the a mission is opened
(Я бы также сделал это предложение в новом абзаце).
clicking on it and the program enters the "free flight" mode - надо как-то переформулировать, например: clicking on it switches the program in the "free flight" mode
In this mode the camera is controlled by the following keys:
WASD and arrows - camera movement, mouse - rotation along the x and y axes
C - move the camera down
SPACE - move the camera up
The effects that are turned off by default do not work correctly
It's planned to regularly publish updates.
-
Мне нравится с желтым выделением в колонке. Да, видно и без того хорошо... но, на мой взгляд, это одна из тех деталей, что отличают совершенный продукт от просто хорошего.
Вот во вьюпорте- действительно лишнее. И это выделение логически ничем не оправдано. Да еще и перечеркивает тут плюсик к комфорту, что дает желтый цвет в колонке. Видишь два одинаковых выделения - и невольно начинаешь сравнивать и искать разницу, отвлекаясь от основной задачи.
-
Chuzhoi
Отлично! Спасибо! Кстати, хочу сделать окантовку вокруг букв во вьюпорте, чтобы читаемость не страдала от светлого фона.
Zontik
Ты не проверял? У тебя работает последняя сборка? Какие перспективы на апгрейд у тебя? ;)
-
Нет, я сейчас категорически не успеваю ничего лишнего. Увы.
Перспективы на апгрейд у меня вполне определенные: однажды он станет неизбежен. Морально я уже к этому готов. Но, увы, пока не материально.
хочу сделать окантовку вокруг букв во вьюпорте
Не знаю, что ты называешь окантовкой, но если в буквальном смысле (буквы с контуром) - мелкие довольно плохо читаются. Полупрозрачный темный фон в этом смысле воспринимается куда лучше.
-
Не знаю, что ты называешь окантовкой, но если в буквальном смысле (буквы с контуром) - мелкие довольно плохо читаются. Полупрозрачный темный фон в этом смысле воспринимается куда лучше.
Можно оба варианта попробовать. Также можно попробовать окантовку вокруг букв сделать размытой, если это технически возможно.
-
Всё-таки жёлтый бледноватый сделали. Его можно либо насыщеннее сделать, выбрав эталонный жёлтый, либо сместить чуть ближе к оранжевому. Будь моя воля - сделал бы красно-оранжевым, но раз это цвет ошибки...
Таким я себе представляю идеал:
(https://i.ibb.co/SnjRwQV/DE-viewer-conc.png)
Цветовая легенда:
(https://i.ibb.co/Zzqx1TM/DE-viewer-color-legend.png)
1)
HTML: fffc00
RGB: 100 99 0 (%)
HSV: 59,4 100 100 (%)
---
2.
HTML: ff9939
RGB: 100 60 22,4 (%)
HSV: 29,1 77,6 100 (%)
---
3.
HTML: ffbc39
RGB: 100 73,7 22,4 (%)
HSV: 39,7 77,6 100 (%)
Так же у выделения есть окантовка в значении 0,25 (опционально)
Окантовку же вокруг букв размытой делать нельзя, при данном дизайне.
В общем, показанное — при желании/времени. А так, вполне нормально и то что есть.
-
Окантовку же вокруг букв размытой делать нельзя, при данном дизайне.
Имеется в виду окантовка для букв в самом вьюпорте - на тот случай, если просматриваемая модель или миссия будет светлой. На черном фоне ее не будет видно. Окантовка же для букв и других элементов на панели файлов совершенно не нужна.
Что касается желтого цвета, то, возможно, он и несколько бледноват, и можно сделать его немного поярче. Но насколько - вопрос дискуссионный, поэтому я предлагаю высказаться остальным заинтересованным. Мне кажется, что твой вариант слишком ярок. Оранжевый, кстати, тоже неплох - но только тот, который снизу, а не сверху (желто-оранжевый).
-
Да, это хорошая мысль. Спасибо за разъяснение.
Кстати, а какова конечная цель проекта? Что в идеале программа должна уметь делать?
-
Забавно, но на представленном скрине лучше всего читается именно средняя строка, желтая. Оранжевый на сером размывается.
Была бы еще указана цветовая формула для четвертого элемента (фона) - можно было бы и глаза не напрягать, а просто проанализировать числа.
При этом ярко-желтый читается так же хорошо, как и бледно-желтый, но из сдержанного дизайна выбивается.
Может показаться, что мы тут цепляемся к мелочам. Ну да, после того, что сделали в последних версиях Премьера, слово "читабельность" вообще лучше забыть. И не такие дизайнерские причуды приходится терпеть. Но если уж вы спросили...
-
Есть возможность добавить нечто вроде статистики? Открываешь карту и видишь - на карте столько-то мобов (типы мобов), столько-то аммо (тип аммо). и тд.
-
spy
Есть возможность, рекомендую обговорить это сейчас всем вместе, что конкретно нужно, и это можно будет разместить на экране сразу после загрузки миссии, как у моделей. Информации много, поэтому всё может не влезть, а городить сейчас дополнительный интерфейс пока некогда.
Maxim
Кстати, а какова конечная цель проекта? Что в идеале программа должна уметь делать?
Мне видится конечная цель просмотрщика - это реализация ТЗ. Из ТЗ не хватает лишь поиска, некоторых информационных фич, типа цветной подсветки ресурсов из архива, расширенной информации о моделях и миссиях... Всё остальное идет бонусом - всякие тени, прозрачности, съемка скриншотов. А конечная цель ВООБЩЕ - прототип игры с ресурсами Thief. Это описано в первом посте. Но принимаются к рассмотрению любые предложения ;)
-
Да, я читал про всеобщую цель, но если честно, она мне показалась как бы с запасом на дальнее будущее. Не типа грёз, а что-то такое... сложное в достижении. Просто если рассматривать это на фоне того, что даже поиск трудно сделать, оказывается. И что, действительно может получиться в итоге?
И есть ещё одна вещь, которая любопытна чисто в теоретическом плане. Как мы знаем, француз Le Corbeau (или как пишется его имя... всё время забываю), по странному стечению обстоятельств получил исходники Thief. Так вот, при должных навыках программирования можно ли благодаря им настолько улучшить Thief, чтобы например модернизировать скелет моделей, сделать анимацию лица или какую-нибудь динамическую погоду? Как я понял, для этого не хватает исходников. И на этом фоне интересует и твоя конечная цель. Прототип игры с ресурсами Thief это как? Типа можно даже полноценную игру сделать? Или это так и остаётся всё равно каталогом по своей сути?
-
Не типа грёз, а что-то такое... сложное в достижении.
Да, так и есть.
И что, действительно может получиться в итоге?
Покажет время :). Очень на это надеюсь. Всякие специфические хотелки для просмотрщика (не лежащие в направлении игрового движка), несколько отдаляют этот момент.
Так вот, при должных навыках программирования можно ли благодаря им настолько улучшить Thief, чтобы например модернизировать скелет моделей, сделать анимацию лица или какую-нибудь динамическую погоду? Как я понял, для этого не хватает исходников.
Всего им хватает, они же собрали проект в итоге. И можно сделать абсолютно всё что только пожелаешь, вопрос в том, нужно ли? Как я уже когда-то говорил, пусть Thief остается Thief'ом, ему совсем ни к чему динамическая погода и т.п. навороты. Он есть, его у нас никто не отнимает. Вот например, пришел ты к Баффорду и фигакс, утро наступило, все проснулись, ходят по особняку, а там ты - слабый и беззащитный, что делать? Ныкаться до ночи или валить всех и брать скипетр? Короче, это уже совсем другая игра.
Но если пофантазировать, например, мы на официальной основе делаем ремейк Thief, нам зарплаты платят, мы фулл-тайм занимаемся только им, почему бы тогда не сделать всё современно и хорошо? Ну мы берем и делаем. Лицевую анимацию, погоду, управление транспортом, портальная пушка, все дела... Вот и всё. Да, если говорить в разрезе оригинальных исходников Thief, то пришлось бы повозиться, потому что обычно старые форматы ресурсов совсем несовместимы с нынешними технологиями, их банально неудобно использовать, поэтому пришлось бы писать конвертеры, а это в свою очередь, привело бы к значительному изменению оригинального кода, в итоге куча лишней работы, непонятно зачем сделанной, намного проще взять готовый движок и сделать всё заново на нём и это опять будет уже другая игра. Как было с Thief 3.
И на этом фоне интересует и твоя конечная цель. Прототип игры с ресурсами Thief это как? Типа можно даже полноценную игру сделать?
Ну, например, так: https://www.youtube.com/watch?v=DG9C4ouE1Fw только с графикой посовременней. Я не говорю что так и будет, просто чтобы было понятно, как это может выглядеть. Я сам ещё не знаю :).
Или это так и остаётся всё равно каталогом по своей сути?
Даже сейчас "каталог" - это дополнительный функционал, а не основной. Архитектура заточена именно на игровой движок, просмотр ресурсов - это лишь внешняя сторона программы (можно воспринимать это как меню в игре). Пока просто она отнимает всё основное время разработки, но код пишется так, чтобы всё это работало во время игрового процесса.
-
spy
Есть возможность, рекомендую обговорить это сейчас всем вместе, что конкретно нужно, и это можно будет разместить на экране сразу после загрузки миссии, как у моделей. Информации много, поэтому всё может не влезть, а городить сейчас дополнительный интерфейс пока некогда.
Только хотел написать про отдельное меню, как увидел выделенное. Не знаю насколько это сложно, хватило бы всплывающего окна, шифт-s (stats). Появляется окошко с инфой. Я примерно так представлял себе это. Смотришь и видишь - ага -
================
зомби - 15 штук,
призраки - 3,
хаунты - 8.
водяные стрелы - 20.
=============
Хотя решать тебе.
Меня в нынешнем воре устраивает почти всё. Еслиб можно было прикрутить тени как Т3 и сделать новые модели в замен существующих с квадратными плечами, было бы просто замечательно. Нравится идея которую в свое время вычитал у гоблина, который говорил, что мобы на эксперте, после оглушения через некоторое время приходят в себя, и начинают искать игрока.
-
Нравится идея которую в свое время вычитал у гоблина, который говорил, что мобы на эксперте, после оглушения через некоторое время приходят в себя, и начинают искать игрока.
Именно из-за подобных мобов я и бросил System Shock 2, не доиграв. Патроны конечны, а враги бессмертны - вот и вся убогая суть этой идеи, как я ее понял.
Хотя движок Вора даже в текущем варианте позволяет добиться подобного поведения AI, к счастью, у подавляющего большинства авторов хватает ума этого не делать.
-
Zontik
Именно из-за подобных мобов я и бросил System Shock 2, не доиграв.
А не приходила мысль связывать их или запирать где-нибудь? Ну то есть, это как бы получается "полуторный" вариант ghost-прохождения, когда ты можешь оглушать, но при этом вынужден морочиться с телами, либо искать место где их можно было бы запереть, либо связывать (а веревка конечный ресурс), в итоге проще оказывается играть ghost'ом, но в случае крайней необходимости - вот такой вариант. На мой взгляд, техника интересная, да и "мобы" конечны, они не спавнятся, а лишь "воскресают", но этот процесс можно контроллировать.
--------------------------
Кстати, по поводу нововведений. Вчера подумал об управлении навигацией с клавиатуры, предлагаю изменить её следующим образом:
- стрелки влево-вправо - переключают модель предыдущая-следующая
- стрелки вверх-вниз - просто смещают курсор
- клавишей ENTER можно открыть модель, на которой находится курсор
- клавиша BACKSPACE открывает родительский каталог
Таким образом у нас появляется возможность открывать каталоги при помощи клавиатуры..., короче, всю привычную логику работы с каталогами позволяет реализовать, плюс остается возможность листать модели, а поскольку список вертикальный, перемещение курсора стрелками вверх-вниз тоже выглядит логично.
-
Именно из-за подобных мобов я и бросил System Shock 2, не доиграв. Патроны конечны, а враги бессмертны - вот и вся убогая суть этой идеи, как я ее понял.
Хотя движок Вора даже в текущем варианте позволяет добиться подобного поведения AI, к счастью, у подавляющего большинства авторов хватает ума этого не делать.
Оффтопик: Зонт, ну ты тоже тот еще перец. Насажал дверей которые невозможно открыть, но которые простукиваются и вводят в заблуждение. Совершил простейшую геймдизайнерскую ошибку, хотя сам - тертый калач в этом деле.
Механика возрождения врагов работает в тандеме с возрождением игрока и поддерживает в постоянном напряжении. В воре ты хозяин положения, потому ты можешь и локации зачищать и двигаться незаметно, а в сисшоке ты - жертва. Всё там отлично разработчики реализовали.
-
Оффтопик:
А не приходила мысль связывать их или запирать где-нибудь?
Подобная система была в Cold War. Там, если оглушить врага обычным способом, он через некоторое время очухивается (более того, он будет приводить в чувство остальных оглушенных, которые попадут к нему в поле зрения). Но его можно усыпить насовсем (ну по крайней мере, до окончания миссии), вколов ему снотворное. А со снотворным, понятное дело, в игре напряженка...
Что касается SS2, то да, помню такую досадную мелочь, как респаун врагов. Но не помню, чтобы это сильно раздражало - по крайней мере, не до такой степени, чтобы из-за этого бросить игру. Тем более что там есть "будки воскрешения", которые за весьма умеренную плату (или, может, вообще бесплатно?) дают тебе почти (или полное?) бессмертие.
Зонт, ну ты тоже тот еще перец. Насажал дверей которые невозможно открыть, но которые простукиваются и вводят в заблуждение.
Это где?
-
Я вам больше скажу — в SS2 для меня даже необходимостью было, чтобы враги возрождались. Потому что ни раз попадал в такую ситуацию, когда деньги нужны для получения той или иной модификации и без которой не пройти, а они закончились, так как никогда не знаешь что ждёт в будущем и соответственно не можешь оптимально спланировать трату нанитов. Причём, эта ситуация возникла у меня даже в повторном прохождении, учреждённом через какое-то время. И снова именно на палубе возле лифта, в который надо попасть, чтобы двигаться дальше по прохождению истории. И приходилось бегать по палубе туда-сюда , отстреливать врагов и ожидать новых, дабы надыбать нанитов и сетуя каждый раз, если попадается "пустой" зомбак с бутылкой спиртного или пачкой чипсов, или же двумя патронами, вместо заветных нанитов. Я даже жалел, что они не возрождаются чаще, потому что набирать сумму было крайне однообразно и долго. ;D
-
Кстати, по поводу нововведений. Вчера подумал об управлении навигацией с клавиатуры, предлагаю изменить её следующим образом:
- стрелки влево-вправо - переключают модель предыдущая-следующая
- стрелки вверх-вниз - просто смещают курсор
- клавишей ENTER можно открыть модель, на которой находится курсор
- клавиша BACKSPACE открывает родительский каталог
Таким образом у нас появляется возможность открывать каталоги при помощи клавиатуры..., короче, всю привычную логику работы с каталогами позволяет реализовать, плюс остается возможность листать модели, а поскольку список вертикальный, перемещение курсора стрелками вверх-вниз тоже выглядит логично.
Да, я думаю, что это хороший вариант.
-
Это где?
Оффтопик: Ну как где? Как минимум в первой миссии его новой кампании.
-
Оффтопик:
А не приходила мысль связывать их или запирать где-нибудь?
Ты так пошутил, что ли, или я чего-то не ухватил из базового интерфейса?
"мобы" конечны, они не спавнятся, а лишь "воскресают", но этот процесс можно контроллировать.
Этого вообще не понял. Я бы и рад установить контроль над рождаемостью, но... как-то забыли обеспечить механизмом реализации.
Насажал дверей которые невозможно открыть, но которые простукиваются и вводят в заблуждение. Совершил простейшую геймдизайнерскую ошибку, хотя сам - тертый калач в этом деле.
Никто не совершенен. Хотя двери, которые невозможно открыть, у меня, как правило, не активны, что их и отличает. А простукивать у меня можно и стены с тем же успехом. Впрочем, это не оправдание, потому что есть и другие вещи, которые я бы сейчас сделал по-другому.
В воре ты хозяин положения, потому ты можешь и локации зачищать и двигаться незаметно, а в сисшоке ты - жертва. Всё там отлично разработчики реализовали.
Не спорю, просто мне такая игра удовольствия не доставляет. Одну боль.
Ладно, вернемся к теме.
- стрелки влево-вправо - переключают модель предыдущая-следующая
- стрелки вверх-вниз - просто смещают курсор
То есть в какой-то момент курсор и выделение оказываются в разных местах? На первый взгляд это как-то алогично. На тот же самый по счету взгляд - логичнее смещать курсор и выделение одновременно со сменой модели. Но в случае длинных списков это может привести к невозможности их листать, так?
- клавиша BACKSPACE открывает родительский каталог
Вот это правильно. А клавиша всегда будет работать, независимо от последних 1операций и смещения фокуса?
-
То есть в какой-то момент курсор и выделение оказываются в разных местах? На первый взгляд это как-то алогично.
И это верно. Как и то, что перемещаться между моделями клавишами "вверх" и "вниз" интуитивно понятнее (поскольку используется вертикальный список).
Я думаю, что все-таки стоит оставить нынешнюю систему, но иметь возможность перемещаться и по папкам, заходя в них Enter'ом. Когда выбрана папка, в центре вьюпорта можно писать ее имя в квадратных скобках тем же шрифтом, что и сообщение об ошибке (но только не красным цветом).
При вхождении в папку лучше, если будет открываться сразу первая модель, минуя папки (как сейчас). А клавиша Home может работать как сейчас - выбирать первую модель, но с рядом уточнений:
1. Если первая модель уже выбрана, то нажатие Home приведет в выбору папки [..].
2. Точно так же, если выбрана любая папка, кроме [..], нажатие Home приведет к выбору [..].
3. Если выбрана папка [..], нажатие Home приведет к выбору первой модели.
Таким образом, используя Home, можно будет попасть как на первую модель в списке, так и на папку [..]. Многократное нажатие Home будет приводить к циклическому переключению между папкой [..] и первой моделью.
Поведение клавиши PageUp аналогичное, но попроще - если листать дальше некуда, выбирается сначала первая модель, при следующем нажатии - папка [..]. И все. (Сейчас, кстати, PageUp переключает на конец списка, что неправильно; поведение PageDown корректное.)
И да, клавиша Backspace должна переходить на папку верхнего уровня.
На тот же самый по счету взгляд - логичнее смещать курсор и выделение одновременно со сменой модели. Но в случае длинных списков это может привести к невозможности их листать, так?
Не понял, почему?
Это где?
Оффтопик: Ну как где? Как минимум в первой миссии его новой кампании.
Оффтопик: А где именно? Не помню ни одной активной двери в кампании, в которую невозможно было бы войти.
-
Последние изменения
2019-12-18 23:30 MSK
+ пути к ресурсам игры удаляются из программы, если мы выходим из каталога игры (чтобы ресурсы разных игр не перемешивались при загрузке)
+ исправлено падение программы при клике или скролле на странице ошибки при первом запуске
+ окно программы при запуске располагается по центру экрана
+ исправлено поведение клавиши PgUp, перематывающей список в самый конец, при нажатии в верхней части списка
-
Я бы сделал перемещение через WSAD. В некоторых игровых эмуляторах, например, встречал навигацию в интерфейсе схожую игровой, что является как бы продолжением из одного в другое. Ну и привычно и тянуться рукой к стрелкам не надо.
-
Цитата: Zontik от Вчера в 16:18:25
На тот же самый по счету взгляд - логичнее смещать курсор и выделение одновременно со сменой модели. Но в случае длинных списков это может привести к невозможности их листать, так?
Не понял, почему?
Возможно, я что-то упускаю, но раз нельзя смещать курсор отдельно - значит, попасть в нижнюю часть списка можно, только пролистав его весь и посмотрев принудительно все промежуточные модели. Или тут есть альтернатива?
Я бы сделал перемещение через WSAD
А что будут делать в этом случае клавиши A и D? Список-то не трехмерный. И даже не двух.
Хотя на самом деле я приму любой интерфейс, поскольку уже ясно, что откровенно дурацким он все равно не будет. Но даже дурацкий интерфейс можно было бы простить за функциональность. Есть хороший пример, называется DromEd.
-
Возможно, я что-то упускаю, но раз нельзя смещать курсор отдельно - значит, попасть в нижнюю часть списка можно, только пролистав его весь и посмотрев принудительно все промежуточные модели. Или тут есть альтернатива?
Альтернатив достаточно: PageUp/PageDown, Home/End. Ну или воспользоваться мышью. (У тебя медленно открываются модели?)
Хотя, в принципе, и Форсов вариант с вверх/вниз - навигация только по списку и вправо/влево - навигация с переключением модели тоже неплох. Просто потребует немного привыкания, и не каждый сразу догадается, что так можно. Выделение открытой модели (желтый шрифт) отдельно от выделения текущего файла в списке (серый фон) у нас теперь, по крайней мере в теории, есть.
В общем, я колебаюсь. Или колеблюсь.
Я бы сделал перемещение через WSAD.
Мне эта идея, скажем так, не особенно нравится. Я вот вообще не играю через WSAD. Тогда мне, пользуясь этой логикой, надо выбирать предыдущий файл правой кнопкой мыши, а следующий - клавишей M. Или выбирать нужный файл джойстиком. Нет уж, давайте лучше по-классически, стрелками.
-
Force, а ты уже выходил с этой программой, так сказать, на международную арену? TTLG в курсе твоих наработок?
-
Да я не настаиваю на предложении, делайте как угодно, лишь бы всё работало :agree:
А как ты, Chuzhoi, играешь не с WSAD это занимательно. Ты же не только в авиасимуляторы играешь. Учитывая, что с точки зрения эргономики WSAD не просто так появилось. Находится в таком месте, где остальные клавиши, кои так же участвуют на исполнении других команд, располагаются по правую сторону и до них той же управляющей рукой легко дотягиваться. Со стрелками же предполагается, что основное управление сдвигается сугубо в правую, остаточную зону клавиатуры. А управлять правой рукой, а левой исполнять остальные команды это какая-то мозговыносящая фигня. Тем более, что в таком случае важные исполнительно-подтверждающие клавиши, которые должны быть в стороне от всего, оказываются именно в той зоне дотягивания правой рукой до них, как это было бы в случае левой руки и WSAD. То есть это не совсем правильно. Ибо что у тебя остаётся для дотягивания правой рукой на назначение остальных команд? /, ., \, ', ], Enter, Backspace, Delete, End, PgDn, PgUp, ну и правая цифровая клава. Большинство клавиш являются не свободными буквенными, а "системными", которым хорошо бы как раз отдельные команды исполнять. Либо руку искривлять, дотягиваясь куда-то. Всё это полная дичь и я всегда везде, где только можно, первым делом убираю дурацкое управление стрелками. В случае же использования буквенных клавиш на остальные команды левой рукой, ты лишаешься управления мышью. В общем, стрелки это архаика. Как правило, можно встретить в древних играх.
Можно предложить сделать возможность произвольного назначения клавиш на ту или иную команду, но предполагаю, что это воплотить в жизнь технически сложно. Force знает ответ. Это получается нужно пользовательский интерфейс иметь с опциями.
-
Maxim
Я тоже играю не на WSADе ;D
Chuzhoi
Нет, хотел модели персонажей приделать и пойти.
-
Оффтопик: Если разобраться, ESDF так-то функциональнее, чем WASD. Но почему-то не прижилось.
-
У тебя медленно открываются модели?
Я пока на правах теоретика. В предыдущих версиях открывались околомгновенно.
-
хотел модели персонажей приделать
Вот это будет прорыв. Понятное дело, что интерфейс, который мы обсуждаем - дело важное, но все же уже сейчас у него лицо вполне человеческое, и речь идет скорее о его полировке. А персонажи - это будет уже совсем здорово.
А анимация будет показываться? Или пока это совсем фантастика?
В общем, стрелки это архаика.
Оффтопик: Макс, я играю не стрелками. У меня ПКМ - вперед, M - назад, <> - вправо-влево. Остальное вокруг. Могу и WASD'ом играть (мне попадались игры, в которых управление не переназначается), но мне это не так привычно.
-
Ковыряюсь тут в модельках, пока фиксил ориентацию костей друг относительно друга, выяснил одну любопытную вещь...
Я вижу исправление бага позиционирования костей в отдельной модели:
(http://forcesw.com/i/reports/object_transform_bug_3.jpg)(http://forcesw.com/i/reports/object_transform_fix_1.jpg)
(http://forcesw.com/i/reports/object_transform_bug_4.jpg)(http://forcesw.com/i/reports/object_transform_fix_2.jpg)
Но, по всей видимости, в DromEd'е есть некий дополнительный параметр ориентации модели, который я не учитываю, некоторые проблемные модели в миссиях так и остались кривыми:
(http://forcesw.com/i/reports/object_transform_bug_1.jpg)(http://forcesw.com/i/reports/object_transform_bug_2.jpg)
Кто-нибудь может подсказать, что это за параметр может быть, или где он хотя бы в меню DromEd'а находится?
-
Force
Там в модели массив матричек 3х4, и у каждого чайлда индекс в туда. Но жизнь была бы пуста, если бы вместо единичных матричек не попадались бы массивы нулей.
Трансформы вроде в системе координат родителя.
-
nemyax
Матрицы разве не 3х3?
С нулями в родителе я разобрался, а вот в остальных местах - посмотрю. Надо эти бажные модели исследовать.
-
3x3, а сразу после неё вектор трансляции.
Ну вот оно (matrixs.h):
typedef float mxs_real;
typedef struct mxs_vector {
union {
struct {mxs_real x,y,z;};
mxs_real el[3];
};
} mxs_vector;
typedef struct mxs_matrix {
union {
struct {mxs_real m0,m1,m2,m3,m4,m5,m6,m7,m8;};
struct {mxs_vector vec[3];};
mxs_real el[9];
};
} mxs_matrix;
typedef struct mxs_trans {
mxs_matrix mat;
mxs_vector vec;
} mxs_trans;
Насчёт массива гоню, прямо на подобъекте хранится трансформ. В массиве там настройки лимитов вращения-скольжения. Забыл уже всё.
-
Ву-ху! :yay:
Исправлена давнишняя проблема ориентации объектов на миссии. Теперь все объекты должны четко стоять на своих местах, как задумано!
Было и стало:
(http://forcesw.com/i/reports/object_transform_bug_1.jpg)(http://forcesw.com/i/reports/object_transform_fix_3.jpg)
Связано это было с какой-то загадочной особенностью инициализации кватернионов в библиотеке glm. В механизме считывания самих моделей всё было нормально.
Сборка будет чуть позже.
-
Последние изменения
2020-01-04 00:55 MSK
+ исправлена ошибка вращения объекта сразу после его открытия, без предварительного движения мышью
+ исправлена ориентация некоторых объектов в миссиях, связанная с особенностью указания ориентации кватернионов в библиотеке GLM
+ исправлено построение AABB и OBB для объектов и их костей
+ шейдеры теперь умеют принимать на вход массивы данных
+ добавлена заготовка схемы отрисовки для дебажного вывода bounding boxes
Последняя актуальная сборка:
deviewer_build.zip (http://forcesw.com/deviewer_build.zip) 2020-01-04 00:55 MSK
Первый пост обновлен.
-
В формате уровней используются кватернионы?
-
Нет, углы Эйлера. Я просто преобразую их в кватернионы для ориентации объектов, а GLM, имея конструктор кватерниона из углов Эйлера, накладывает их в порядке x, y, z. В общем, какая-то дурацкая ситуация. Как можно правильно наложить трансформацию на объект по углам Эйлера по дефолту, когда ты не знаешь договоренности, в какой последовательности это надо делать? Короче, зачем в GLM такой конструктор? Может ты, как опытный моделлер прольешь свет? Я чего-то не понимаю?
-
Ну скорее всего в глм дефолтный порядок углов - xyz. Ты такой эйлер создал, он так дальше и живёт.
А в движке какой используется порядок для эйлеров? Если взять не тот порядок, то само собой будет фейл. И зачем промежуточные кватернионы, если ты можешь переводить эйлеры сразу в матрицы, не накапливая ошибок.
http://www.songho.ca/opengl/gl_anglestoaxes.html
-
А в движке какой используется порядок для эйлеров?
Я полагаю, такой же, только из-за того что оси другие, накладывать их надо в другой последовательности. Я преобразовывал оси, но это были условия для декартовых координат. Подумал сейчас, надо будет ещё кое-что попробовать. Спасибо за ссылку :).
И зачем промежуточные кватернионы, если ты можешь переводить эйлеры сразу в матрицы, не накапливая ошибок.
Ну, ошибки там смешные, это ж не техническое моделирование. :) А кватернионы - просто удобнее и все зависит, в первую очередь, от физического движка. Во вторую - от анимаций вора, которые я ранее не планировал, но раз вы тут все про них знаете, то почему бы и нет? В общем, когда физический движок подключу, станет понятнее, как дальше быть и в чем хранить.
-
Раз другие оси, домножал бы на матрицу-переориентировалку. Если пытаться в кватернионах что-то тасовать, можно себе такое адище устроить.
-
Раз другие оси, домножал бы на матрицу-переориентировалку. Если пытаться в кватернионах что-то тасовать, можно себе такое адище устроить.
Да, сами модели я так и переориентирую в итоге. Но размещение их на уровне надо обрабатывать через отдельные повороты по углам Эйлера в исходной последовательности. Я подумал и пришел к выводу, что тут ничего нельзя сделать из-за того что оси другие - только исходные оси и исходные повороты. Сейчас работает, насколько я могу судить, но всё равно есть странные модели, выглядящие разобранными (Thief 2):
camera02.bin
camera03.bin
camera04.bin
но они, вроде как, не используются в игре... Но всё равно, подозрительно.
Из используемых странно выглядят:
turnew0.bin
turnew1.bin
turnew3.bin
-
turnew0.bin
Эта состоит из одного подобъекта, там нечему разваливаться.
turnew1.bin
turnew3.bin
У этих иерархия корень-дочка-внучка, притом у turnew1.bin ориджины дочки и внучки чёрти где. Впрочем, их оси X проходят как надо для локального вращения.
-
nemyax
А у тебя есть возможность открыть эту модель в каком нибудь редакторе и посмотреть, целая ли она?
-
Я их импортировал в блендер, чтобы посмотреть. У turnew0.bin нету ни одного чайлда. Там разрушенная турелька единым куском, как я понял.
-
Так я про turnew1.bin
Можешь и фотку приложить
-
Force
Да удобнее будет тебе скачать блендер 2.79b и мой импортёр да и проверить.
-
Тебе - удобнее, да. Ничего делать не придется. :lol:
-
camera02.bin
camera03.bin
camera04.bin
turnew0.bin
turnew1.bin
turnew3.bin
Все они используются в игре, только динамически. Разные уровни тревоги = разные модельки (цвет лампочки).
-
Всё это планируется реализовать с ресурсами Dark Engine, поэтому логично ожидать от этого проекта появления какого-то игрового прототипа, внешне похожего на Thief.
Ты не думал вместо прямой поддержки этого шыта сделать конвертор в твои собственные форматы и избавить движок от совместимости со мрак-мотором?
-
Так я и использую по факту конвертер. У меня что структура миссии, что моделей - своя. Все загружаемые ресурсы на лету складываются в нужные структуры данных, и движок с ними работает. Когда достигну определенного запланированного этапа (когда набор данных устоится) - начну кэшировать эти структуры на диске после первого чтения. Для миссий это вообще позволит добиться практически мгновенной загрузки, поскольку будет грузиться только нужный кусочек уровня. Так что, да, фактически можно использовать любые форматы ресурсов - главное лишь написать для них "ридер" в формат движка.
-
Последние изменения
2020-01-14 15:00 MSK
- исправлено отображение уровней на видеокартах AMD
- отрефакторен рекурсивный обход BSP-дерева при открытии моделей, убрана рекурсия
- исправлено падение программы при открытии некоторых старых или поврежденных моделей
- откорректирована простановка доступных для выборки mipmap-уровней текстур
- добавлена отладочная схема отрисовки
-
Актуальная сборка
deviewer_build.zip (http://forcesw.com/deviewer_build.zip) 2020-02-05 23:30 MSK
Последние изменения
2020-02-05 23:30 MSK
+ исправлено отображение некоторых проблемных моделей, состоящих из нескольких костей
Наконец-то удалось выловить и исправить неприятный баг, способный весьма усложнить отображение моделей персонажей, состоящих из множества костей. Понимаю, что затянулось это значительно дольше чем ожидаемые две недели, но уж больно баг был досадный, нельзя было его игнорировать и приступать к персонажам. Теперь путь открыт. Наконец-то!
-
Актуальная сборка
deviewer_build.zip (http://forcesw.com/deviewer_build.zip) 2020-02-17 23:00 MSK
Последние изменения
2020-02-17 23:00 MSK
+ добавлена поддержка цветных полигонов в моделях
+ исправлено отсечение пути к текстурам, находящимся в одном подкаталоге с открытой моделью (информация о текстурах, отображаемая на экране)
+ различные внутренние оптимизации
В списке изменений информации не густо, но изменений много, хоть и мало заметных на первый взгляд. Была проведена довольно серьезная работа с моделями, устранены некоторые ошибки при поиске текстур. Исправлено падение программы в определенных ситуациях. Самыми заметными изменениями стали поддержка цветных полигонов моделей и исправление информации о текстурах, отображаемой на экране (если текстура находится в одном подкаталоге с моделью, абсолютная часть пути к текстуре отсекается).
-
Небольшой анонс для тех кто следит за темой. Это скриншот-загадка для внимательных тафферов, способных догадаться ЧЕГО ИМЕННО это анонс. Предлагайте свои варианты :)
(http://forcesw.com/i/dev_054_teaser.jpg)
-
Я угадал! Это анонс новой версии :yay:
-
:lol:
Да, так и есть :biggrin:. Но смена циферок скорее следствие ЭТИХ изменений. Каких? На всякий случай скажу, что это не модели персонажей. :suspect:
-
Тени мне на скрине нравятся. Может динамическое освещение? И да, я невнимательный, поэтому это последняя попытка.
-
Тени мне на скрине нравятся. Может динамическое освещение? И да, я невнимательный, поэтому это последняя попытка.
Хотел тут ещё понаписать всякого... чтобы облегчить поиски отгадки, но решил повременить пока.
Скажу только, что динамическое освещение и такие вот тени были с самого первого релиза просмотрщика :). Проблема только в том, что пока не добавлено интерактивное взаимодействие, никто не узнает что тени динамические :biggrin:.
-
Анонс грядущего прохождения "Патриота"?
Из необычного же на экране вижу только тень от AI (хотя можно ли приравнивать модель игрока к AI - вопрос для меня спорный). Выглядит все безупречно, практически как в редакторе (за исключением веселой рожицы). Раньше просмотрщик не позволял такого? Насколько я помню, были различные проблемы с отображением миссий. Здесь же никаких проблем не вижу.
-
Zontik
Насколько я помню, были различные проблемы с отображением миссий. Здесь же никаких проблем не вижу.
Всё верно, это практически ответ :), не хватает только сформулированного логического вывода, резюме так сказать :).
Из необычного же на экране вижу только тень от AI
Да, сейчас тени рисуются вообще от всего, даже от чего не надо...
Выглядит все безупречно, практически как в редакторе...
Приятно слышать! :)
-
Резюме - анонсируется полноценный просмотрщик миссий?
сейчас тени рисуются вообще от всего, даже от чего не надо...
На скриншоте видно не очень хорошо, но, кажется, тень есть даже от пламени свечи?
-
Рассказываю. ВНЕЗАПНО пишет мне PinkDot (Juliusz Kaczmarek, ему не очень нравится его ник) и говорит, что он знает как открыть миссии New Dark'а! Мы пообщались с ним, я поковырялся и всё получилось! Это было так неожиданно и так круто! Так что да, теперь это полноценный просмотрщик миссий, поддерживающий все их форматы!
На самом деле, требуется ещё воз и маленькая тележка доработок, чтобы действительно назвать просмотрщик полноценным, особенно это касается считывания всяких специфических связей и свойств объектов и правильного их применения. Но уже очень скоро выйдет новый билд, в котором можно будет открыть (на этот раз любую) миссию, увидеть все её текстуры и объекты, и полетать по ней.
Это выглядит ещё большим достижением на фоне моих (и всех, кто мне в этом помогал) неудачных попыток связаться с разработчиками New Dark и их уходом от ответственности (и от помощи).
Так что, я очень рад! :yay: Огромная благодарность выражается тафферу TTLG с никнеймом PinkDot aka Juliusz Kaczmarek! Его имя будет увековечено в благодарностях! :agree:
-
А меня всё подмывает спросить: а какой в этом всём замечательном и интересном, собственно, практический толк? К чему всё это можно приспособить с пользой для дела? Просто... открыть миссию и полетать можно и в дромеде.
-
Maxim
Уже сейчас у меня меньше проблем с просмотром миссии в просмотрщике, чем в ДромЕде. Я открываю эту же миссию, в папке FMs о она вся в Jorge. Ну и в софтваре, и мышку не поддерживает и в микроскопическом окошечке. Я спрашивал в теме, как со всем этим быть и как исправить, никто не ответил.
-
Здорово. Кстати, вот что ещё мне надумалось. Это более удобное создание скринов-анонсов. Летаешь такой по миссии и в нужном месте останавливаешься с "камерой". Опять же, можно и в дромеде, но не столь удобно будет.
-
А как выглядят AI в твоем просмотрщике? Поза по умолчанию? Если так, то ни о каких скриншотах с людьми и речи быть не может.
Для просмотра миссии в Дромеде вообще-то используется игровой режим, а не превьюшечный глазок. Так что с ним и надо сравнивать.
Насчет Jorge могу сказать только одно - такого не должно быть (да ты и сам догадывался). Где-то конфликт ресурсов. Но я не Борис, так что готового рецепта у меня нет.
-
Zontik
AI надо подождать. Да там и без этого ещё куча лишних объектов висит в воздухе - все триггеры видны, споты в виде лопат :lol:. Так что идея Максима со скринами не очень прокатывает пока.
Скажу так, если получится подключить AI-модели и их анимацию, можно будет сказать - дело в шляпе. Потому что сейчас только это осталось неизведанной территорией. Но ещё я видел, чего добился Juliusz (PinkDot) - это впечатляет, и если он подскажет, думаю, все будет хорошо. У нас будет всё. Это лишь вопрос времени.
-
Актуальная сборка
deviewer_build.zip (http://forcesw.com/deviewer_build.zip) 2020-02-26 20:00 MSK
Последние изменения
2020-02-26 20:00 MSK
+ добавлена поддержка миссий формата New Dark Engine! Ура! Особая благодарность выражается Juliusz Kaczmarek aka PinkDot!
+ незначительно ускорена загрузка миссий
+ при открытии миссии, камера позиционируется в стартовой позиции
+ класс цвета переделан на хранение данных в векторе с плавающей точкой, это обеспечивает лучшую точность
+ отключено "залипание клавиш", для предотвращения накопления смещений камеры при управлении интерфейсом
+ увеличена яркость режима просмотра миссий
-
Актуальная сборка
deviewer_build.zip (http://forcesw.com/deviewer_build.zip) 2020-03-06 14:00 MSK
Последние изменения
2020-03-06 14:00 MSK
+ уменьшен радиус SSAO и соответственно, bent normals. Последние теперь включены в финальную картинку, отчего она выглядит немного зашумленной. Отключить вклад SSAO и bent normals можно клавишей k.
+ увеличено значение FOV c 50 до ~74 градусов по вертикали, что соответствует FOV New Dark Engine.
+ переработано взаимодействие с объектной иерархией. Считываются свойства Render Type и Self Illumination, это позволило не рисовать лишние объекты миссии и исправило отображение теней от светильников.
+ исправлено смещение полигонов для обратного буфера глубины. Это предотвращает мельтешение теней (артефакты) при повороте или перемещении камеры.
Работа с объектной иерархией оказалась очень увлекательной. Я наконец-то разобрался со связями и увидел, как фантастически досконально DromEd позволяет взаимодействовать с объектами! Это обещает быть очень интересным!
Уже сейчас миссии должны выглядеть почти как в игре. В том плане, что теперь ничего лишнего не висит в воздухе. :)
Можно заметить, что я добавил в финальный рендер такую штуку как искривленные нормали - bent normals. Это фэйковый эффект, симулирующий некое подобие глобального освещения. Он добавлен временно и в будущем планируется он него уйти. Дело в том, что миссии вора в оригинале (даже в New Dark'е) отображаются с использованием статических лайтмэпов, которые считаются по сложным алгоритмам, на подобие рейтресинга в момент построения уровня (вы это прекрасно знаете и без меня :)). Это построение создает эффект мягкого освещения, особенно на перпендикулярных стыках стен, в углах.
(http://forcesw.com/i/reports/butler_original.jpg)
Когда же мы говорим про прямое освещение, которое обычно используется в реалтайме, то картинка начинает значительно уступать предрасчитанному лайтмэпу даже при тех же равных...
(http://forcesw.com/i/reports/butler_bent_normals_off.jpg)
Поэтому чтобы хоть как-то минимально скомпенсировать недостаток вторичного освещения, я добавил искривленные нормали:
(http://forcesw.com/i/reports/butler_bent_normals_on.jpg)
Да, результат получился очень спорным. Скорее всего, я даже использую эти нормали некорректно. Но, ещё раз повторюсь, в будущем их вообще можно будет выбросить в угоду глобальному освещению, а пока, если они так сильно мешают, их можно отключить клавишей k. Так что вопрос освещения остается открытым, но высказывать свои пожелания вы всё равно можете. Возможно, у вас будет какая-нибудь прекрасная идея, которую я не учел. ;)
-
C нормалями определенно не хуже, чем без них, хотя все равно достаточно плохо. Зачем и кому может понадобиться их отключать?
Но больше всего именно на этой картинке по глазам бьют даже не даркмодовские тени, а черная лампа. С этим-то можно что-нибудь сделать, надеюсь? DromEd каким-то образом интерпретирует данные текстур и заставляет светиться те из них, которым соответствующее свойство добавлено в 3D-редакторе.
-
Zontik
Да, черная (неосвещенная сама собой) лампа - это решаемо. Надо только найти как :). Мне в DromEd'е "удалось" только что сделать вот такое:
(http://forcesw.com/i/reports/lanterns.jpg)
Причем, мне не удалось сделать по-нормальному, хотя я ничего особенного для этого не делал. Просто поменял яркость у включенного и выключенного светильников. Надо найти свойство, которое отвечает за "свечение" самого объекта. Если ты или кто-нибудь ещё мне подскажет, буду очень признателен! :)
P. S. Таааакс... Вскрылись новые подробности, оказывается, это и есть свойство Self Illumination... Только что-то у него с наследованием не то :(.
P. P. S. Хотя не, всё то. Это я накосячил... простое решение не прокатывает, увы :(. Ну, зато, наступила ясность, знаю как починить лампы! :)
-
Я бы написал сразу, если хотя бы предположил, что ты этого не знаешь. Извини.
-
Zontik
Я почти ничего не знаю. У меня есть потроха, все видно, но как они взаимодействуют - приходится искать в туториалах по редактору для новичков. Поэтому, я буду рад любым пояснениям по любым вопросам, касающимся редактора.
-
У меня есть потроха, все видно
Ты и компилятор уровней накопал?
-
nemyax
Да не, я просто говорю про листинг чанков. У них у всех имена говорящие - одноименные с полями в редакторе. Сложность только в расковыривании формата их хранения, и какая логика стоит за ними. Если со вторым помогут местные умельцы, или не только местные, то вот с первым - как повезет. Пока что всё нужное мне встречалось в OPDE, но я недавно забрел в DromEd'е в такие интересные места, что OPDE такое и не снилось! :sly:
-
статических лайтмэпов, которые считаются по сложным алгоритмам, на подобие рейтресинга в момент построения уровня
Любопытно. То есть ты хочешь сказать, что в оригинальных алгоритмах учитывается переотражение света от объектов, поэтому светотень такая мягкая (т. е. используется radiosity lighting)? Действительно, в Dromed есть опции RayCast и ObjCast Lighting (никогда их не включал) - получается, это оно и есть?
Вторая картинка похожа на TDM. Кажется, я, наконец, начинаю понимать, почему там все выглядит таким угловатым (хотя в последние, гм, годы стало вроде бы получше). А третья в углах выглядит неестественной вообще (осветленный угол стены слишком бросается в глаза).
-
Chuzhoi
Любопытно. То есть ты хочешь сказать, что в оригинальных алгоритмах учитывается переотражение света от объектов, поэтому светотень такая мягкая (т. е. используется radiosity lighting)?
Вот ты сказал и я сам задумался. А ведь нет, действительно! Оно МОГЛО БЫ БЫТЬ ТАМ, но его нет.
(http://forcesw.com/i/reports/lanterns_no_radiosity.jpg)
Думаю тогда проблема в другом. В обратном подходе. Лайтмэп накладывается на абсолютно освещенную поверхность, тогда как реалтаймовое освещение пытается рассеять абсолютную тьму. В итоге лайтмэп не учитывает нормаль к поверхности, отсюда и равномерность освещения на всех "гранях" стены.
А третья в углах выглядит неестественной вообще (осветленный угол стены слишком бросается в глаза).
Меня тоже как раз это коробит, поэтому я и сделал эту штуку выключаемой, кому совсем плохо от неё станет :). Она ещё и исчезает у границ экрана при поворотах камеры как SSAO :cheesy:.
-
ВНЕЗАПНО!!! :aaa: На меня снизошло откровение! Убрал учет нормалей, поставил честную формулу затухания света и вот:
(http://forcesw.com/i/reports/butler_without_normals.jpg)
Идеально! :yay:
Ну, это работает так только с условием, что никаких других эффектов нет... Ну что, оставить пока так?
-
Думаю тогда проблема в другом. В обратном подходе. Лайтмэп накладывается на абсолютно освещенную поверхность, тогда как реалтаймовое освещение пытается рассеять абсолютную тьму. В итоге лайтмэп не учитывает нормаль к поверхности, отсюда и равномерность освещения на всех "гранях" стены.
А может, просто дело в элементарном разбавлении теней эмбиентом? На второй картинке эмбиента нет или он недостаточен, поэтому и углы такие резкие.
Любопытно, кстати, что тогда означают эти RayCast и ObjCast Lighting, если не radiosity. Кстати, в последнем нет ничего такого фантастического - уже в Quake 2 этот способ использовался.
Оффтопик: Кстати, вспомнил, что еще мне напоминает вторая картинка: освещение в классическом Unreal Engine (до второй версии включительно; в третьей, кажется, алгоритмы поменялись) с отключенной опцией Dark Corners (которая была включена по умолчанию). В этом движке использовался свой способ "оживления" освещенных примитивными компьютерными алгоритмами полигонов - затемнение углов. Видимо, по замыслу разработчиков, это должно было создать ощущение полумрака. Кстати, в редакторе на пустых комнатах это выглядело довольно неестественно, но в реальных игровых уровнях это вполне неплохо работало, придавая картинке своеобразный анриловский шарм.
Ага, обновление... Ну не знаю. На первый очень беглый взгляд вроде и неплохо, но на самом деле получается слишком примитивно - ведь между полигонами все-таки должны быть границы, а их тут совсем нет...
-
Вот еще два скрина.
New dark (тут видно, что учет нормалей уже сделан):
(http://forcesw.com/i/reports/butler_original_new.jpg)
Без нормалей, эта же миссия, исправленная для New Dark:
(http://forcesw.com/i/reports/butler_without_normals_new.jpg)
Да, в общем, надо это дело тюнить и обкатывать. Искать/составлять алгоритмы, удовлетворяющие нашим потребностям.
За себя могу сказать так: мне нравится вот этот, последний алгоритм затухания света, но когда он используется с нормалями в лоб, как раньше, он выглядит очень темным. Надо его как-то настроить, что ли?
P. S. Кстати, с этим затуханием искривленные нормали выглядят не так вырвиглазно. Гармонируют...
-
Действительно, в Dromed есть опции RayCast и ObjCast Lighting
Фактически это одно и то же, только в последнем прочитываются тени еще и от объектов, а в первом - только от брашей. Но они в корне отличаются от первого режима Quick Lighting, где все делается как-то неаккуратно (но резких теней там все равно нет, если не считать артефакты).
Как говорится, чем могу... Листинг чанков лучше обсуждать не со мной.
-
А какое свойство отвечает за то, чтобы фонарный столб начал отбрасывать тень хотя бы от других светильников? А то сейчас все фонари не отбрасывают теней вообще. Или это где-то в движке захардкожено?
-
На ttlg нашел:
the object itself casting a shadow (Object System > Immobile: TRUE)
Это оно! Кажется, даже Zontik уже про это говорил когда-то...
-
...вот только... Это совершенно унылый критерий для отбрасывания теней в современном проекте, потому что любой потенциально подвижный объект, типа ящика, бочки и т.п. тень отбрасывать не будет, потому что свойства Immobile у него быть не может. Пожалуй, приберегу это свойство до момента прикручивания физики, там оно даже семантически больше подходит, а для теней всё-таки использую Self Illumintation.
Насколько это будет объективная замена логики?
-
Не получится ли в результате этой логики так, что светильник при выключении перестанет отбрасывать тень? Просто не знаю, что происходит со свойством в результате включения/выключения. Это уже задача движка - интерпретировать действия игрока, в редакторе этого не посмотришь.
-
Zontik
А сейчас именно так и есть. Абсолютно все объекты, у которых нет свойства immobile, тень не отбрасывают никогда. Среди них все светильники, независимо от того, включены они или нет. Я же предлагаю наличие тени навесить на наличие свойства self illumination, причем даже с нулевым значением. Таким образом тени не будет только у светильников, которые могут или горят. "Мертвые" светильники, без свойства self illumination тень отбрасывать будут.
-
Это какая-то инопланетная логика.
Я же предлагаю наличие тени навесить на наличие свойства self illumination
"Мертвые" светильники, без свойства self illumination тень отбрасывать будут.
Так наличие приравнять к наличию или все-таки к отсутствию?
В общем, сначала действительно хотелось бы понять логику, чтобы потом уже ее обоснованно разгромить. Потому что решение такое представляется более чем спорным: какая вообще связь между способностью светиться и способностью отбрасывать тень? Это имело бы смысл только в случае, если бы в помещении допускалось не более одного источника света - тогда понятно, что самому от себя тень отбрасывать затруднительно. (И то спорно.)
-
В общем, сначала действительно хотелось бы понять логику, чтобы потом уже ее обоснованно разгромить.
Ты очень категоричен.
"Мертвые" светильники, без свойства self illumination тень отбрасывать будут.
Тут всё верно.
Я же предлагаю наличие тени навесить на наличие свойства self illumination
self illumination = 1.0 - тени нет.
self illumination = 0.5 - тени нет.
self illumination = 0.01 - тени нет.
self illumination = 0.0 - тени нет.
свойства self illumination нет вообще - тень есть.
Вот что имелось в виду.
Почему так? Предположим, если рядом стоят два фонаря, столбы, на которых они стоят не будут отбрасывать тень. Если один фонарь погасить рубильником, его self illumination станет 0.0 и он просто погаснет. Если же привязать тень к значению 0.0, то как только мы выключим один фонарь, у его столба внезапно появится тень, которой не было видно даже частично, хотя он горел очень тускло и её было бы видно, а это некрасиво и неправильно. Поэтому мы все потенциально работающие фонари теней лишаем, как и было в оригинале. Но даем тени никогда не работающим, чего в оригинале не было. Так же даем тени всем остальным объектам просто потому что можем, а Dark Engine не мог. Вот и вся логика.
Да, это тоже, в общем-то костыль, связанный с тем, что в оригинале светильники теней не отбрасывают вообще. Но это более логично, чем вешать тени только тем объектам, которые immobile.
Я планировал повозиться и сделать тени от всего вообще, только пофиксить светящиеся поверхности, которые раньше заслоняли свет, сделать так чтобы они тень не создавали и тогда всё станет почти как в реальности, но станет сильнее отличатся от оригинала, потому что теней станет больше, чего не предусматривали дизайнеры. Вот это вот решение и кажется спорным. В правильности же описанного в предыдущих абзацах я не сомневаюсь. Уверен, если бы не заговорил об этом, никто ничего бы и не заметил.
-
Ну и self illumination все таки связано с освещением. Другого подходящего свойства я не знаю.
-
Теперь понял. Ладно, разгром отменяется, раз уж придерживаемся подхода "как в оригинале". Меня смущает только то, что свойство Self Illumitation может назначаться не только светильникам, но и, например, огромному бойлеру с маленьким светящимся индикатором. Или вообще может быть назначено по ошибке объекту, которому оно вовсе не нужно. В то время как Immobile - это только слово, которое в реальности не имеет никакого влияния на подвижность/неподвижность объекта: его можно назначить хоть ящику, который поднимут и унесут, а тень от него останется лежать. То есть это слово-описание, а не слово-индикатор.
-
Меня смущает только то, что свойство Self Illumitation может назначаться не только светильникам, но и, например, огромному бойлеру с маленьким светящимся индикатором.
Гм, а ведь и правда! Об этом я не подумал... Почему-то решил, что такие части есть только у светильников. Можно поступить более топорно - смотреть на родителей объекта, если, к примеру, это lanterns - тогда тени не рисовать. Но это уже hard code и этого бы не хотелось. Но я сейчас пока не вижу другого способа сделать красиво и правильно. Потому что Immobile нет у половины объектов, а значит и теней не будет у половины объектов. Да это будет выглядеть как в оригинале... но для этого тогда есть New Dark.
В то время как Immobile - это только слово, которое в реальности не имеет никакого влияния на подвижность/неподвижность объекта: его можно назначить хоть ящику, который поднимут и унесут, а тень от него останется лежать. То есть это слово-описание, а не слово-индикатор.
Ну не, оно ведь имеет функциональное значение, хоть и немного странное - рисовать тени. А ещё странно, что объект при этом можно взять... Он же немобильный... :confused:
-
А вообще в чем задача: сделать движок для каких-то будущих проектов или для еще одной имитации оригинала? Потому что в первом случае аргумент "Immobile нет у половины объектов" звучит по меньшей мере неубедительно. Нет - так пускай автор сделает, в чем проблема?
С другой стороны, если имитировать оригинал, а в особенности ФМ - это означает, что выглядеть должно как минимум похоже на задуманное авторами. И где тени не запланированы - их как-то не совсем правильно добавлять.
В общем, я, наверное, чего-то не понимаю, так что тебе виднее.
-
"Immobile нет у половины объектов" <...> Нет - так пускай автор сделает, в чем проблема?
Immobile не подходит по семантике для всех объектов. Почему - я уже объяснял, если человек выставляет свойство "объект недвижим" - он таким и должен быть, иначе это профанация, а не редактор свойств.
Хотелось сделать "и нашим и вашим", но если консенсуса нет, я могу и не спрашивать. А то у меня такое чувство, что я не спрашиваю, а уговариваю, а это действительно странно.
-
Я вовсе не протестую, просто хочу, чтобы ты яснее представлял себе ситуацию перед принятием решения.
А вот эта фраза -
если человек выставляет свойство "объект недвижим" - он таким и должен быть, иначе это профанация, а не редактор свойств.
заставляет сомневаться, что ты все понял правильно и до конца. Ну, может, это просто игра слов. Уточню в последний раз, что свойство Immobile никак не обеспечивает неподвижность предмета и только путает не вполне адекватным названием.
А если ты нацелен в будущем на движок с физикой, то там это свойство станет исчезающе редким, если в нем вообще останется какой-то смысл.
-
Уточню в последний раз, что свойство Immobile никак не обеспечивает неподвижность предмета и только путает не вполне адекватным названием.
Я из этого сделал такой вывод - dark engine неправильно обрабатывает свойство Immobile, нужно сделать так, чтобы объекты, которым выставлено это свойство, оставались на своих местах всегда.
Но можно сделать другой вывод (который, судя по всему, ты и продвигаешь) - в DromEd'е свойство Cast Shadow названо Immobile и всё сейчас в игре совершенно нормально. Да, если считать так, то всё правильно, за тем лишь исключением, что у половины предметов нет теней. Даже у тех, которым бы они точно не помешали (стулья например). Отсюда снова напрашивается вывод, что свойство Immobile неправильно воспринимается дизайнерами миссий.
А раз в обоих случаях мы пришли к выводу, свойство Immobile всеми воспринимается неправильно, то нам ничего не остается, как сделать всё правильно самим - зафиксировать за свойством ровно то поведение, какое оно и обозначает своим названием - объект должен оставаться на своем месте абсолютно всегда. А это настенные факелы, бойлеры, баннеры, какой-нибудь закрепленный декор, который игрок не должен просто подойти и взять голыми руками. И если, например, бойлер нельзя будет взять из-за его массы, то факел - как раз из-за этого свойства. Ах да, логика DromEd настроена противоположным образом, ну, значит теперь будет иначе. По крайней мере до тех пор, пока не всплывут новые подробности или более подходящие свойства. Иного более элегантного выхода я не вижу. Есть ли они?
-
Но можно сделать другой вывод (который, судя по всему, ты и продвигаешь) - в DromEd'е свойство Cast Shadow названо Immobile и всё сейчас в игре совершенно нормально.
Ну да, лажанулись, когда придумывали название. А потом кривое название криво поняли дизайнеры.
-
А раз в обоих случаях мы пришли к выводу, свойство Immobile всеми воспринимается неправильно
Почему неправильно? Зонтик всё правильно объяснил. Свойство Immobile = true добавляет постоянную тень неподвижному объекту. В данном случае Immobile - означает, что предмет, которому добавляется это свойство, должен быть неподвижным. В принципе его можно добавить любому объекту, но в этом случае, если взять объект, тень останется на месте, поэтому его добавляют только неподвижным объектам. Или добавляют со значением false, если надо, чтобы неподвижный объект не отбрасывал тень.
И если, например, бойлер нельзя будет взять из-за его массы, то факел - как раз из-за этого свойства.
За это отвечает другое свойство (FrobInfo), Immobile - на это никак не влияет.
Да, если считать так, то всё правильно, за тем лишь исключением, что у половины предметов нет теней. Даже у тех, которым бы они точно не помешали (стулья например).
У стульев это свойство стоит.
-
Glypher
Ты не понял, видимо. Я говорю о том, что Immobile, по-хорошему, разрабам надо было бы переименовать в Cast Shadow. Всё.
Предположим, я - новичок, добавляю бочке свойство Immobile, ожидая, по названию свойства, что она будет неподвижна. Включаю игру, да у неё появилась тень, ура! Но что это, я толкаю бочку, она сдвигается, а тень остается на месте... Никакой это не Immobile, извините. И я не согласен с тем, что так и надо это дело оставить. Переименовать в DromEd'е я не могу, значит, у меня в движке это будет недвижимый объект. А уж с тенями придумаем что-нибудь.
При всем при этом, как новичок должен догадаться, что Immobile - означает "нарисовать тень от объекта"? А никак! Это ошибка именования свойства, как nemyax и сказал. Если ни у кого никаких новых соображений нет, предлагаю на этом вопрос Immobile закрыть.
-
И я не согласен с тем, что так и надо это дело оставить.
Почему не надо? Мало ли на свете дурацких формулировок. Их на нём даже большинство.
Если тебе надо самому отображать свойства, то переименуй у себя в Cast Shadow или Affect Lightmap. А обездвиживание обзови Static, например, чтобы не путалось с иммобайлом.
-
Я говорю о том, что Immobile, по-хорошему, разрабам надо было бы переименовать в Cast Shadow. Всё.
Теперь ясно. :) Согласен.
-
добавляю бочке свойство Immobile, ожидая, по названию свойства, что она будет неподвижна. Включаю игру, да у неё появилась тень, ура! Но что это, я толкаю бочку, она сдвигается, а тень остается на месте... Никакой это не Immobile, извините
Вот у меня такая же песня была всегда. И до сих пор, добавляя эту опцию, каждый раз думаю о нелогичности названия.
-
Все-таки уточню еще один нюанс. FrobInfo отвечает за взаимодействие игрока с объектом. Игрока, а не его физической модели! То есть позволяет объекту подсвечиваться и ожидать каких-то действий. А в примере с бочками взаимодействует именно физическая модель. Бочку можно зафиксировать флагами Location, Rotation или дико увеличить массу (сработает ли?), чтобы она не шевелилась при столкновении. Но нормального, адекватного, логичного способа "сделать объект неподвижным" (буквально!) как не было, так и нет. Те же упомянутые флаги не используются сами по себе, а входят в состав одного из физических свойств объекта (забыл название).
-
Zontik
Но нормального, адекватного, логичного способа "сделать объект неподвижным" (буквально!) как не было, так и нет.
Обожди, в игре же есть неподвижные объекты (почти все). Факелы, генераторы, стулья, столы... Скорее это у бочки есть какие-то свойства, которые делают её подвижной, разве нет?
-
У бочки отключены эти флаги - Location, Rotation, плюс физ модель тоже косвенно на это влияет. У бочек - сфера. Будучи приподнятой над уровнем пола (об этом должен позаботиться автор), при старте миссии она начинает падать, пока на столкнется с поверхностью. Это и дает ей подвижность. Если ее не приподнять, есть высокая вероятность, что при запуске миссии она провалится сквозь пол в бесконечность.
У столов и стульев модель OBB, при этом флаги фиксации установлены по умолчанию. Как и у всех подобных объектов.
То есть свойство, управляющее фиксацией, есть у всех, при этом у большинства объектов фиксация по умолчанию включена. Чтобы сделать тот же стол подвижным, придется превратить его в сферу, что может прокатить с более-менее кубическим столом, но совершенно не подходит для узких, длинных или низких. И положить на такой стол ничего будет нельзя. И выходит, что подвижность обеспечивается с куда большим напрягом, чем неподвижность.
Если же просто отключить флаги фиксации у того же стола, при входе в миссию ты в лучшем случае успеешь увидеть его крышку, прежде чем она провалится сквозь пол вслед за ножками.
-
То есть получается, что подвижные объекты в Dark Engine физически могут быть только сферами? А когда мы делали разрушающийся завод, его обломки тоже были сферами?
-
Zontik
Спасибо за информацию!
Какие-же всё-таки неудачные названия у свойств в DromEd'е! Совершенно неинтуитивные. При этом использовать их с толком будет довольно затруднительно как раз из-за их крайне специфического поведения в оригинале. Ну, то есть, я не могу в дромеде пометить стол как подвижный - у него либо тень пропадет либо он провалится сквозь пол :lol:, при этом мне не поможет даже сделать его физическую модель сферой - у меня он проваливается сквозь пол наполовину...
В общем, ладно, будем отстраиваться от того, от чего это в принципе возможно, на остальное успешно забьем... :embarassed:
-
А когда мы делали разрушающийся завод, его обломки тоже были сферами?
Конечно. Поэтому в подобных эпизодах нужно всеми силами не допустить игрока в зону поражения, иначе несоответствие видимой формы реальной сведет его с ума. Или делать обломки совсем мелкими, чтобы несоответствие не так бросалось в глаза.
То есть получается, что подвижные объекты в Dark Engine физически могут быть только сферами?
Точнее, сдвигаемые. Лифты - подвижны, двери - подвижны, анимированные модели - также подвижны. Их просто сдвинуть телом нельзя. Так что убогость вполне скомпенсирована.
Не буду врать - кажется, есть еще какая-то редко используемая форма (с почти всеми недостатками сфер) - кажется, именно она использована у ящиков, благодаря чему на них можно залезать. Но в целом это картину не меняет. И выстроить из ящиков пирамидку по-прежнему остается нетривиальной задачей.
-
Лифты - подвижны, двери - подвижны, анимированные модели - также подвижны.
Но ничто из перечисленного не вступает в коллизию с миром. Только с другими объектами и довольно специфически, избирательно.
-
Верно, я просто отмечаю, из-за чего Thief не кажется нам таким примитивным, как, казалось бы, должен.
-
Zontik
Верно, я просто отмечаю, из-за чего Thief не кажется нам таким примитивным, как, казалось бы, должен.
Да, у него уникальная система наследования архетипов. В ней ничего сложного нет, но она позволяет добиться невероятной гибкости, какая редко встречается в играх. В современных играх/движках, скорее всего, она есть и даже более совершенна, но на тот момент, с полной уверенностью могу сказать, аналогов у неё не было. Тут фактически вся логика выстраивается за счет связей, свойств и иерархии. В других движках за это отвечали отдельные компилируемые модули.
-
Сегодня, в день двадцатилетия второй части нашей любимой игры, я рад предложить вашему вниманию очередную юбилейную сборку Dark Engine Viewer'а, которая теперь поддерживает модели персонажей! Ура!!! :yay:
(http://forcesw.com/static/files/440/087/158491990087440.jpg)
Актуальная сборка:
Thief 2: The Metal Age 20th Anniversary build (http://forcesw.com/deviewer_thief2_20th_anniversary.zip) 2020‒03−23 01:50 MSK (UTC+3:00)
Последние изменения
2020‒03−23 01:50 MSK Thief 2: The Metal Age 20th Anniversary Build
+ добавлено отображение моделей персонажей (выражается благодарность Juliusz Kaczmarek aka PinkDot и Randy Sybel aka Shadowspawn).
+ затухание в шейдере переключено на квадратичное. Теперь свет затухает по законам физики, но от этого стало темнее.
+ клавишами "+" и "-" теперь можно менять яркость изображения в режиме свободной камеры.
+ исправлено наследование свойств объектной иерархии.
Кроме того, я обновил мой вебсайт: forcesw.com (http://forcesw.com/rus) На нем можно найти много новых скриншотов, и в будущем там будет появляться больше интересной технической информации о проекте и вообще... :biggrin: Буду рад, если вы расскажете о новой версии просмотрщика и моем вебсайте своим друзьям и в социальных сетях :)!
Хочется выразить благодарность Juliusz Kaczmarek aka PinkDot и Randy Sybel aka Shadowspawn, которые помогли приделать поддержку моделей персонажей. Возникла странная ситуация, когда формат прочитать можешь, все данные имеешь, а они не складываются в целостную картину. И так соберешь, и эдак - ну никак не получается. Помогли исходники BinToE, любезно присланные Shadowspawn'ом. В результате решение было получено, но результат нуждается в рефакторинге для поддержки анимаций персонажей. Мы же хотим анимацию?
Теперь, когда, наконец-то, долеланы все модели, мы достигли некоей устойчивой стадии готовности проекта. Была создана тема на форуме TTLG (https://www.ttlg.com/forums/showthread.php?t=150408), где я презентовал Dark Engine Viewer. Посмотрим что скажут англоязычные тафферы :).
Еще на повестке дня стоит запрос Максима о текстовом фильтре. Есть у меня мысли, как это можно сделать в рамках существующей реализации:
в интерфейсе начинаем писать символы и они сразу же появляются в строке поиска (не надо на нем кликать мышкой и делать фокус). А как только символов стало больше одного, список перестраивается и сразу же открывается первая модель этого нового списка. Следовательно, клавиша BACKSPACE не возвращает нас в предыдущий каталог, а стирает символ поиска. Как-то так.
Какие у кого мысли?
-
Увидел скриншоты на сайте и понял, что свет играет ТАК МНОГО. Только вот у меня вопрос, есть возможность создать такой динамический свет на движке?
Приеду в город обязательно посмотрю программу. А для каких целей она будет использоваться? Или это вещь сугубо для редакторов?
-
Увидел скриншоты на сайте и понял, что свет играет ТАК МНОГО. Только вот у меня вопрос, есть возможность создать такой динамический свет на движке?
А можно конкретнее, что именно имеется в виду? Какой свет? Какие скриншоты?
Приеду в город обязательно посмотрю программу. А для каких целей она будет использоваться? Или это вещь сугубо для редакторов?
Вообще, хотелось сделать вещь именно для игроков, дать им новый игровой и визуальный опыт. Я писал о некоем игровом прототипе в первом сообщении темы. А пока мы к этой цели движемся, разработчики миссий могут использовать Dark Engine Viewer для своих нужд, например, для поиска моделей. Сейчас, насколько мне известно, Dark Engine Viewer стал единственной программой, способной просматривать оригинальные модели персонажей без плясок с конвертерами, прямо из ресурсов игры. Обычные модели вроде как можно было, но это не точно. :)
-
Именно что "вроде как". Был просмотрщик, который как-то что-то иногда показывал.
Поздравляю с релизом! Ну а остальных - с тем, что остался год до совершеннолетия (компания-то американская, а по их законам Thief все еще числится в подростках).
-
Force, с релизом! :up:
Force, есть в планах сделать, чтобы показывалось и разрешения текстур, наложенных на модель?
-
Спасибо за поздравления!
Glypher
Force, есть в планах сделать, чтобы показывалось и разрешения текстур, наложенных на модель?
Не было, но если надо - не проблема. Боюсь только, как бы вьюпорт не стал слишком захламленным.
-
Поздравляю с майлстоуном!
А как только символов стало больше одного, список перестраивается и сразу же открывается первая модель этого нового списка. Следовательно, клавиша BACKSPACE не возвращает нас в предыдущий каталог, а стирает символ поиска. Как-то так.
Какие у кого мысли?
Я бы не хотел, чтобы фильтрация списка мне переключала текущую модельку. Лучше сам кликну куда надо.
-
Поздравляю с майлстоуном!
Спасибо! :agree:
А как только символов стало больше одного, список перестраивается и сразу же открывается первая модель этого нового списка. Следовательно, клавиша BACKSPACE не возвращает нас в предыдущий каталог, а стирает символ поиска. Как-то так.
Какие у кого мысли?
Я бы не хотел, чтобы фильтрация списка мне переключала текущую модельку. Лучше сам кликну куда надо.
Разумно, принимается!
А еще я подумал, что имеет смысл начинать поиск не со второго вбитого символа, а с первого, типа чтобы сразу "слистнуть" к нужной букве... Кстааааати! А ищем мы с начала строки или из любого места? Потому что из любого места найдет все-все вхождения, которые, скорее всего, не то что мы ищем, но с другой стороны мы можем помнить именно середину названия, а не начало. При этом на нужный символ начала строки можно просто промотать скролом. Поэтому, думается мне, что искать надо из любого места и всё-таки со второго вбитого символа...
-
Не было, но если надо - не проблема. Боюсь только, как бы вьюпорт не стал слишком захламленным.
Было бы неплохо. Можно завязать на хоткей - Показать/скрыть.
-
Поэтому, думается мне, что искать надо из любого места и всё-таки со второго вбитого символа...
А то и с третива. По-моему, если человек не в состоянии воспроизвести нужные ему три символа подряд, то он сам не знает, какого ч0рта он ищет.
-
Force, поздравляю с очередным релизом! И всех тафферов - с 20-летием Thief II: The Metal Age!
PS. Надо, наконец, запомнить, что Бассо одет в бордовое. А то мне все время кажется, что он в зеленом.
-
Chuzhoi
Спасибо!
Да, я тоже путаю его со слугой :).
-
Актуальная сборка:
Thief 2: The Metal Age 20th Anniversary build (http://forcesw.com/deviewer_thief2_20th_anniversary.zip) 2020‒03−28 13:00 MSK (UTC+3:00)
Последние изменения
2020‒03−28 13:00 MSK (UTC+3:00) Thief 2: The Metal Age 20th Anniversary Build
+ улучшен механизм определения каталогов с ресурсами игры. Теперь миссия, расположенная внутри любой директории игры, легко находит путь к ресурсам.
+ улучшен механизм поиска текстур для моделей. Добавлена поддержка вложенных каталогов по названию языка (правда, пока ищется только "english").
+ добавлена поддержка замещаемых текстур, описываемых параметром TxtRepl r*, где * - номер текстуры [0, 3].
+ увеличен максимальный лимит экспозиции (для повышения яркости клавишами + и -).
+ теперь в миссиях Thief 1 отображаются высокополигональные модели (при наличии).
+ добавлена поддержка открытия программы в нужном каталоге через передачу параметра в командной строке или перетаскиванием каталога на окно программы.