Да, не очень понятно о чём речь.

А так - стандартная процедура. Идёшь на сайт производителя видяхи, выбираешь модель и ОС, смотришь последнюю версию и ту, что у тебя. Если у производителя есть более свежая, то скачиваешь и смотришь. Перед установкой новой версии делаешь точку восстановления. Если всё хорошо - хорошо, если плохо - откат на точку восстановления. В этом смысле Вин10 от более ранних ничем особым не отличается.

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

Ещё возможен вариант железного глюка. Нужно посмотреть, что там с режимами работы видяхи. Может загнано что сильно вверх.

Что установлена и используется в корпорации :)

Тогда - действительно ...
Но вот насчет "гарантированного результата" я бы не был столь пессимистичен :ups: В конце концов, "Все мы люди-человеки, все мы любим чебуреки, ну и прочую такую благодать" ©, так шта-а-а :rolleyes:

А просьбы еще принимаются?
Прикрутить бы к границам окошка линейки измерительные Чтобы хотя бы в Orto проекциях присутствовали. А самый идеал по образу фотошопа измеритель клик при заданной нажатой клавише> потянуть> второй клик в конечной точке = в окошке расстояние 00.000м

Орто у меня нет, проекция всегда перспективная. Разный ФОВ для модели и кокпита. Линейками и т.п. пока я заморачиваться не буду. Хватает задач и без этого. :)

Ща чуть перепиливаю инициализацию, чтоб в случае проблем не валиться с ошибками. И по дороге саму отрисовку чуть меняю. Потом, кручение/сдвиги мешей и хуков. А ещё - второй текстурный слой не прикручен. А ещё - запись в bin msh не доделана. А ещё, ещё, ещё... :)

Хотелок у самого - вагон! :) Но вписаться и не сделать сильно хуже, чем сделать пусть и не всё, что хочется.

Вчера провел эксперимент - взял мешь из кабины спитфаера, конвертнул его в obj, поправил в Максе и выгрузил обратно в мешь. Результат прямо скажем не порадовал. Местами теряется мапинг, положение нового меша сбивается и т.д. Последующая доработка напильником займет очень много времени и к результату не приведет. Буду ждать другой формат для макса. :) Это было вступление... В процессе размышления меня посетила бредовая идея - а вдруг можно в готовом меше скрыть (удалить, отключить) некоторые полигоны? Вообще я хотел сделать открывающийся фонарь на спите 9. Очень часто все статичные элементы кабин объединяются в мешь Body. У спита все остекление фонаря это Body. Было бы супер взять и скрыть полигоны сдвижной части и на их место прилепить отдельный мешь. Такие операции вообще технически возможны или это фантастика? :)

По поводу конверта в obj - не могу ничего сказать, я с Максами/Блендерами не дружу от слова совсем. И с obj, в принципе, возможны проблемы по причине того, что формат достаточно простой и не содержит в себе многого необходимого. Про сбой маппинга, например, выше обсуждали, текстуру надо флипнуть по Y, а в obj это не указать.

Теперь маленькое лирическое отступление на тему того, как вообще функционирует отрисовка в ОГЛ и ДХ. Понимание этого позволит создавать более сложные модели и иметь при этом хорошую производительность. Те, кто в курсе этого, могут скипнуть следующие абзацы. :)

Фактически, что ОГЛ, что ДХ, это машины состояния. Условно - у нас есть конвейер. На него в определённом порядке грузятся команды. В соответствии с ними происходит изменение состояния конвейера. Вроде просто? Да. Но изменение состояния конвейера операция ОЧЕНЬ дорогая с точки зрения производительности. Это фундаментальная вещь в манипулировании с 3Д данными. При изменении состояния конвейера видяха должна синхронизировать все стадии внутренней обработки. Её внутренние конвейеры должны закончить обработку данных в пределах предыдущего состояния. А это приводит к тому, что на этот момент новые поступившие команды и данные не могут начать обрабатываться. Вот тут у нас и происходит основная потеря производительности. Если мы строим модели по определённым правилам, уменьшая кол-во изменений состояния конвейера до минимума, то решающими факторами для производительности будут пропускная шины для загрузки данных и скорость вывода готового результата на экран, мы таким образом будем приближаться к максимально возможной скорости обработки данных.

Основной девиз в 3Д - "Сортируйте всё, всегда, сортируйте максимально возможно!". Особенно в случае тяжелых операций, типа блендинга и ему подобных. Объединяйте части модели, использующие одинаковые настройки материалов в максимально крупные блоки. Разделяя модель на части старайтесь, чтоб части были максимально крупные, с минимально возможным кол-вом материалов. Внутри отдельных частей модели также сортируйте и объединяйте части по материалам. Режьте только там, где без этого не обойтись.

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

Ещё один пример. Тут выкладывалась модель с более чем 70к полигонов на лод. Почему она так шустро отрисовывается? Именно потому, что в ней фактически не происходит переключений состояния конвейера. Один раз загрузили данные, один раз установили стейты и потом всё, что мы делаем, говорим видяхе "рисуй!". Это очень быстро происходит, учитывая, что видяхи умеют кэшировать результаты промежуточных расчётов, которые не сбрасываются изменениями состояния конвейера.

