Если у гарнитуры будет два дисплея разрешением 11 520×6480, покрывающими всю область зрения каждого глаза, то да. Рендерить всю площадь в полном разрешении не обязательно, только небольшую область, куда смотрит глаз, остальное можно в 0.1x и меньше. Трекер глаза должен быть быстрым, частота кадров высокой, и движки игр должны уметь рендерить периферию и центр в разном разрешении.
У меня стоит оригинальный VB6 вместе с 2022 студией. VB6 на современном железе летает даже не как ракета, а как звездолёт. Как телепорт. Всё абсолютно мгновенно, никаких лагов. Сейчас кеш CPU как ОЗУ у компов, под которые писалась эта IDE, а частота выросла в 100 раз.
Проект интересный, скорее всего лишит его этого качества.
Для трехмерности нужно чтобы картинка зависела от ракурса. Как именно она это делает это второй вопрос — через VR, через голографию или ещё как‑то.
Что касается заглыхания темы то тут во многом сказалась некоторая дороговизна производства и воспроизведения такого контента + медицинские аспекты для зрителей (было исследование, после просмотра 3D-фильмов у 27% зрителей возникает определенный дискомфорт, 22% жалуется на ухудшение самочувствия, а 7% испытывает сильную головную боль).
Самая главная проблема — необходимость напяливать очки. То, что требует приблуду для использования, не приживается. Привет КПК со стилусами и тем, кто считает, что айфон это просто сенсорный телефон и до айфона это уже было.
Надо было хорошо вложиться в технологию автостереоскопических дисплеев и развить их до хорошего качества, тогда бы прижилось. А дальше можно увеличивать число ракурсов, добавлять трекеры головы и прочее.
Головная боль, дискомфорт и тошнота возникают, когда картинка отличается от того, что ожидает мозг. Включается биологическая механика, что раз данные из зрительной коры какие‑то не такие, значит ты поел грибов/ядовитых ягод/испореченную еду и надо блевать@лежать. Сюда же укачивание в транспорте, кстати.
Стереоскопические (а не 3D) дисплеи не меняют картинку если двигать головой, плюс дивергенция чаще всего косячит — расстояние между «камерами», на которые это снято, не совпадает с расстоянием между глаз. Плюс мозг привык, что когда смотришь на объекты на разном расстоянии, надо, помимо поворота глазных яблок, ещё и фокусировку настраивать. А тут фокус постоянный везде, а дивергенция разная. Все эти аспекты, в совокупности, увеличивают вероятность того, что организм стриггерится на протокол действий при отравлении блевать@лежать. Но все эти вещи фиксятся развитием технологии, чтобы обманывать мозг до конца. VR тоже в начале пути испытывал такие проблемы.
А вот не факт. Клиповое мышление, ИИ и всякие нейроинтерфейсы с большой вероятностью могут отправить плоский текст туда же, куда отправилась каллиграфия и письмо тушью.
Для того, чтобы VR/AR выстрелил, нужно стратегическое фундаментальное развитие технологий отображения со сроком окупаемости 30 лет и чудовищными инвестициями. Эффективные менеджеры, зарабатывающие здесь и сейчас реальные деньги и поднимающие KPI, заполонившие, в том числе, и Apple, и Facebook, на такое почти не способны.
Лёгкие AR очки, голографические фазированные антенные решётки оптического диапазона, фемтосекундные голографические проекторы и AR линзы всё равно постепенно приведут к слиянию виртуального и реального миров, заполонят всё ИИ 3D интерфейсами и похоронят массовые дисплеи и плоские кнопочки.
А «метавселенная», если отбросить маркетинг — это то, как конкретно Цукерберг видит это самое слияние миров, с использованием современных технологий.
Кто мешает в будущем проапгрейдить тело органами восприятия для 4D? А в мозг поставить рядом со зрительной корой 4D‑ускоритель? К чему эти проекции проекций?
человек не понимает китайский — значит, и компьютер не понимает китайский
Это логическая ошибка. Если часть системы не может X, это не значит, что вся система не может X. Это как утверждать, что раз один транзистор не умеет выполнять ассемблер, значит весь процессор не может. А он может. Потому что эмерджентность. Система из элементов обретает свойства, не отсутствующие у её элементов.
Система «человек‑в‑комнате‑с‑книгой» знает китайский и даёт осмысленные ответы. А её составляющие нет. Вот и всё.
Вы просто не видели софт, на 99% состоящий из кривого латаного‑перелатаного копипаста генерации нейросетей, отобранных генетическими алгоритмами, хелоуворлдов весом в 15 Гб и терафлопсов, уходящих на отрисовку иконки приложения, потому что её 30 раз в секунду заново выдумывает и генерирует ИИ на вирутальной машине в разрешении 208 МПикс, после чего от неё отрезается фрагмент 50×50 пикселей, и каждый из пикселей несколько раз сохраняется в наноблокчейн‑облако в 7Zip архив, заверенный вашей биометрией.
Имхо — при подобных подходах C, C++ и C# должны уже показывать +‑ одинаковые результаты. Просто потому что это подразумевает отказ почти ото всех абстракций, которые дают языки, кроме каких‑то базовых. Дальше уже только ассемблер. Который в разном виде можно так или иначе запустить во всех языках.
Согласно СТО, фотон с его фотоновой точки зрения существует не в 4D пространстве‑времени, а в 2D плоскости. Времени как измерения у него нет, как нет и траектории. Он просто вневременная точка на плоскости.
Поэтому некорректно рассуждать о том, замечает ли он или вообще делает ли что то, потому что для этих штук требуется хотя бы два момента времени, а у фотона он всего один.
А для наблюдателя фотон вполне себе «летит». Тут важно отметить, что обнаружить его, не поглотив, мы пока не умеем, поэтому то, что он «летит» тоже предмет дискуссии. Квантовая механика, например, подразумевает, что он не летит, и там происходят более замороченные штуки.
В частности, ваше предложение приведет к тому, что читателю кода класса где-то в глубине иерархии, чтобы понять побочные ээфекты, производимые методом, нужно будет вернуться вверх по цепочке наследования и посмотреть, какие побочные эффекты для метода назначены там атрибутами. И хорошо, если достаточно вернуться в корень иерархии - аттрибут-то можно применить к методу и на промежуточном уровне, и язык это никак запретить не может. Свойство - это сокрашенная записб для пары методов, так что и к нему это применимо.
А вот с этим должна помогать IDE, помечая/сообщая/выделяя, что вот, изменение свойства обрабатывается таким‑то RunOnMemberAccess‑методом. Или, как вариант, вместо атрибута RunOnMemberAccess постановить, что вызываться будет всегда метод с названием __OnPropertyChangedAggregator__ по аналогии с Deconstruct(out...)у кортежей.
Сейчас тоже при изменении свойства может оказаться, что его 100 500 раз перегрузили, и в этих перегрузках сеттеры и геттеры могут вполне себе генерировать кучу побочных эффектов. Плюс класс вполне может иметь какие‑нибудь фоновые потоки/таски, которые как‑то реагируют на изменение свойств и генерируют побочные эффекты. Выстрелить себе (или не себе) в ногу всегда можно.
Смысл в том, чтобы
public Type1 Property1 { get; set; }
public Type2 Property2 { get; set; }
public Type3 Property3 { get; set; }
public Type4 Property4 { get; set; }
public Type5 Property5 { get; set; }
не превращалось в
private Type1 _property1;
public Type1 Property1
{
get => _property1;
set
{
_property1 = value;
OnPropertyChanged();
}
}
private Type2 _property2;
public Type2 Property2
{
get => _property2;
set
{
_property2 = value;
OnPropertyChanged();
}
}
private Type3 _property3;
public Type3 Property3
{
get => _property3;
set
{
_property3 = value;
OnPropertyChanged();
}
}
private Type4 _property4;
public Type4 Property4
{
get => _property4;
set
{
_property4 = value;
OnPropertyChanged();
}
}
private Type5 _property5;
public Type5 Property5
{
get => _property5;
set
{
_property5 = value;
OnPropertyChanged();
}
}
Ну дичь же, огород приходится городить на ровном месте. Ладно хотя бы CallerMemberName появился. И то, ИМХО — решение ужасно кривое, можно было бы сделать гораздо лаконичнее. Ну или что-типа
public notify Type1 Property1 { get; set; }
public notify Type2 Property2 { get; set; }
public notify Type3 Property3 { get; set; }
public notify Type4 Property4 { get; set; }
public notify Type5 Property5 { get; set; }
Чтобы было виднее, что оно автоматом что‑то там вызовет.
[RunOnMemberAccess(MemberAccess.PropertySet | MemberAccess.PropertyGet)]
public event Action<MemberAccessInfo> MyOnPropertyChange;
И компилятор должен автоматом прописать его вызов во все свойства данного и всех производных классов автоматом (кроме тех, у которых атрибут ExcludeRunOnMember). И подобный механизм должен позволять работать не только для перехвата изменения свойств, но и для чтения, вызова методов, подписок на события и любых других штук.
MemberAccessInfo должно быть ref struct, чтобы не генерировать аллокации и жрать ресурсов по минимуму. Можно даже сделать автоспециализацию. Типа
По типу аргумента PropertySetInfo оно понимает, что это надо вызывать в моменты изменения свойств. Было бы BeforeMethodRunInfo — запускалось бы перед вызовом методов и передавало бы все аргументы метода, что удобно, кстати, для автоматизации проверки аргументов. Для полей это тоже можно сделать, но будет не очень оптимально.
То есть нужен механизм, который не требует от тебя в каждое свойство что‑то прописывать, будь то атрибут или какой‑то там вызов. И уже внутри этой штуки ты смотришь, что там за свойство изменилось и надо ли на него реагировать.
Я себе сделал класс ChangeNotifier(object obj), которому можно скормить любой объект, и он будет автоматом засекать изменения свойств и полей, тупо каждые 100 мс сравнивая хэши значений с предыдущими. Но хотелось бы иметь некостыльный, нормально работающий инструмент.
Ну, это, конечно, неправильно, но лучше, чем ничего - вероятность того, что такое улетит в продакшн уже меньше. А чтобы было правильно, достаточно компилятор заставить перед каждым (!) await ставить что-типа if (!Monitor.CheckAwaitAllowed()) throw new Exception("bruh"); тогда эта штука будет работать в 100% случаев, хотя и в рантайме.
PS await - он не обязательно про Task: там может быть что угодно. К примеру, у меня в свежей библиотеке есть класс, который ни разу не Task/ValueTask, но у него в одном из методов написано await this;
В одном из моих проектов пришлось с нуля рожать собственные таски с пулами. Заодно сделал возможность писать штуки вроде
await 100; //await Task.Duration(100);
Так делать, конечно, нехорошо, но прикольно :) await можно использовать и в более общем виде, как оператор «преврати всё что идёт ниже, в большую толстую лямбду и дай мне» и делать с этим что угодно. Так тоже делать нехорошо :)
Имхо: то, что сейчас — это примерно уровень матричных принтеров 80х годов. В будущем техпроцесс существенно поменяется, и всё это будут делать на совсем других принтерах.
Где частицы порошка тысячами будут по одному отслеживаться, поворачиваться и выкладываться акустической левитацией в матрице ультразвуковой фазированной решётки, выравниваться точным электростатическим полем и сплавляться друг с другом тысячами фемтосекундных лазеров ещё в полёте, параллельно. Само печатаемое изделие будет сканироваться и уточнаться этими же лазерами на лету, а система датчиков и актуаторов будет в реальном времени в противофазе моделировать и подавлять все вибрации и шумы так, что точность будет достигаться при очень небольшой жёсткости конструкции.
Это как современный HDD на 32 Тб — если посмотреть внутрь и осознать, с какой плотностью и точностью он работает, даже если держать его в руках и чесаться им — можно немного удивиться, почему он стоит меньше космической программы марсоходов.
Если у гарнитуры будет два дисплея разрешением 11 520×6480, покрывающими всю область зрения каждого глаза, то да. Рендерить всю площадь в полном разрешении не обязательно, только небольшую область, куда смотрит глаз, остальное можно в 0.1x и меньше. Трекер глаза должен быть быстрым, частота кадров высокой, и движки игр должны уметь рендерить периферию и центр в разном разрешении.
Скажите, а существуют ли готовые решения, строящие не облака точек или полигональные модели, а NeRF?
Писать калькуляторы на VB6 это классика:)
У меня стоит оригинальный VB6 вместе с 2022 студией. VB6 на современном железе летает даже не как ракета, а как звездолёт. Как телепорт. Всё абсолютно мгновенно, никаких лагов. Сейчас кеш CPU как ОЗУ у компов, под которые писалась эта IDE, а частота выросла в 100 раз.
Проект интересный, скорее всего лишит его этого качества.
Для трехмерности нужно чтобы картинка зависела от ракурса. Как именно она это делает это второй вопрос — через VR, через голографию или ещё как‑то.
Самая главная проблема — необходимость напяливать очки. То, что требует приблуду для использования, не приживается. Привет КПК со стилусами и тем, кто считает, что айфон это просто сенсорный телефон и до айфона это уже было.
Надо было хорошо вложиться в технологию автостереоскопических дисплеев и развить их до хорошего качества, тогда бы прижилось. А дальше можно увеличивать число ракурсов, добавлять трекеры головы и прочее.
Головная боль, дискомфорт и тошнота возникают, когда картинка отличается от того, что ожидает мозг. Включается биологическая механика, что раз данные из зрительной коры какие‑то не такие, значит ты поел грибов/ядовитых ягод/испореченную еду и надо блевать@лежать. Сюда же укачивание в транспорте, кстати.
Стереоскопические (а не 3D) дисплеи не меняют картинку если двигать головой, плюс дивергенция чаще всего косячит — расстояние между «камерами», на которые это снято, не совпадает с расстоянием между глаз. Плюс мозг привык, что когда смотришь на объекты на разном расстоянии, надо, помимо поворота глазных яблок, ещё и фокусировку настраивать. А тут фокус постоянный везде, а дивергенция разная. Все эти аспекты, в совокупности, увеличивают вероятность того, что организм стриггерится на протокол действий при отравлении блевать@лежать. Но все эти вещи фиксятся развитием технологии, чтобы обманывать мозг до конца. VR тоже в начале пути испытывал такие проблемы.
А вот не факт. Клиповое мышление, ИИ и всякие нейроинтерфейсы с большой вероятностью могут отправить плоский текст туда же, куда отправилась каллиграфия и письмо тушью.
Для того, чтобы VR/AR выстрелил, нужно стратегическое фундаментальное развитие технологий отображения со сроком окупаемости 30 лет и чудовищными инвестициями. Эффективные менеджеры, зарабатывающие здесь и сейчас реальные деньги и поднимающие KPI, заполонившие, в том числе, и Apple, и Facebook, на такое почти не способны.
Лёгкие AR очки, голографические фазированные антенные решётки оптического диапазона, фемтосекундные голографические проекторы и AR линзы всё равно постепенно приведут к слиянию виртуального и реального миров, заполонят всё ИИ 3D интерфейсами и похоронят массовые дисплеи и плоские кнопочки.
А «метавселенная», если отбросить маркетинг — это то, как конкретно Цукерберг видит это самое слияние миров, с использованием современных технологий.
Кто мешает в будущем проапгрейдить тело органами восприятия для 4D? А в мозг поставить рядом со зрительной корой 4D‑ускоритель? К чему эти проекции проекций?
Ох уж эта китайская комната!
Это логическая ошибка. Если часть системы не может X, это не значит, что вся система не может X. Это как утверждать, что раз один транзистор не умеет выполнять ассемблер, значит весь процессор не может. А он может. Потому что эмерджентность. Система из элементов обретает свойства, не отсутствующие у её элементов.
Система «человек‑в‑комнате‑с‑книгой» знает китайский и даёт осмысленные ответы. А её составляющие нет. Вот и всё.
Дисковая полка на 20+ дисков, контроллер и программный raid6 или raid10?
Кончается место — докупил один‑два диска, поставил. Сдох диск — заменил. Диски можно найти где угодно, полки тоже.
Вы просто не видели софт, на 99% состоящий из кривого латаного‑перелатаного копипаста генерации нейросетей, отобранных генетическими алгоритмами, хелоуворлдов весом в 15 Гб и терафлопсов, уходящих на отрисовку иконки приложения, потому что её 30 раз в секунду заново выдумывает и генерирует ИИ на вирутальной машине в разрешении 208 МПикс, после чего от неё отрезается фрагмент 50×50 пикселей, и каждый из пикселей несколько раз сохраняется в наноблокчейн‑облако в 7Zip архив, заверенный вашей биометрией.
Это мем из будущего, вы пока не поймёте.
В новых .NET кстати появились AVX512. Но они, к сожалению, доступны далеко не на всех современных железках, и не всегда работают хорошо.
Имхо — при подобных подходах C, C++ и C# должны уже показывать +‑ одинаковые результаты. Просто потому что это подразумевает отказ почти ото всех абстракций, которые дают языки, кроме каких‑то базовых. Дальше уже только ассемблер. Который в разном виде можно так или иначе запустить во всех языках.
Согласно СТО, фотон с его фотоновой точки зрения существует не в 4D пространстве‑времени, а в 2D плоскости. Времени как измерения у него нет, как нет и траектории. Он просто вневременная точка на плоскости.
Поэтому некорректно рассуждать о том, замечает ли он или вообще делает ли что то, потому что для этих штук требуется хотя бы два момента времени, а у фотона он всего один.
А для наблюдателя фотон вполне себе «летит». Тут важно отметить, что обнаружить его, не поглотив, мы пока не умеем, поэтому то, что он «летит» тоже предмет дискуссии. Квантовая механика, например, подразумевает, что он не летит, и там происходят более замороченные штуки.
А вот с этим должна помогать IDE, помечая/сообщая/выделяя, что вот, изменение свойства обрабатывается таким‑то
RunOnMemberAccess‑методом. Или, как вариант, вместо атрибутаRunOnMemberAccessпостановить, что вызываться будет всегда метод с названием__OnPropertyChangedAggregator__по аналогии сDeconstruct(out...)у кортежей.Сейчас тоже при изменении свойства может оказаться, что его 100 500 раз перегрузили, и в этих перегрузках сеттеры и геттеры могут вполне себе генерировать кучу побочных эффектов. Плюс класс вполне может иметь какие‑нибудь фоновые потоки/таски, которые как‑то реагируют на изменение свойств и генерируют побочные эффекты. Выстрелить себе (или не себе) в ногу всегда можно.
Смысл в том, чтобы
не превращалось в
Ну дичь же, огород приходится городить на ровном месте. Ладно хотя бы CallerMemberName появился. И то, ИМХО — решение ужасно кривое, можно было бы сделать гораздо лаконичнее. Ну или что-типа
Чтобы было виднее, что оно автоматом что‑то там вызовет.
ИМХО, это выглядеть должно как то так: есть возможность объявить 1 раз метод
Или сразу событие
И компилятор должен автоматом прописать его вызов во все свойства данного и всех производных классов автоматом (кроме тех, у которых атрибут ExcludeRunOnMember). И подобный механизм должен позволять работать не только для перехвата изменения свойств, но и для чтения, вызова методов, подписок на события и любых других штук.
MemberAccessInfo должно быть ref struct, чтобы не генерировать аллокации и жрать ресурсов по минимуму. Можно даже сделать автоспециализацию. Типа
По типу аргумента PropertySetInfo оно понимает, что это надо вызывать в моменты изменения свойств. Было бы BeforeMethodRunInfo — запускалось бы перед вызовом методов и передавало бы все аргументы метода, что удобно, кстати, для автоматизации проверки аргументов. Для полей это тоже можно сделать, но будет не очень оптимально.
То есть нужен механизм, который не требует от тебя в каждое свойство что‑то прописывать, будь то атрибут или какой‑то там вызов. И уже внутри этой штуки ты смотришь, что там за свойство изменилось и надо ли на него реагировать.
Я себе сделал класс ChangeNotifier(object obj), которому можно скормить любой объект, и он будет автоматом засекать изменения свойств и полей, тупо каждые 100 мс сравнивая хэши значений с предыдущими. Но хотелось бы иметь некостыльный, нормально работающий инструмент.
Ну, это, конечно, неправильно, но лучше, чем ничего - вероятность того, что такое улетит в продакшн уже меньше. А чтобы было правильно, достаточно компилятор заставить перед каждым (!) await ставить что-типа if (!Monitor.CheckAwaitAllowed()) throw new Exception("bruh"); тогда эта штука будет работать в 100% случаев, хотя и в рантайме.
В одном из моих проектов пришлось с нуля рожать собственные таски с пулами. Заодно сделал возможность писать штуки вроде
await 100; //await Task.Duration(100);Так делать, конечно, нехорошо, но прикольно :) await можно использовать и в более общем виде, как оператор «преврати всё что идёт ниже, в большую толстую лямбду и дай мне» и делать с этим что угодно. Так тоже делать нехорошо :)
Предположу, что низкая скорость вынуждает кодек использовать для сжатия не только прошлые кадры, но и будущие — а это требует внесения задержки.
OnPropertyChanged настолько часто все делают, что могли бы уже завести фичу на уровне языка.
Такое довольно просто в рантайме обнаружить и кинуть Exception, но в стандартные таски это не завезли.
Имхо: то, что сейчас — это примерно уровень матричных принтеров 80х годов. В будущем техпроцесс существенно поменяется, и всё это будут делать на совсем других принтерах.
Где частицы порошка тысячами будут по одному отслеживаться, поворачиваться и выкладываться акустической левитацией в матрице ультразвуковой фазированной решётки, выравниваться точным электростатическим полем и сплавляться друг с другом тысячами фемтосекундных лазеров ещё в полёте, параллельно. Само печатаемое изделие будет сканироваться и уточнаться этими же лазерами на лету, а система датчиков и актуаторов будет в реальном времени в противофазе моделировать и подавлять все вибрации и шумы так, что точность будет достигаться при очень небольшой жёсткости конструкции.
Это как современный HDD на 32 Тб — если посмотреть внутрь и осознать, с какой плотностью и точностью он работает, даже если держать его в руках и чесаться им — можно немного удивиться, почему он стоит меньше космической программы марсоходов.