Все они от пакета 140 компиляторов


Тогда бы выбивало на нём. Он же динамечиский у нас. Косяк либо в sound_static.lib, либо в самом xrSound.

Я бы сказал, все они из debug-конфигурации. Откуда взяли sound_static.lib?

Ворбисы и прочая дрянь. Можно собрать в 3rd-party.sln

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

Zagolski, если бы у меня стояла последняя студия, я бы уже такие методы перепробовал. Тут у Винтаря(Аля ФЗ) проблема. Но, в целом, я позимичил немного с конфигами проектов. Если не поможет, буду уже сам обновляться и нормально разбираться.

Замутить асинхронную загрузку пред компилированного дерева
А вообще конечно надо чанки..

Всем привет. Кто нибудь может подсказать одну вещь. Я C++ не знаю.

В файле LEVEL есть чанк 0x3, который хранит визуалы в формате OGF. Некоторые визуалы/OGF имеют чанк 0xc (этот чанк есть у Multiple Usage объектов), который хранит данные о трансформации MU-модели. Эти данные представляют собой 16 чисел float (ну или матрица 4x4 из float чисел). Из этих данных удалось вычислить позицию MU-модели. Я обозначил её T, а всё что не известно X:

XXXX
XXXX
XXXX
TTTX

Можете подсказать, как из этой матрицы извлечь масштаб и поворот?

http://compgraph.tpu.ru/3d.htm

abramcumner, а как сделать преобразование такой матрицы в значения, которые были введены в СДК? Мне нужно получить позицию XYZ, поворот XYZ и масштаб XYZ.

А какой у тебя АПИ под руками? В здмакс есть decomp_affine.

abramcumner, я думаю у него Blender

Там тоже есть функция разложения матрицы: https://docs.blender.org/api/blender_python...atrix.decompose
Только как именно использовать не подскажу, питон не знаю.

да, у меня блендер.

Забыл

Вроде вот для блендера:

В блендере есть функции у матриц to_euler, to_scale, to_translation, но они почему-то выдают совсем левые значения. Может это из-за различий в системе координат?

Я создаю матрицу и не меняю местами элементы, может нужно в другом порядке матрицу записывать (чтобы компенсировать различия в системе координат)?

Я записал так:

transform_matrix = mathutils.Matrix((
(t[0], t[1], t[2], t[3]),
(t[4], t[5], t[6], t[7]),
(t[8], t[9], t[10], t[11]),
(t[12], t[13], t[14], t[15])
))

где t - это матрица трансформаций

в итоге у меня получилась матрица, но когда я вызываю transform_matrix.decompose(), то получаю совсем левые значения масштаба. Поворот тоже вроде левый (пока не проверял).

А позицию выдает правильную?
Попробуй транспонировать матрицу, а потом декомпоз делать.


На ум приходит только поменять столбцы со строками. Транспонирование как раз это делает.

abramcumner, транспонировал матрицу и всё получилось. Спасибо. Наконец-то теперь правильно будут импортироваться деревья. Чтобы удобнее в блендере анимировать камеру и создавать anm файлы (а то в слепую анимировать не получается без деревьев, вечно врезаешься в них).

Привет помогите решить проблему с вылетом собрал двиг ЧН при создании новой игры получаю вот такой вылет
Expression : fatal error
Function : CScriptEngine::lua_pcall_failed
File : ..\xrServerEntities\script_engine.cpp
Line : 192
Description : <no expression>
Arguments : LUA error: ...l.k.e.r. clear sky\gamedata\scripts\smart_terrain.script:330: attempt to index global 'gulag_general' (a nil value)

Скорее всего где-то выше по логу есть сообщение об ошибке в gulag_general.script.
Попробуй в файле gulag_general.script в строке 1149 удалить слеш перед scripts.

Привет всем маленький вопросик как реализовать линзы для прицеливание как в моде от шокера не подскажите или где примерно копать?

John_Wick, репозиторий шокера смотри. Мы в окси себе утащили эти линзы.

Можешь дать ссылку на репозиторий ?

John_Wick, в шапке всё.

