Навскидку, поправьте ели не так, есть разница между 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, но это уже серьёзный телескоп нужен для этого.
Скорее всего обратная и даже прямая совместимость с будущем - это всё то, что можно "скормить в коде и комментариях /*iddqd TBD*/" некоему Perl+Regexp, потому как "обновление ABC ломает всё", языковыми конструкциями не лечится. И в классических языках программирования похоже это лучший выход из ситуации помимо флажков версий и декораторов-макросов.
Ну почему же, если в качестве байткода вызывать методы того же Qt. Более того в новой почти полнофункциональной операционной системе называемой нынче "браузер" рендерить часть веб-контента AJAX-ом, то фактически эти самые JSON-XML-подобные пакеты и есть некая имитация иксов, концепт которых был ещё в середине 90-х. Можно образно сказать что фронтенд - это имитация рабочего стола и прочих элементов GUI, созданных на бекенде. А там хоть Ncurses или Turbo Vision по сети, но это уже более ранняя история.
В ещё стародавнее время в мультиплее можно было передавать изображение игры практически мгновенно, создавая двоичный поток об этой сцене по коаксиалу 10 мбит, в качестве проигрывателя - движок самой игры, там уже и текстуры есть и всё что нужно, достаточно представлять координаты и дерево объектов. Гипотетически, можно байткод, который и формирует это дело между GPU<->CPU перехватывать и уже отправлять непосредственно его, включая физику, а далее его восстанавливать на GPU-приёмнике, наверняка подобного рода технологию рано или поздно завезут, так как GPU в облаке как сервис и виртуальные видеокарты прямо говорят о том что это необходимо сделать, в этом случае можно рендерить хоть 8к, разумеется, для нативных фильмовых сцен это дело не подойдёт а для геймплея вполне.
До сих пор используются стандарты, описание технологий, их оформление, характерных для 60-х годов прошлого века. Иными словами то что сейчас наблюдаем - это бумажный документооборот в электронном виде. И глава Nvidia абсолютно прав в той идее, что ИИ вынудить сделать стандарты, адаптированные полностью под электронную форму а остальное - результат её обработки (для тем кому очень нужны бумажные архивы). Включая то, что производственная среда будет адаптирована не для человека, но для машин, им не нужно освещение для перемещения, в шахту не нужно подавать воздух (достаточно азота и углекислого газа), рабочее пространство (они пролезут с миллиметровой точностью), спецодежда, инструменты адаптированные для ручной работы (сразу синтезированные под техпроцесс), человека в ПТУ надо отучить 2-3 года, в то время как ИИ сразу же заточен под задачу. В этом русле производительность именно человеческого труда ставится под вопрос, предвосхищая переход к креативному потреблению нежели изготовлению.
Для сельхоза по-сути от человека нужно только зрение. То есть распознавать то что пока что (о чём и говорит Nvidia) не удаётся сделать машине в реалтайм, когда в поле застряло колесо, на пути коряги, зерно в перьях, бегающие лошади и коровы поперёк комбайна и прочая нештатка. Однако, это занимает проценты от полной автоматизации ухода за урожаем уже на настоящем уровне беспилотников и обслуживания техники. Там ещё мысль не просто использовать инструменты которые изначально были спроектированы для человека но и такие которые идеальны для обслуживания роботами, им не нужен ключ на 17 приспособленный под среднестатистическую руку или кирзовые сапоги.
Хотя в этом смысле подобного рода PLM-системы уже немножко опоздали, так как скорее всего проще синтезировать робота или его программу управления под выполнения задачи чем использовать симуляцию оптимального ручного процесса
Навскидку, поправьте ели не так, есть разница между 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, но это уже серьёзный телескоп нужен для этого.
Скорее всего обратная и даже прямая совместимость с будущем - это всё то, что можно "скормить в коде и комментариях /*iddqd TBD*/" некоему Perl+Regexp, потому как "обновление ABC ломает всё", языковыми конструкциями не лечится. И в классических языках программирования похоже это лучший выход из ситуации помимо флажков версий и декораторов-макросов.
Ну почему же, если в качестве байткода вызывать методы того же Qt. Более того в новой почти полнофункциональной операционной системе называемой нынче "браузер" рендерить часть веб-контента AJAX-ом, то фактически эти самые JSON-XML-подобные пакеты и есть некая имитация иксов, концепт которых был ещё в середине 90-х. Можно образно сказать что фронтенд - это имитация рабочего стола и прочих элементов GUI, созданных на бекенде. А там хоть Ncurses или Turbo Vision по сети, но это уже более ранняя история.
В ещё стародавнее время в мультиплее можно было передавать изображение игры практически мгновенно, создавая двоичный поток об этой сцене по коаксиалу 10 мбит, в качестве проигрывателя - движок самой игры, там уже и текстуры есть и всё что нужно, достаточно представлять координаты и дерево объектов.
Гипотетически, можно байткод, который и формирует это дело между GPU<->CPU перехватывать и уже отправлять непосредственно его, включая физику, а далее его восстанавливать на GPU-приёмнике, наверняка подобного рода технологию рано или поздно завезут, так как GPU в облаке как сервис и виртуальные видеокарты прямо говорят о том что это необходимо сделать, в этом случае можно рендерить хоть 8к, разумеется, для нативных фильмовых сцен это дело не подойдёт а для геймплея вполне.
Попытки с помидорами уже вроде как имеются, и даже используются.
Вообще говоря будет профессия в ПТУ что-то вроде оператора-садовода а не агронома. Для него будут примеры:
До сих пор используются стандарты, описание технологий, их оформление, характерных для 60-х годов прошлого века. Иными словами то что сейчас наблюдаем - это бумажный документооборот в электронном виде. И глава Nvidia абсолютно прав в той идее, что ИИ вынудить сделать стандарты, адаптированные полностью под электронную форму а остальное - результат её обработки (для тем кому очень нужны бумажные архивы). Включая то, что производственная среда будет адаптирована не для человека, но для машин, им не нужно освещение для перемещения, в шахту не нужно подавать воздух (достаточно азота и углекислого газа), рабочее пространство (они пролезут с миллиметровой точностью), спецодежда, инструменты адаптированные для ручной работы (сразу синтезированные под техпроцесс), человека в ПТУ надо отучить 2-3 года, в то время как ИИ сразу же заточен под задачу. В этом русле производительность именно человеческого труда ставится под вопрос, предвосхищая переход к креативному потреблению нежели изготовлению.
Для сельхоза по-сути от человека нужно только зрение. То есть распознавать то что пока что (о чём и говорит Nvidia) не удаётся сделать машине в реалтайм, когда в поле застряло колесо, на пути коряги, зерно в перьях, бегающие лошади и коровы поперёк комбайна и прочая нештатка. Однако, это занимает проценты от полной автоматизации ухода за урожаем уже на настоящем уровне беспилотников и обслуживания техники. Там ещё мысль не просто использовать инструменты которые изначально были спроектированы для человека но и такие которые идеальны для обслуживания роботами, им не нужен ключ на 17 приспособленный под среднестатистическую руку или кирзовые сапоги.