Jump to content
Korean Random

MasterModeley

User
  • Content Count

    37
  • Joined

  • Last visited

Everything posted by MasterModeley

  1. Удалось ли кому-то получить данные из gamedata.dat? Что-то моих знаний и умений не хватает
  2. Нужны файлы с расширением *.0 Это заголовки файлов, без них собрать сложнее и не факт, что будет правильно. Сконвертировал https://yadi.sk/d/9CZp1QQLQC6Z7Q "Соединить" текстуры у меня не получается, так как это карты шейдеров.
  3. Вы ошибаетесь. Я независимый исследователь :)
  4. Итак, есть ли какие-либо новые идеи? Собираюсь сделать следующую попытку разобраться в раскраске моделей.
  5. Удалось найти метод вытаскивания моделей? Формат файлов моделей настолько запутанный, что у меня получилось вытащить модели только частично.
  6. Это типа metalness и roughness для PBR шейдинга?
  7. Возможно, вам подойдёт вот это https://github.com/figment/hkxcmd
  8. Я не знаю, как и что там на самом деле, но делаю так: для packedVertices по 32 бита данных на вершину = 10 + 11 + 11 $tx = ( ( $packed & 0xFFC00000 ) >> 22 ) / 0x3FF; // $ty = ( ( $packed & 0x3FF800 ) >> 11 ) / 0x7FF; $tz = ( $packed & 0x7FF ) / 0x7FF; для sharedVertices по 64 бита данных на вершину = 22 + 21 + 21 $tx = ( ( $packed >> 42 ) & 0x3FFFFF ) / 0x3FFFFF; $ty = ( ( $packed >> 21 ) & 0x1FFFFF ) / 0x1FFFFF; $tz = ( $packed & 0x1FFFFF ) / 0x1FFFFF; Получаются нормированные координаты. Масштаб и смещение подбирается из параметров 'codecParams' и/или 'domain'. Найди меня в соцсетях или по почте [email protected]. Здесь я бываю редко и не всегда смогу ответить быстро.
  9. Модели бронирования, которые у меня на сайте, как раз выделены из этого файла. Это, по сути, обычная 3D модель с вершинами и поверхностями, в которой вместо цвета и текстур прописаны их физические параметры.
  10. Принцип, который там использовался, был не совсем правильный. После очередного обновления танков всё порушилось. Как уже писал чуть выше, правильная и полная информация находится в репозитории https://github.com/blueskythlikesclouds/TagTools
  11. Решить проблему "в лоб" оказалось слишком сложно. Пришлось серьёзно заняться гуглением. В результате нашёл кое-что полезное. Вот здесь https://github.com/blueskythlikesclouds/TagTools отлично расписано, что и как хранится в havok файле. После небольших исправлений cможет переварить файлы WoT. Тем более, в новой версии WoT формат havok очистился от лишнего.
  12. Из полученных данных я теперь тоже могу собирать такие модели https://i.imgur.com/RuBW8LS.png Однако это не совсем то, что хотелось получить. Вершины получаются правильные, но объекты - нет.
  13. Мне кажется, что эти "части" должны быть замкнутыми (возможно выпуклыми) фигурами , поэтому пересекаются друг с другом. Осталось научиться отделять значимые полигоны от служебных.
  14. Обязательно. Как только удастся получить вменяемую модель, сразу же всё расскажу и покажу.
  15. ОК. Разобрал структуру данных. Приступил к попыткам собрать геометрию.
  16. Колитесь, как вам удалось получить такое https://i.imgur.com/RuBW8LS.png ? Я погряз в разборе структуры данных.
  17. Предполагаю, что можно. Есть некоторые подвижки в изучении этих файлов.
  18. Внимательно присмотревшись к блоку TNA1 можно обнаружить его связь с TSTR: 8127 0000 hkRootLevelContainer 0102 hkArray 0203 tT 0304 tAllocator 0400 hkRootLevelContainer::NamedVariant 0500 hkContainerHeapAllocator 0601 0203 T* 0700 int 0800 hkStringPtr 0900 hkRefVariant 0A00 char* 0B00 0601 020A hkReferencedObject 0C00 hkBaseObject 0D00 0000 hkPropertyBag 0E00 char 0F00 hkMemoryResourceContainer 1000 0102 0215 0304 0102 0217 0304 hkResourceContainer 1100 hkResourceBase 1201 hkRefPtr 1319 0601 0215 1201 1310 0601 0217 tTYPE 1400 0601 0219 0601 0210 hkMemoryResourceHandle 1500 0102 021E 0304 hkResourceHandle 1600 0601 021E hkMemoryResourceHandle::ExternalLink 1700 0102 0223 0304 HKBodyFlagsData 1800 hkVector4 1900 0601 0223 HKBodyFlagsData::Info 1A00 hkVector4f 1B00 hkInt64 1C00 unsigned int 1D00 float 1E00 long long и т.д.
  19. Если в нем и есть hkx файлы, то скорее всего их запихнули в ba2 архивы. Распаковщик https://gamer-mods.ru/load/skyrim_se/instrumentarij/bethesda_archive_extractor/151-1-0-4758
  20. К сожалению, там слишком маленький тестовый файл. И на первый взгляд он не имеет ничего общего с исследуемой версией.
  21. Вот до чего я пока докопался в staticModules_default: - блок TAG0 - блок SDKV : версия SDK в текстовом виде - блок DATA : данные геометрии и физики (?) - блок TYPE - TSTR : строки (в большинстве с префиксом hk* ) - TNA1 : ? - FSTR : строки (имена параметров?) - TBDY : ? - TPAD : ? - блок INDX - ITEM : массив индексов { uint32 флаги(?), uint32 позиция в блоке DATA, uint32 количество (не размер!) данных } Причём, блок TYPE кажется одинаков для всех файлов(?) Может ли кто-нибудь кинуть в меня "типичный" havok файл, который можно конвертировать hkxcmd и посмотреть, что в итоге должно примерно получиться? Можно бросаться уже конвертированными.
  22. Подводем итоги проведённым изысканиям. Рассмотрим подробно принципы формирования новых текстур на примере шасси Сфинкса. Материал определён в файле "\Objects\vehicles\afv\sphinx\sphinx_hull.mtl" и имеет вот такой вид: Перебирая "Item" в "Layers" мы можем получим набор цветов, соответствующих "LayerKey". Для этого надо исследовать файл материалов, определённый в "Material". Например, для "RubberRaw" это будет файл "/materials/at_materials/rubberraw_01.mtl": Здесь нас интересует атрибут "Diffuse", мы и будем использовать. В нашем случае это чёрная резина с цветом #050505. Составив таблицу цветов, займёмся файлом "/objects/vehicles/afv/sphinx/textures/new/wheels/id.xml" в котором описаны материалы и их слои: Мы видим три материала из 4-5 слоёв. По идее, вместо вычисленных выше цветов можно просто использовать текстуры, определённые в этом файле. Но найти их мне не удалось. "BaseLayer" определяет цвет основы, на которую наносятся остальные слои. Интенсивность первого первого слоя определяется R каналом в файле "/objects/vehicles/afv/sphinx/textures/new/wheels/w.dds", интенсивность второго, третьего и четвёртого слоёв каналами G, B и A соответственно. Файл "/objects/vehicles/afv/sphinx/textures/new/wheels/id.dds" в красном канале содержит карту применения того или иного материала. В нашем случае пикселы с R == 1 соответствуют материалу с <Palette id="1"> и т.д. В результате, алгоритм расчёта пикселя тестуры выглядит следующим образом: 1) выбираем пиксель из w.dds и раскладываем на каналы как R, G, B, A 2) выбираем соответствующий пиксель из id.dds и выбираем R канал как M 3) если M == 0 - пиксель не используется 4) выбираем Palette с id == M как P 5) выбираем цвет как СOLOR из таблицы цветов для P[BaseLayer] 6) для каждого слоя P[Layer] выбираем соответствующие цвета из таблицы цветов как cl и смешиваем с СOLOR используя (R, G, B, A): COLOR = blend( COLOR, cl, {R, G, B, A} ) 7) закрашиваем пиксель текстуры цветом COLOR
  23. Нет. Это зоны применения того или иного материала/шейдера. Причем "синий" шейдер для колёс это не то же самое, что и "синий" для корпуса или башни. Но ваша теория очень интересная. Попробую проверить её.
  24. Я рендерю у себя на сайте. Там нет такой возможности. Либо неправильно читаю UV из сgf. Надо будет еще со смешением цветов поэкспериментировать. Пока результат мне не очень нравится.
×
×
  • Create New...