Всегда помните и думайте об этом. Лирическое отступление - OFF.

В этой модели Спита полигоны объединены скорее всего именно по этой причине. Если часть модели монолитна, то выделять её в отдельный элемент очень вредно для производительности.

Теперь о самом вопросе.

Всё можно сделать. :) Но надо ли подменять собой профессиональные инструменты, которые именно под такой функционал заточены и умеют это делать на отлично? Они же, как раз, и созданы для разработки моделей. :) У нас немного другая задача - конверт данных, просмотр результата и чуть позже будет лёгкая манипуляция с готовыми частями модели (круть-верть мешей и хуков), то, что заменит ручную работу с форматами, неподдерживаемыми большими продуктами, чтоб из пушки по воробьям не пулять. В общем, пока у меня в планах нет задачи написания своего Макса, с "блекджеком и шл.хами". :)

Ясно, спасибо за ответ. :)

Прошу обратить внимание.
Всплыла бага 1с паковщика.
При запаковке в сфс меша содержащего хук
[HookLoc]
1 -5E-007 0 5E-007 1 0 0 0 1 0.8264 -0.00459003 0.00399995
этот паковщик вывернул хук на 90 градусов.
Проблема решилась правкой ручками.
[HookLoc]
1 0 0 0 1 0 0 0 1 0.8264 -0.00459003 0.00399995

Т.е. 1С тулза иногда подглючивает на форматах короткой записи чисел. Пока обнаружен только этот глюк, но возможно всплывёт ещё какой-то.

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

эээ. не проверил. сфску перепаковал, а старую удалил.

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

Если такое ещё раз вылезет, то будет очень хорошо, если мне закинете два меша, исходный и пакованный. Чтоб обнюхать можно было это дело со всех сторон.

Попробовал на 3х разных кокпитах. Может я что-то не так делаю, но мапинг частично слетает. Некоторые детали нужно отзеркаливать на развёртке. Некоторых вообще нет... В общем сделал небольшое видео для наглядности. https://youtu.be/Ms8A-dmaPiQ

Похоже, что надо ещё и свой экспорт из IMF в TGA делать...

Уже раза три рассказывал. :) В obj нет возможности указать каким образом мапить текстуру. У TGA в заголовке есть флаги с помощью который указывается какой угол изображения является нулевой координатой и каким образом нужно перевернуть текстуру перед отрисовкой/маппингом. Для редактирования obj необходимо флипнуть по Y те файлы, у которых этот флаг установлен (развёрнутых по X в игре мне не попадалось). Т.е., перед редактированием нужно перевернуть соответствующие текстуры по вертикали. А после редактирования - перевернуть назад, как было. Понимаю, что это неудобно. Но по другому ни как.

Самое плохое то, что часть текстур шарится между разными объектами игры. Я, собственно, именно по этому экспорт текстур и не делал, чтоб доп. путаницу не вносить. Просто если ещё и текстуры импортить, то может получиться замес с кучей развёрнутых по разному и в результате, уже в игре, могут возникнуть проблемы с теми объектами, которые не редактировались.

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

Почему при загрузке obj редактор не видит некоторых текстур - ХЗ. Надо смотреть по месту. Есть ли по этому пути текстура. А если она там есть, то является ли она TGA. Просто напомню, что IMF - внутренний формат игры. И хоть он и имеет расширение TGA, TGA файлом не является. И, соответственно, при попытке загрузить этот файл в Максе/Блендере у нас будет ошибка, ибо они про этот формат ничего не знают.

