Тут возникает довольно серьёзная проблема, когда скомпилированный пакет не имеет каких-либо идентификаторов от системы сборки. И нет никаких средств проверить целостность, атрибуты и единство пакета, который был собран самостоятельно и внедрён в систему или локальное окружение помимо репозитория. В основном упор идёт на дату и номер версии, а также то что если изменить 1 байт - это уже новый пакет. Поэтому в системе разрастается зоопарк версий, особенно весело когда программа тянет за собой двоичники необходимых зависимостей, что для .NET что для MSVC redistributable, .deb/.rpm могут притянуть различные только им нужные .so, Python 2.7/3 - уже стало именем нарицательным, если песочница использует символические ссылки - уже достижение. В подавляющем большинстве случаев весь этот довесок летит в Program Files или bin. Вообщем по-всей видимости без инфраструктурных изменений вряд ли что-то можно улучшить существенным образом.
Проблема в CubeIDE и прочих визуалках без обратной связи из исходного кода "наверх" - невозможность динамической реконфигурации. Иными словами, допустим, в какой-то момент необходимо переключить ШИМ в шестишаговый режим, пробросить UART сделав Remap пинов, по ходу дела менять режимы DMA например. То есть система программируется изначально как нечто статическое. Конечно для большинства простых задач этого хватает но на специализированных применениях это может создать больше проблем. Плюс HAL/LL вместо регистров это отдельная тема, попытка языковыми средствами из 70-х с надеждой на упорство компилятора создать абстракцию, вроде как ООП на С, и да и нет, в итоге проще сделать какой-нибудь кодогенератор и единственный заголовочник.
Имеется в виду то что до сих пор в качестве аргументов используются различного рода вещи, которые тянутся из того что нужно собрать в систему сборки, не важно какого высокого она уровня. Иными словами включить/выключить CUDA/AVX/SSE, сделать море #define-ов, сгенерировать какой-либо .pm итд. То есть до сих пор нет каких-то встроенных в сам язык средств, поддерживающих сборку, иными словами требуется пересмотр самого принципа текст-компилятор-редактор связей-отладчик с наличием утилиты в этом механизме, отвечающей за сборку, включая данные о распределении памяти, опции подключаемых библиотек, версий, причём, инвариантно к именам/расширениям файлов, собирая непосредственно объекты и функции но это уже не задача make. До сих пор системы сборки и контроля версий по-сути обёртка на принципы работы и тулкиты, которые были ещё с середины 80-х. В даже в настоящее время проект - это просто папки и набор файлов в них с описанием того что нужно с этим сделать, вместо указания того, что нужно сделать непосредственно с их содержимым.
CMake медленно но верно как было замечено превращается в уже почти в графическое IDE. Наверняка уже завезли вещи связанные с Git, проверкой версий пакетов онлайн, среды окружения, тестирование самого компилятора на правильность. Но опять-таки краеугольный камень - что он не заходит внутрь файла забрать пользовательские идентификаторы, ориентируется на время/дату и прочие системные штуки при обновлении, не создаёт атрибутов файлов или дампов этапов построения с обработкой исключений при ошибках компиляции с целью не прервать процесс а максимально скомпилировать всё что без ошибок. Ну и разумеется танцы с макросами и зависимыми переменными. Вообщем скорее всего этот инструмент поглотит некий perl/python с явной кодогенерацией по шаблону из мета-языка, пригодного для конкретного применения, включая тот же bash/bat для сборки (локальной/тест/релиз). CMake же пытается объять необъятное и уже требует ненулевой порог входа для обучения.
Turbo C также мог по Ctrl+F9 собрать и запустить, подсветив код не хуже чем сейчас. Это был где-то 1998й год, всё влезало на дискету 1.44. Тогда были обычные make, и сейчас тоже самое, главное чтобы батарейка у биоса не села и не сбросила незаметно время. В качестве пакета - lib с заголовочниками, директория с датой - версия, bat-файл для всего остального. Практически за 30 лет лишь косметические изменения. Если бы тогда спросили у будущего: до сих пор используете файловые системы для структурирования проекта? Представлен очевидный ответ. Интересно, есть ли у этого процесса хоть какая-то интегрированная прямая поддержка со стороны IDE.
Кроме этого добавить ещё гамма- и радио-всплески (видимые в электромагнитном спектре), слияния чёрных дыр (видимые в спектре гравитационных волн), частицы сверхвысоких энергий в тераэлектронвольт из точечного источника (в спектре корпускулярного взаимодействия), детектирование всплесков нейтрино (спектр косвенного взаимодействия с веществом) скорее тут даже можно расширить на саму природу возникновения вспышки. Вот бы ещё выявить изменение или вспышку на фоне реликтового излучения, это самое интригующее было бы, некое событие эпохи рекомбинации.
Навскидку, поправьте ели не так, есть разница между nova и supernovae. Нова - это в принципе яркое астрономическое явление, а далее его классифицируют как переменную "катаклизмическую" звезду (бывает и такое что звезда блекнет, как Бетельгейзе, помнится зимой 2020 стала заметно тусклее) или сверхновую, для белого карлика Ia при превышении предела Чандрасекара аккрецией вещества.
Также, не задавайте в моделях параметры из разряда фемтофарад , наногенри, тераомы и др, что частенько приводит к singular matrix error, или к зависаниям на коммутациях. И шаг счёта для лучшей сходимости и устойчивости решения по порядку величины равной минимальной постоянной времени схемы, как раз определяемой этими параметрами вроде итд, иными словами, обусловленность системы. Деление практически на 0 делает большую величину, из-за нелинейной разрядной сетки даже для double сумма с большим числом есть само число. Адаптивный шаг счёта, определяемый этими постоянными времени и LC-контурами приводит к уточнению reltol на уровне сотен МГц для схемы в 50 Гц при каждой коммутации.
Раньше были обычные справочники для основных параметров, которые определяют скажем так основное назначение. Особенно про транзисторы из разряда КТ315 или МП42Б. Давались только минимальная бета, ёмкости, обратный ток, температурное сопротивление кристалл-корпус/корпус-среда и другая мелочёвка. Из этого уже можно было построить малосигнальную или нелинейную модель для расчётов "вручную". Из предельных характеристик также, напряжение пробоя, максимальное напряжение база-эмиттер обратное косвенно вытягиваются остальные параметры. Вообщем фактически воссоздать характеристики по их кусочно-линейным аппроксимациям.
Лучше исключить Is сразу же, используя предел , так как действительно чувствительность к прямой ветке слишком высокая и использовать его как параметр.
Ещё бы дополнительно сравнить температурные зависимости ВАХ, особенно для расчётов тепловых потерь, увеличивающихся с ростом температуры. В даташитах обычно приводят для -40, 25 и 85/105/125). В принципе можно параметр неидеальности n вынести в числитель как и можно будет использовать линейный МНК.
Также можно использовать аналитическое решение для МНК с уравнением прямой, раз уж используется Maple/Maxima. Аппроксимацию сделал сразу для "ступеньки" функции ВАХ в общем виде, используя точку Vce0.
Как-то строил для транзистора получается примерно следующее
А для анализа характеристик обратного восстановления - включить в ЭДС небольшие катушки (процентов 5-10, обычно равные напряжению к.з. трансформатора/сети. ), чтобы они создавали угол коммутации .
Также, по заряду обратного восстановления можно ориентировочно вписать в параметр ёмкость диода. Помимо этого конечно есть ещё эффект варикапа но для силовых диодов это не актуально.
Да, магнитные сейчас довольно хорошие, небольшая проблема - держатель магнита с диаметральной намагниченностью, обычно делаемый 3Д-печатью и заливкой эпоксидкой, хотя некоторую кривизну можно довольно неплохо исправить программно полиномом или таблицей.
Интересная задача. Попытался посмотреть аппроксимацию нелинейности звеном
Скрипт в Maxima для нахождения параметров колебательного звена
Программа
V1:b[0]/(a[2]*p^2+a[1]*p+1)
/*Переход к КЧХ*/;
V2:p=%i*2*%pi*f;
/*Комплексно-частотная характеристика КЧХ*/
V3:V1,V2;
/*Мнимая и действительная части*/
V3R:realpart(V3);V3I:imagpart(V3);
/*Точка с нулевой фазой - действительная часть равна нулю (частота свободных колебаний)*/
V4:solve(V3R=0,[a[2]]);
/*находим в точке f0*/
V5:V4,f=f0;
/*Подставляем в исходное выражение*/
V6:factor(V1),V5;
/*Обратное преобразование Лапласа (получение импульсной характеристики)
выбрать n - дискриминант отрицательный*/
V6i:ilt(V6,p,t);
/*Амплитуда при синусе при t=0*/
V6a1:V6i/sin(2*%pi*f0*sqrt(1-%pi^2*a[1]^2*f0^2)*t);
V6a:V6a1,t=0;
/*В самом начале амплитуда равна значению в точке A*/
V6b:V6a=A;
/*решение для корректировочного коэффициента b0*/
Vb0:solve(V6b,b[0]);
assume(τ>0,f0>0);
/*Постоянная времени переходного процесса*/
V7:2*%pi^2*a[1]*f0^2=τ;
/*Решение для коэффициента a[1]*/
V8:solve(V7,a[1]);
Vb01:factor(Vb0),V8;
/*Нахождение постоянной времени по уровню*/
V9:A*exp(-τ*t0)=B;
V10:solve(V9,τ);
/*Нахождение численных параметров
по графику f0 - за 16+1/4 периода время 15 секунд
точка A в самом начале, точка B - 10 периодов
*/
V11:[f0=(16+1/4)/15, A=39, B=10];V111:t0=10*f0,V11;
/*полный набор численных параметров*/
Num:push(V111,V11);
/*Постоянная времени*/
V12:V10,Num;;
Num1:append(V12,Num);
Vbn:factor(Vb01),Num1;
/*коэффициенты a1 , a2, b[0]*/
V13:[V8,V5,Vbn],Num1;
float(V13);
/*подстановка в импульсную характеристику*/;
V14:factor(-V6i),[V13,Num];
wxplot2d(V14,[t,0,25]);
В итоге получилась следующая аппроксимация звеном вида :,
при этом, . В результате имеем следующую импульсную характеристику (с нулевыми начальными условиями, в исходной модели, видимо, они не нулевые, -40 начальный угол)
Импульсная характеристика линейного звена второго порядка
Видно, что +- график одинаковый с точки зрения общей "энергетики" переходного процесса. В конце имеется в оригинальной модели статическое значение порядка -2, и более быстрая диссипация, связанная с сухим трением (вязкий коэффициент). Поэтому для управления целесообразно рассмотреть применение корневых методов для линеаризированного объекта управления. Что касается замкнутой системы то желаемый результат есть фактически предельно апериодический процесс с кратным апериодическим полюсом. В этом случае все полюса расположены рядом в левой полуплоскости на действительной оси. Как только появляются комплексно-сопряжённые полюса, то имеется перерегулирование. Чем левее они расположены - тем быстрее, но тем больше может быть всплеск, также он характерен и для апериодического процесса с разнесёнными постоянными времени. Круговая частота колебаний определяется мнимой осью, постоянная времени - действительной. В этом случае полюса рационально расположить в секторе порядка 45 град исходящего из нуля, там будет и быстродействие приемлемое и колебательность небольшая. Также ПИД-регулятор с таким объектом сразу в замкнутой системе даст 4й порядок (2+2). Поэтому рационально использовать компенсатор. Очень грубо он может быть синтезирован из указанного выше объекта управления как режекторный фильтр , то есть как обратная передаточная функция с вспомогательным дважды апериодическим полюсом . Компенсатор позволяет "выровнять" АЧХ объекта управления, но уменьшает быстродействие. В этом случае он ставится в ошибку управления и к нему суммируется интегратор (и небольшая пропорциональная составляющая), либо на выходе интегратора, для таких объектов производная (дифференциальная) - явный путь к автоколебаниям, интересно взглянуть на результаты оптимизации по времени на соотношения этих постоянных времени, скорее всего дифференциальная будет практически нулевой. Ну и разумеется возможность применения апериодического управления - deadbeat control, но это только для дискретных систем.
Нет, маленько не так, мультиплеер может содержать элементы, который производитель игры хочет скрыть, ну вроде как все хотят чтобы ЗП капала за ПО, принимаем как должное. Поэтому невозможно будет описать сцену без скрытой физики, например, в мультиплее помимо людей ещё что-то делает ИИ а также меняется сцена по какому-то алгоритму или сюжет, которого нет в синглплее. В этом случае конечно же будут пакеты которые помогают эти изменения прорисовать. На клиентской стороне только текстуры, полигоны, звук/миди, базовая физика которая в общедоступном движке ну и по мелочам сетевые протоколы и локальное хранилище. Всё остальное уже в облаке. Мало того, если канал совсем небольшой то передаваться может "усечённая сцена" или отсутствовать мелкая моторика у персонажей.
Кстати вроде как подобный метод с переменным сжатием используется в DJVU. Там получается так что делаются из изображения слои, каждый слой это свой пространственный фильтр низкой частоты грубо говоря (например, усреднение по соседним точкам). Как только производная от изменения яркости становится большой (или в спектре появляются ВЧ-составляющие) применяется уже более мелкое сжатие локальной области. То есть сжимаются уже не исходная картина, а разбитая на эти слои, потом они снова складываются-восстанавливаются.
Имеются ли артефакты на границах блоков? Сжимается только покадровое изменение картины? В библиотеках самого jpeg вроде как имеется уже возможность поиграть с размером блоков DCT (lossy), а затем ещё поднастроить результат квантования (lossless).
Всё верно, речь идёт не о сервер-рендеринге а именно об этом действии на машине пользователя, которая выступает в качестве визуализатора, содержит терабайты текстур, демок, интро итд а по факту принимает поток графа сцены, который уже можно протолкнуть через узкополосные или падающие каналы. При этом, действительно, механика и прочее поведенческое "ноу-хау" (чтобы скрыть от читер-крякеров) из разряда ИИ, отрабатывается на игровом сервере. Вообщем это что то среднее между тонким клиентом и сервером.
Для антарктической экспедиции, когда охота поиграть с друзьями на другом континенте а видос через исчезающий Старлинк или другой спутник на высоких широтах уже не прогнать через .
Именно так! Пользователь освобождается от бремени переноса к себе бинарников геймплея и физики, которые лежат на сервере а на его стороне лишь тонкий клиент с GPU для отрисовки. Аналогично все САПР-ы. Мало того, там автоматом виртуальная флешка с ключами привязанные к ГлобалУслугам (эту тему кстати не только у нас курируют, взять те же корневые сертификаты) с биометрическим ID. Ну и соответственно трафик может быть для векторной графики из разряда US Robotics 56k
А если геймплей охота глянуть через спутник, ASDL, диалап, пусть даже и спустя сотню миллисекунд, может там MMORPG 8k, такая где нужно увидеть на экране пиксель чтобы разгадать где спрятался юнит, сжатие без потерь не пойдёт, канал не позволит, с потерями - будет один большой блюр на весь экран с косинусными артефактами. То есть это потенциально индустриальная задача, когда разработчики игры, CAE/CAD/CAM могут движением мыши сгенерировать легковесный вьюер без игрового движка (99.9 это текстуры и полигоны), чтобы можно было смотреть на удалёнке что происходит, делать туторы и классрумы под сотню человек не напрягая связь. Причём это может быть универсальное решение в виде некой стандартной либы под CPU-GPU, что-то как раз из разряда x11-ов и Wayland-а, только более адаптировано под эту задачу, включающую обработку таймаутов, лагов и непрорисовок (пока что эти интерфейсы подразумевают идеальную связь)
С нетерпением жду что же есть на самом деле межзвёздный объект 3I/ATLAS с самой большой на данный момент избыточной скоростью. Как раз в сентябре вроде как будет максимум (потом наступит соединение с Солнцем) с яркостью 11, но это уже серьёзный телескоп нужен для этого.
Тут возникает довольно серьёзная проблема, когда скомпилированный пакет не имеет каких-либо идентификаторов от системы сборки. И нет никаких средств проверить целостность, атрибуты и единство пакета, который был собран самостоятельно и внедрён в систему или локальное окружение помимо репозитория. В основном упор идёт на дату и номер версии, а также то что если изменить 1 байт - это уже новый пакет. Поэтому в системе разрастается зоопарк версий, особенно весело когда программа тянет за собой двоичники необходимых зависимостей, что для .NET что для MSVC redistributable, .deb/.rpm могут притянуть различные только им нужные .so, Python 2.7/3 - уже стало именем нарицательным, если песочница использует символические ссылки - уже достижение. В подавляющем большинстве случаев весь этот довесок летит в Program Files или bin. Вообщем по-всей видимости без инфраструктурных изменений вряд ли что-то можно улучшить существенным образом.
Проблема в CubeIDE и прочих визуалках без обратной связи из исходного кода "наверх" - невозможность динамической реконфигурации. Иными словами, допустим, в какой-то момент необходимо переключить ШИМ в шестишаговый режим, пробросить UART сделав Remap пинов, по ходу дела менять режимы DMA например. То есть система программируется изначально как нечто статическое. Конечно для большинства простых задач этого хватает но на специализированных применениях это может создать больше проблем. Плюс HAL/LL вместо регистров это отдельная тема, попытка языковыми средствами из 70-х с надеждой на упорство компилятора создать абстракцию, вроде как ООП на С, и да и нет, в итоге проще сделать какой-нибудь кодогенератор и единственный заголовочник.
Имеется в виду то что до сих пор в качестве аргументов используются различного рода вещи, которые тянутся из того что нужно собрать в систему сборки, не важно какого высокого она уровня. Иными словами включить/выключить CUDA/AVX/SSE, сделать море #define-ов, сгенерировать какой-либо .pm итд. То есть до сих пор нет каких-то встроенных в сам язык средств, поддерживающих сборку, иными словами требуется пересмотр самого принципа текст-компилятор-редактор связей-отладчик с наличием утилиты в этом механизме, отвечающей за сборку, включая данные о распределении памяти, опции подключаемых библиотек, версий, причём, инвариантно к именам/расширениям файлов, собирая непосредственно объекты и функции но это уже не задача make. До сих пор системы сборки и контроля версий по-сути обёртка на принципы работы и тулкиты, которые были ещё с середины 80-х. В даже в настоящее время проект - это просто папки и набор файлов в них с описанием того что нужно с этим сделать, вместо указания того, что нужно сделать непосредственно с их содержимым.
CMake медленно но верно как было замечено превращается в уже почти в графическое IDE. Наверняка уже завезли вещи связанные с Git, проверкой версий пакетов онлайн, среды окружения, тестирование самого компилятора на правильность. Но опять-таки краеугольный камень - что он не заходит внутрь файла забрать пользовательские идентификаторы, ориентируется на время/дату и прочие системные штуки при обновлении, не создаёт атрибутов файлов или дампов этапов построения с обработкой исключений при ошибках компиляции с целью не прервать процесс а максимально скомпилировать всё что без ошибок. Ну и разумеется танцы с макросами и зависимыми переменными. Вообщем скорее всего этот инструмент поглотит некий perl/python с явной кодогенерацией по шаблону из мета-языка, пригодного для конкретного применения, включая тот же bash/bat для сборки (локальной/тест/релиз). CMake же пытается объять необъятное и уже требует ненулевой порог входа для обучения.
Turbo C также мог по Ctrl+F9 собрать и запустить, подсветив код не хуже чем сейчас. Это был где-то 1998й год, всё влезало на дискету 1.44. Тогда были обычные make, и сейчас тоже самое, главное чтобы батарейка у биоса не села и не сбросила незаметно время. В качестве пакета - lib с заголовочниками, директория с датой - версия, bat-файл для всего остального. Практически за 30 лет лишь косметические изменения. Если бы тогда спросили у будущего: до сих пор используете файловые системы для структурирования проекта? Представлен очевидный ответ. Интересно, есть ли у этого процесса хоть какая-то интегрированная прямая поддержка со стороны IDE.
Кроме этого добавить ещё гамма- и радио-всплески (видимые в электромагнитном спектре), слияния чёрных дыр (видимые в спектре гравитационных волн), частицы сверхвысоких энергий в тераэлектронвольт из точечного источника (в спектре корпускулярного взаимодействия), детектирование всплесков нейтрино (спектр косвенного взаимодействия с веществом) скорее тут даже можно расширить на саму природу возникновения вспышки. Вот бы ещё выявить изменение или вспышку на фоне реликтового излучения, это самое интригующее было бы, некое событие эпохи рекомбинации.
Навскидку, поправьте ели не так, есть разница между nova и supernovae. Нова - это в принципе яркое астрономическое явление, а далее его классифицируют как переменную "катаклизмическую" звезду (бывает и такое что звезда блекнет, как Бетельгейзе, помнится зимой 2020 стала заметно тусклее) или сверхновую, для белого карлика Ia при превышении предела Чандрасекара аккрецией вещества.
Также, не задавайте в моделях параметры из разряда фемтофарад
, наногенри, тераомы и др, что частенько приводит к singular matrix error, или к зависаниям на коммутациях. И шаг счёта для лучшей сходимости и устойчивости решения по порядку величины равной минимальной постоянной времени схемы, как раз определяемой этими параметрами вроде 
итд, иными словами, обусловленность системы. Деление практически на 0 делает большую величину, из-за нелинейной разрядной сетки даже для double сумма с большим числом есть само число. Адаптивный шаг счёта, определяемый этими постоянными времени и LC-контурами приводит к уточнению reltol на уровне сотен МГц для схемы в 50 Гц при каждой коммутации.
Раньше были обычные справочники для основных параметров, которые определяют скажем так основное назначение. Особенно про транзисторы из разряда КТ315 или МП42Б. Давались только минимальная бета, ёмкости, обратный ток, температурное сопротивление кристалл-корпус/корпус-среда и другая мелочёвка. Из этого уже можно было построить малосигнальную или нелинейную модель для расчётов "вручную". Из предельных характеристик также, напряжение пробоя, максимальное напряжение база-эмиттер обратное косвенно вытягиваются остальные параметры. Вообщем фактически воссоздать характеристики по их кусочно-линейным аппроксимациям.
Лучше исключить Is сразу же, используя предел
, так как действительно чувствительность к прямой ветке слишком высокая и использовать его как параметр.
Ещё бы дополнительно сравнить температурные зависимости ВАХ, особенно для расчётов тепловых потерь, увеличивающихся с ростом температуры. В даташитах обычно приводят для -40, 25 и 85/105/125). В принципе можно параметр неидеальности n вынести в числитель как
и можно будет использовать линейный МНК.
Также можно использовать аналитическое решение для МНК с уравнением прямой, раз уж используется Maple/Maxima. Аппроксимацию сделал сразу для "ступеньки" функции ВАХ в общем виде, используя точку Vce0.
Как-то строил для транзистора получается примерно следующее
А для анализа характеристик обратного восстановления - включить в ЭДС небольшие катушки (процентов 5-10, обычно равные напряжению к.з. трансформатора/сети.
), чтобы они создавали угол коммутации 
.
Также, по заряду обратного восстановления можно ориентировочно вписать в параметр ёмкость диода
. Помимо этого конечно есть ещё эффект варикапа но для силовых диодов это не актуально.
Да, магнитные сейчас довольно хорошие, небольшая проблема - держатель магнита с диаметральной намагниченностью, обычно делаемый 3Д-печатью и заливкой эпоксидкой, хотя некоторую кривизну можно довольно неплохо исправить программно полиномом или таблицей.
Интересная задача. Попытался посмотреть аппроксимацию нелинейности звеном
Скрипт в Maxima для нахождения параметров колебательного звена
Программа
В итоге получилась следующая аппроксимация звеном вида :
,
при этом,
. В результате имеем следующую импульсную характеристику (с нулевыми начальными условиями, в исходной модели, видимо, они не нулевые, -40 начальный угол)
Видно, что +- график одинаковый с точки зрения общей "энергетики" переходного процесса. В конце имеется в оригинальной модели статическое значение порядка -2, и более быстрая диссипация, связанная с сухим трением (вязкий коэффициент). Поэтому для управления целесообразно рассмотреть применение корневых методов для линеаризированного объекта управления.
, то есть как обратная передаточная функция с вспомогательным дважды апериодическим полюсом 
. Компенсатор позволяет "выровнять" АЧХ объекта управления, но уменьшает быстродействие. В этом случае он ставится в ошибку управления и к нему суммируется интегратор (и небольшая пропорциональная составляющая), либо на выходе интегратора, для таких объектов производная (дифференциальная) - явный путь к автоколебаниям, интересно взглянуть на результаты оптимизации по времени на соотношения этих постоянных времени, скорее всего дифференциальная будет практически нулевой. Ну и разумеется возможность применения апериодического управления - deadbeat control, но это только для дискретных систем.
Что касается замкнутой системы то желаемый результат есть фактически предельно апериодический процесс с кратным апериодическим полюсом. В этом случае все полюса расположены рядом в левой полуплоскости на действительной оси. Как только появляются комплексно-сопряжённые полюса, то имеется перерегулирование. Чем левее они расположены - тем быстрее, но тем больше может быть всплеск, также он характерен и для апериодического процесса с разнесёнными постоянными времени. Круговая частота колебаний определяется мнимой осью, постоянная времени - действительной. В этом случае полюса рационально расположить в секторе порядка 45 град исходящего из нуля, там будет и быстродействие приемлемое и колебательность небольшая. Также ПИД-регулятор с таким объектом сразу в замкнутой системе даст 4й порядок (2+2). Поэтому рационально использовать компенсатор. Очень грубо он может быть синтезирован из указанного выше объекта управления как режекторный фильтр
Нет, маленько не так, мультиплеер может содержать элементы, который производитель игры хочет скрыть, ну вроде как все хотят чтобы ЗП капала за ПО, принимаем как должное. Поэтому невозможно будет описать сцену без скрытой физики, например, в мультиплее помимо людей ещё что-то делает ИИ а также меняется сцена по какому-то алгоритму или сюжет, которого нет в синглплее. В этом случае конечно же будут пакеты которые помогают эти изменения прорисовать. На клиентской стороне только текстуры, полигоны, звук/миди, базовая физика которая в общедоступном движке ну и по мелочам сетевые протоколы и локальное хранилище. Всё остальное уже в облаке. Мало того, если канал совсем небольшой то передаваться может "усечённая сцена" или отсутствовать мелкая моторика у персонажей.
Кстати вроде как подобный метод с переменным сжатием используется в DJVU. Там получается так что делаются из изображения слои, каждый слой это свой пространственный фильтр низкой частоты грубо говоря (например, усреднение по соседним точкам). Как только производная от изменения яркости становится большой (или в спектре появляются ВЧ-составляющие) применяется уже более мелкое сжатие локальной области. То есть сжимаются уже не исходная картина, а разбитая на эти слои, потом они снова складываются-восстанавливаются.
Имеются ли артефакты на границах блоков? Сжимается только покадровое изменение картины? В библиотеках самого jpeg вроде как имеется уже возможность поиграть с размером блоков DCT (lossy), а затем ещё поднастроить результат квантования (lossless).
Всё верно, речь идёт не о сервер-рендеринге а именно об этом действии на машине пользователя, которая выступает в качестве визуализатора, содержит терабайты текстур, демок, интро итд а по факту принимает поток графа сцены, который уже можно протолкнуть через узкополосные или падающие каналы. При этом, действительно, механика и прочее поведенческое "ноу-хау" (чтобы скрыть от читер-крякеров) из разряда ИИ, отрабатывается на игровом сервере. Вообщем это что то среднее между тонким клиентом и сервером.
Для антарктической экспедиции, когда охота поиграть с друзьями на другом континенте а видос через исчезающий Старлинк или другой спутник на высоких широтах уже не прогнать через
.
Именно так! Пользователь освобождается от бремени переноса к себе бинарников геймплея и физики, которые лежат на сервере а на его стороне лишь тонкий клиент с GPU для отрисовки. Аналогично все САПР-ы. Мало того, там автоматом виртуальная флешка с ключами привязанные к ГлобалУслугам (эту тему кстати не только у нас курируют, взять те же корневые сертификаты) с биометрическим ID. Ну и соответственно трафик может быть для векторной графики из разряда US Robotics 56k
А если геймплей охота глянуть через спутник, ASDL, диалап, пусть даже и спустя сотню миллисекунд, может там MMORPG 8k, такая где нужно увидеть на экране пиксель чтобы разгадать где спрятался юнит, сжатие без потерь не пойдёт, канал не позволит, с потерями - будет один большой блюр на весь экран с косинусными артефактами. То есть это потенциально индустриальная задача, когда разработчики игры, CAE/CAD/CAM могут движением мыши сгенерировать легковесный вьюер без игрового движка (99.9 это текстуры и полигоны), чтобы можно было смотреть на удалёнке что происходит, делать туторы и классрумы под сотню человек не напрягая связь. Причём это может быть универсальное решение в виде некой стандартной либы под CPU-GPU, что-то как раз из разряда x11-ов и Wayland-а, только более адаптировано под эту задачу, включающую обработку таймаутов, лагов и непрорисовок (пока что эти интерфейсы подразумевают идеальную связь)
С нетерпением жду что же есть на самом деле межзвёздный объект 3I/ATLAS с самой большой на данный момент избыточной скоростью. Как раз в сентябре вроде как будет максимум (потом наступит соединение с Солнцем) с яркостью 11, но это уже серьёзный телескоп нужен для этого.