Я у себя линзы (двойной рендер) сделал иначе, практически без падения скорости (что-то около 5% падает) и без задержек кадров. Шокеровский вариант все же сильно режет скорость, раза в два.
Если кратко, то никакие кадры мы не пропускаем, а рендерим два раза за фрейм. Сначала в основной рендертаргет, затем в дополнительный. При этом наш рендертаргет вдвое меньше по высоте, вчетверо меньше пикселей, и соответственно, вчетверо быстрее обработка. Больше разрешение не нужно, потому как линза один фиг только половину экрана занимает.
Там же отключаем отрисовку худа и остальное по желанию, что не нужно (например, рендер фларов от солнца). FOV меняем в начале второго прохода трансформацией матрицы, а отрисовку трассеров переносим из Level() в первый и второй проход рендера.

У меня такой вопрос: кто подскажет, в каком классе(классах) смотреть то, что касается взаимодействия актера с шейпами объектов(с аномалиями\рестрикторами\переходами) ?

AndreySol, в классах реализующих эти объекты(CCustomZone/хз/CLevelChanger)

Метод обновления, вызываемый шедулером, по-моему schedule_Update называется

ну и смысл хвастаться-то тогда без кода?) ну молодец конечно, только пользы от этого для моддинга никакой, если и дальше будет тенденция ныкать наработки по своим подвалам.

mortan, почему пользы никакой? Там есть совет, как это сделать более оптимально. Правда если уменьшен только один выходной рендертаргет, а не все рендертаргеты g-буфера, то прирост будет совсем небольшим.

А что, если рендертаргет вне линзы тоже рендерить с меньшим разрешением и мылить? Всё равно эта часть картинки вне фокуса.

А разве не большая нагрузка будет?

Вчера на дефолтном R2 сделал этот способ, действительно жрет скорость раза в два. Нужно оптимизировать. Да, из-за G-буфера... Посему получается, что тот способ, который я расписал выше, на дефолтной динамике не особо подходит.
Просто я у себя (для NLC 7 HSM) пилю новый рендер на базе статики (взял как базу), так сказать R5, по всем современным стандартам. Но у меня там не совсем отложенное затенение.

Постараюсь оптимизировать под R2 и выше и выложить код. Кто, как не мы сделаем Cталкер лучше? На нас, модмейкеров и движкоковерятелей вся надежда. Никто не собирается ни от кого таить наработки, ну разве что некоторые. Недавно анонсированный Сталкер 2 обещает быть мультиплеерной хренью, как и Fallout 76 (они там что, сговорились меж собой?). У нас сейас есть подобное - Тарков, но никак не Сталкер.

спасибо за пояснение

А вот это уже правильно. Пора уже разрушить капитализм в среде программирования

Верной дорогой идёте, товарищи!

У меня такой вопрос: кто подскажет, в каком классе(классах) смотреть то, что касается взаимодействия актера с шейпами объектов(с аномалиями\рестрикторами\переходами) ?

AndreySol, да ты же бот. Ты уже задавал такой вопрос, и тебе на него даже ответили.

Вынес зашитый в движок экран загрузки в XML. Теперь его, наконец-то, можно легко его изменять!
Кому интересно, можете посмотреть здесь, а кому интересно, как это было сделано – код в репозитории на Github.

Рендерить 3d static корректно на динамике все же можно. Тут нужно создать новый тип в графе для наших 3д объектов и отсеивать их туда из Draw самого CUI3dStatic. Ну и после отрисовки UI пускать на отрисовку наши 3д объекты. Все работает как надо.
Нам ведь нужно, чтобы объекты поверх UI показывались, как в билде. Либо можно их рендерить из CGameObject или из HUDManager, в этом случае они и так рендерятся без проблем. Но разумеется, поверх UI они отрисовываться не будут, только за ним. В этом случае можно сделать как в Скайриме, прямо в мире в пустом окне.
Не работает он на динамике по дефолту, потому как там отложенный рендер, а в нем сцена задолго до UI создается. На статике forward рендер, там этих проблем нет.

По поводу другого вида двойного рендера на оптику, о котором я писал выше, то на динамике R4 падение скорости ровно на 45% (55 фпс из 100) при одинаковой по качеству картинке (в линзе и вне). Не больше и не меньше. Изменение разрешения рендертаргетов роли не играет. Тут опять косяк deferred shading и ничего не сделать. Остается только добавлять новые каналы в G-Buffer (сколько их, восемь вроде на дх11 можно через MRT делать?). Тут главное снизить разрешение картинки вдвое по высоте, чтобы падение скорости было минимально.
Но в любом случае выигрыш есть даже так по сравнению с шокеровским способом, в первую очередь это отсутствие рассинхронизации кадров. Да и фпс побольше, чем там при 1:1. Да и кода меньше.

