Тема интересная, но статья выглядит как поток сознания (путано и не последовательно). Полностью забыто что есть мягкие тени. Light map - это метод кэширования освещения (включая вторичку), а не генерации теней. Самопересекающися тени это либо результат оптимизации по скорости, либо непонимание как сделать правильно (хотя зависит от постановки задачи). Все методы имеют разнве артефакты при наивной реализации, методы борьбы с ними - действительно интересная, но узкая тема.
Методом попиксельного сложения соседних кадров (с арифметикой насыщения). Если удасться сделать с компенсацией движения, то ещё лучше. Хотя в сферическом случае через-кадрового пропадания светящейся надписи и без компенсации станет лучше.
Казеин даёт большую усадку при высыхании (правда во время высыхания сохраняет некоторую пластичность - не трескается). После высыхания его снова можно размочить в воде до состояния соплей. Что бы снизить влаго-поглащающие свойства нужны не домашние технологии (смешивание с формальдегидами, сушка под давлением при определённой температуре). Хорошо бы от плесени защититить изделие.
Ещё вариант домашнего пластика: разжевать хлеб, выплюнуть, дать высохнуть несколько дней - вот вам пластик.
Вы неправильно понимаете принцип двоично-десятичного представления. на один десятичный разряд приходится 4 бита, а не один. Для упомянутой в статье кодировке Чен-Хо на 3 десятичных разряда тратися 10 бит (т.е. 1000 vs 1024). Двоично-десятичное представление рыхлое - содержит неиспользуемые значения на всём возможном диапазоне.
При равных условиях (выполняемых операциях) потеря точности вычислений для обеих систем будет примерно одинаковая (у двоичной потери будут даже меньше). Друг от друга они действительно будут различаться.
Вот об этом и речь. Это не потеря "точности", это грубое округление. Можно просто научить функцию преобразования в строку (в десятичный формат?) красиво округлять для заданного числа разрядов после запятой.
Двоично-десятичная система не является "более точной". В десятичной системе тоже легко получить бесконечно длинные дробные части (в периоде и без). Сохранение введенного вручную числа (любимое 0.1) не является признаком "точности". Уж если такая задача реально возникает, то она легко исправляется другими методами. Например, округлением до нужного знака после запятой, а это уже больше связано с алгоритмом преобразования двочного представления в десятичное.
Я понимаю почему 8х1. Для декодирования сканлайна для каждых 8 пикселей читается два байта (шина данных памяти 8 бит). При таком рскладе можно перейти на 4х-цветный режим (аналог CGA) без палитры, либо так как сделали на Profi. Но, я бы предложил ещё вариант: размер блока 4х1 и для пикселей и для атрибута, атрибут указывает на таблицу (палиру?) пар цетов. Получится до 32 одновременных цветов на экране блоками 4х1, но микросхем придётся добавить, выходную шину ОЗУ палитры ещё в два раза шире (собственно решение в статье тоже прибавило микросхем).
Больше спиралей хороших и разных! Почему только 2D квадратные и круглые? Можно намотать на треугольники, семиугольники, звёздобразные кривые, а также на 3D платоновы тела, может удасться найти еще больше закономерностей.
Вроде в описании электродов сказано что они предназначены для сварки дефектов. Не отломится ли такая сварка через неделю? (учитывая что даже после TIG сварки в похожем случае всё опять отвалилось).
Очередная хайповая тема. Сточки зрения машинного кода массивы прекрасны (всё быстро и компактно). Если важна максимальная производительность какого то участка кода - это идеальный вариант. Если вам важно удобство, защита от выстрела в ногу, если в проекте несколько программистов и хочется изолировать интерфейс от реализации - не используйте массивы таким способом, оберните в класс, который будет помнить размеры всех размерностей и не допускать выход из диапазона при доступе к элементам. Всё ж просто, спорить не о чем.
Ну ход мылей то в целом веный. Но дело не в том каким способом указывать разрядность перед числом, а в том как это применить на практике. Если мы сжимаем массив чисел в котором есть частые значения, то записывать частые значения компактной последовательностью бит - это логично. Ну а дальше поиск компромиса - длина частых значений должна быть минимизирована (а для редких это уже не так важно), в идеале с учётом частоты использования. Тут есть простор для творчества можно комбинировать метод повторения нулей перед единицей как в кодах Элиаса, можно задать повторяющиеся нули/единицы и перед вторым нулём (например 0001110?????), можно брать двух, трёх (как у вас) и т.д фиксированные последовательности, а так же их комбинировать для разных диапазонов. А у Хафмана что там было? Вот только нюанс - это ещё не полноценный алгоритм сжатия, а его часть. Мне кажется обычно в этой части алгоритмов разработчики будут стараться использовать хорошо знакомые и известные решения.
А можно наивный вопрос от человека "не в теме"? Директ, боуден это понятно. А почему не бывает экструдеров которые вращают зубчатое колесо через троссик? Мотор будет не на голове, а давить он будет где надо.
Для узкоспециализированых задач - отличный алгоритм.
А если там скелетно анимированные монстры побегут на десяток тысяч полигонов, для их теней производительности CPU хватит всё пересчитать на лету?
Тема интересная, но статья выглядит как поток сознания (путано и не последовательно). Полностью забыто что есть мягкие тени. Light map - это метод кэширования освещения (включая вторичку), а не генерации теней. Самопересекающися тени это либо результат оптимизации по скорости, либо непонимание как сделать правильно (хотя зависит от постановки задачи). Все методы имеют разнве артефакты при наивной реализации, методы борьбы с ними - действительно интересная, но узкая тема.
Извиняюсь - чего то меня заклилнило, не то написал. Не "попиксельное сложение", а попиксельный максимум из двух соседних кадров.
Методом попиксельного сложения соседних кадров (с арифметикой насыщения). Если удасться сделать с компенсацией движения, то ещё лучше. Хотя в сферическом случае через-кадрового пропадания светящейся надписи и без компенсации станет лучше.
А если не суммировать, а взять максимум яркости от двух соседних кадров?
Похоже скоро гидрогель в мозг начнут закачивать.
Казеин даёт большую усадку при высыхании (правда во время высыхания сохраняет некоторую пластичность - не трескается). После высыхания его снова можно размочить в воде до состояния соплей. Что бы снизить влаго-поглащающие свойства нужны не домашние технологии (смешивание с формальдегидами, сушка под давлением при определённой температуре). Хорошо бы от плесени защититить изделие.
Ещё вариант домашнего пластика: разжевать хлеб, выплюнуть, дать высохнуть несколько дней - вот вам пластик.
Вы неправильно понимаете принцип двоично-десятичного представления. на один десятичный разряд приходится 4 бита, а не один. Для упомянутой в статье кодировке Чен-Хо на 3 десятичных разряда тратися 10 бит (т.е. 1000 vs 1024). Двоично-десятичное представление рыхлое - содержит неиспользуемые значения на всём возможном диапазоне.
При равных условиях (выполняемых операциях) потеря точности вычислений для обеих систем будет примерно одинаковая (у двоичной потери будут даже меньше). Друг от друга они действительно будут различаться.
Вот об этом и речь. Это не потеря "точности", это грубое округление. Можно просто научить функцию преобразования в строку (в десятичный формат?) красиво округлять для заданного числа разрядов после запятой.
Двоично-десятичная система не является "более точной". В десятичной системе тоже легко получить бесконечно длинные дробные части (в периоде и без). Сохранение введенного вручную числа (любимое 0.1) не является признаком "точности". Уж если такая задача реально возникает, то она легко исправляется другими методами. Например, округлением до нужного знака после запятой, а это уже больше связано с алгоритмом преобразования двочного представления в десятичное.
Я понимаю почему 8х1. Для декодирования сканлайна для каждых 8 пикселей читается два байта (шина данных памяти 8 бит). При таком рскладе можно перейти на 4х-цветный режим (аналог CGA) без палитры, либо так как сделали на Profi. Но, я бы предложил ещё вариант: размер блока 4х1 и для пикселей и для атрибута, атрибут указывает на таблицу (палиру?) пар цетов. Получится до 32 одновременных цветов на экране блоками 4х1, но микросхем придётся добавить, выходную шину ОЗУ палитры ещё в два раза шире (собственно решение в статье тоже прибавило микросхем).
Больше спиралей хороших и разных! Почему только 2D квадратные и круглые? Можно намотать на треугольники, семиугольники, звёздобразные кривые, а также на 3D платоновы тела, может удасться найти еще больше закономерностей.
Вроде в описании электродов сказано что они предназначены для сварки дефектов. Не отломится ли такая сварка через неделю? (учитывая что даже после TIG сварки в похожем случае всё опять отвалилось).
Очередная хайповая тема. Сточки зрения машинного кода массивы прекрасны (всё быстро и компактно). Если важна максимальная производительность какого то участка кода - это идеальный вариант. Если вам важно удобство, защита от выстрела в ногу, если в проекте несколько программистов и хочется изолировать интерфейс от реализации - не используйте массивы таким способом, оберните в класс, который будет помнить размеры всех размерностей и не допускать выход из диапазона при доступе к элементам. Всё ж просто, спорить не о чем.
8 бит глубина цвета, но теперь это назвается HDR. Люблю маркетологов...
Там в оргигинале не чертежи.
The main purpose for this handwriting is for the titles, labels and scribbled notes on these diagrams I’ve been working onНу ход мылей то в целом веный. Но дело не в том каким способом указывать разрядность перед числом, а в том как это применить на практике. Если мы сжимаем массив чисел в котором есть частые значения, то записывать частые значения компактной последовательностью бит - это логично. Ну а дальше поиск компромиса - длина частых значений должна быть минимизирована (а для редких это уже не так важно), в идеале с учётом частоты использования. Тут есть простор для творчества можно комбинировать метод повторения нулей перед единицей как в кодах Элиаса, можно задать повторяющиеся нули/единицы и перед вторым нулём (например 0001110?????), можно брать двух, трёх (как у вас) и т.д фиксированные последовательности, а так же их комбинировать для разных диапазонов. А у Хафмана что там было? Вот только нюанс - это ещё не полноценный алгоритм сжатия, а его часть. Мне кажется обычно в этой части алгоритмов разработчики будут стараться использовать хорошо знакомые и известные решения.
А можно наивный вопрос от человека "не в теме"? Директ, боуден это понятно. А почему не бывает экструдеров которые вращают зубчатое колесо через троссик? Мотор будет не на голове, а давить он будет где надо.