Блендер позволяет делать сетку, которую не позволит сделать 3д макс. Поэтому, его "экспорт" будет глючить намного больше. Что касается текстур, я взял родные, пересохранил конвертором ViewIMF-V1_0 в ту же папку, куда и экспортил в obj вашей утилитой. Очень суперская прога!;) Спасибо вам. Удобная и понятная. Но...
Некоторые текстуры отзеркалены, мешей не хватает. Если с текстурой понятно, можно перемапить, то нехватающие меши уже сложнее достать(мне совсем не понятно, куда они деваются).:(
Я понимаю, что это не простой процесс, который требует и времени, и желания. Ещё раз спасибо!

Я, конечно, совсем не спец в Максах/Блендерах. От слова "совсем". Однако рискну дать совет. Не надо "пепемапливать", менять развёртку. Это только бОльшее кол-во проблем создаёт.

Понимаете, мне ведь совсем не трудно при записи obj "перевернуть" текстурные координаты в тех случаях, когда это требуется. Но я осознанно это не делаю. Ибо потом, при обратном экспорте в игру, будет совершенно не понятно, надо ли опять у отдельных материалов "переворачивать" текстурные координаты. Ведь у материала нет атрибута, на который можно было бы ориентироваться.

Но если вы руками, для редактирования модели, перевернёте по Y те текстуры, для которых это требуется, то при обратном экспорте в игру вам не придётся ничего с текстурными координатами делать. Вы просто будете использовать оригинальные текстуры из игры, плюс свои, которые не расшариваются между различными моделями и для которых вы, как автор модифицированной/собственной модели знаете и самостоятельно задаёте нужный угол "нулевой" координаты. Это самый простой и логичный способ, позволяющий избежать лишней работы и потенциальных проблем. Всё это касается obj, естественно.

Я, в принципе, могу добавить в опции экспорта в obj "переворот текс. координат когда это требуется". Но при обратном экспорте вам придётся самостоятельно решать проблемы с обратным преобразованием. Повторю, мне это сделать абсолютно не сложно, но как будете выкручиваться вы при обратном экспорте в игру? Мне совсем не понятно, может я просто чего-то не понимаю.

Надо смотреть конкретно пути этих нехватающих объектов. Всё дело в том, что у игры есть определённая иерархия каталогов, объединяющая меши, материалы и текстуры между собой. Для экспортируемой модели ИЕРАРХИЯ ТЕКСТУР ДОЛЖНА повторять иерархию текстур игры. В этом случае всё должно подтягиваться автоматически. И если что-то не подцепляется, то нужно смотреть по пути к файлу что там конкретно с ним происходит, есть он, нет, правильный ли у него формат, или ещё какой косяк происходит. Перестраивать иерархию при экспорте я не буду. Ибо тут есть тоже куча возможных проблем, как с обратным экспортом, так и с самим сохранением. У нас ведь, в разных каталогах, могут присутствовать файлы с одинаковыми именами. И если ссыпать их в одну кучу, то "кто последний, тот и папа". И вообще хрен разберёшься потом в чём проблемы. В общем, смотрите пути, что по ним находится. Есть ли сам путь, и есть ли по нему нужное содержимое. Тут, увы, сильно помочь не возможно, архитектура игры накладывает на структуру каталогов довольно жесткие ограничения, нужно следовать принятым авторами игры правилам. По другому ни как.

Попробую ещё на более простых моделях. О результатах отпишусь.

Всех с праздником!

По этому поводу - релиз! :)

Версия 1.01 (билд 303)

Полностью переписал отрисовку моделек. В отрисовке полностью избавился от FPP. В результате имеем:

1) Должно рисоваться быстрее
2) Отображение теней, коллизий и нормалей меньше влияет на общую производительность. Владельцам небыстрых компов должно быть по легче.
3) Рисуется два текстурных слоя там, где это присутствует в моделях (всякие повреждения и дырки теперь выглядят нормально).
4) В кокпитах камера теперь выставляется на углы заданные хуком. Ctrl+F устанавливает взгляд в перёд, в направлении и под углом заданным соответствующим хуком камеры. Головой, естественно, можно крутить. В бомбовых прицелах камера крутится не по Y, а как при обычном взгляде. Это не правильно, но в игре нет явного атрибута, указывающего, что камера принадлежит бомбовому прицелу. Это задаётся в классе кокпита. Так-что, по другому универсально ни как.
5) В режиме сетки сделал более явное выделение выбранных в дереве мешей, подсвечиваю их синеньким цветом. Так, вроде, более наглядно и очевидно.
6) Для хуков и нормалей добавил возможность менять из размер/длину. Изменение размера отображается динамически (если включен показ хуков/нормалей, то при изменении размера это сразу видно).
7) Может что-то ещё забыл... :)

Хоть это всё и заняло у меня кучу времени, но теперь код отрисовки и шейдеры привёл к определённому порядку, избавившись от кучи следов эксперементов и огрызков левого кода (напомню, что программа эта - мой материал по изучению программирования 3Д :) ). Производительность можно ещё заметно увеличить, для этого есть хороший ресурс, но это уже потом. Главное - в результате всех переделок структуры кода теперь могу приступать к нормальному редактированию моделек, сдвигам/перемещениям мешей и хуков. Чем, по тихоньку, теперь и займусь.

Известный баг/фича: У некоторых моделей при отрисовке оверлеев может возникать z-fighting. По крайней мере у меня это происходит с Ил4 и некоторыми Жужами (Ю-88). Проблема связана с тем, что в моделях при повреждении иногда дырка может проходить через оверлей. Для того, чтоб в такой ситуации дырявился и оверлей нужно, что-бы соответствующим образом производилось сравнение глубины фрагментов основной модели и оверлея в месте отверстия, что-бы в оверлее отбрасывались фрагменты накрывающие отверстее. Высталение сооответствующего состояния для конвейера приводит к тому, что иногда, из-за конечной точности z-буффера, этот гадкий файтинг и вылезает. Видимо работу с глубиной тоже надо полностью перетаскивать в шейдер. В целом, у меня это случается не часто, заметил только на паре моделек, так-что это не должно особо раздражать и я не спеша с этим что-нибудь придумаю позжее.

Вроде особо ничего не забыл. Телеграфируйте о багах.

Ещё раз - всех с Праздиком!

Браво! :good:

Это просто праздник какой-то!