Надысь собрал xrSE_Factory через MinGW и столкнулся сразу с двумя непонятными проблемами.

Первая проблема это ошибка ЛУА 'setfenv' cannot change environment of given object. Происходит ошибка при вызове setfenv с единицей в первом параметре и (внимание!) только при загруженном xrCore или ещё чём-то от движка. Отдельно от движка всё зашибись. Ладно, опытным путём выяснил что ошибка появляется только при загрузке xrCore с инициализацией файловой системы, заменил LocatorAPI на ELocatorAPI, и ошибка пропала. Всё, вроде бы решил. Но не тут то было. При загрузке xrSE_Factory в ЛЕ ошибка появилась вновь. Дальше собрал ETools борландом, чтобы xrCore использовался только xrSE_Factory, для чистоты экспиремента, и стал пробовать загружать его из разных мест в коде. Дошел до того, что он нормально работает только если был загружен до загрузки погоды, а именно до такой строчки как R_ASSERT(_valid(sun_dir)).
Всё интереснее и интереснее.
Короче много чего я ещё пробовал. Пробовал обновлять луаджит с 5.1.3 до 5.1.4 версии, пробовал обычный луа, результат не менялся.
А помогла только сборка луадижта другой вресией GCC. А именно TDM 4.9.2. В более новых версиях которыми я пробовал собирать (4.9.4, TDM 5.1.0, 5.4.0, 6.4.0, 7.3.0, 8.1.0) эта ошибка есть.

Вот и как понимать эту наркоманию? Я такой везучий и опять нарвался на ошибку в компиляторе, которую много лет никто не замечает или всё-таки что-то где-то портит память или ещё какая бяка?

Вторая проблема с тем, что в IPropHelper для передачи строк используется shared_str. И почему-то от xrse_factory собранного GCC ЛЕ вместо ключей получает какой-то мусор. ИЧСХ, в остальных случаях shared_str ведёт себя нормально. Стоит ли вообще выяснять причину или просто переделать этот интерфейс на использование обычных C-шных строк? С моей точки зрения передавать shared_str как-то не очень аккуратно, т.к. это по сути указатель на контейнер, которым управляет xrCore, а xrCore в нашем случае два разных(xrSE_Factory использует xrCore собранный GCC, ЛЕ использует собранный борландом). Хотя у ПЫСов такой трюк прокатывал.

С этим разобрался. Как выяснилось это никакой не баг, просто разработчики GCC и разработчики борланда мыслят немного в разных плоскостях. GCC при передаче класса по значению создаёт его копию в стеке и передаёт функции указатель на эту копию, борланд передаёт без указателя.

Уот так уот

СамСебеСекретарша, ABI hell Элементы срр не переносимы между компиляторами, для пересечения границ можно использовать только С-шные конструкции.

Либо COM интерфейсы

Только и остаётся.
Но я пока решил ничего сильно не менять, а просто передавать shared_str ссылками.

С луа тоже разобрался. Оказывается его нужно собирать с -std=c90. Причина странного поведения всё-ровно не ясна, но такое решение меня уже устраивает

Методом тыка проверял или узнал где?

buffy, методом тыка.

А можете объяснить назначение xrSE_Factory в движке ? Он присутствует и в игре и в СДК, в чем его роль и смысл ?

AndreySol, если речь о делке, то в игре такой нет. Там какая то фигня находится, что то типа библиотеки с определением классов или хрен его знает - запамятовал. Сейчас придут гуры и объяснят нам.

В игре код из этой либы находится в xrGame.

Эта штука позволяет создавать серверные объекты. Я точно не скажу что это такое, не вникал как этот ваш алайф работает.
Редактором уровней используется для чтения/записи спауна. Там же составляется список свойств объекта для редактора.

Вроде больше ничего xrSE_factory и не умеет.

СамСебеСекретарша, я так и думал. Тама алспавн юзается.

Именно. В основном используется в xrAI.

Летим шпилить онлайн с картами ЧН?

Я новый проект начал. Чую скоро закончу.

Expropriator, летом скука смертная. Так что давай попробуем.