Привет. В прошлой статье я описал математику, которая необходима для вывода трехмерной сцены на экран в виде сетки — т.е. мы остановились на моменте получения координат вершин в пространстве экрана. Следующий шаг — это «заполнение» полигонов из которых состоит объект, т.е. поиск пикселей, которые входят в изображение объекта на экране. Процесс поиска этих точек называется растеризацией. Мы так же хотим иметь возможность текстурировать и освещать объекты — для этого необходимо уметь интерполировать атрибуты, заданные в вершинах (например, текстурные координаты, нормали, цвет и другие).

Наши входные данные — это набор полигонов (мы будем рассматривать только треугольники): координаты их вершин (система координат зависит от алгоритма) и значения атрибутов в каждой из этих вершин, которые в дальнейшем будут интерполироваться вдоль поверхности треугольника. Существует несколько подводных камней, которые я рассмотрю в этой статье:

• Правило заполнения пикселей (filling convention)
• Точность
• Коррекция перспективы при интерполяции аттрибутов (perspective-correct interpolation)

Я рассмотрю три подхода к растеризации:

• «стандартный» алгоритм, использующий наклон граней
• целый ряд алгоритмов, основанных на использовании уравнений граней полигона (traversal-алгоритмы)
• алгоритм растеризации в однородных координатах

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

Всем привет. Я решил попробовать начать цикл статей по модернизации нашей с вами любимой IDA Pro.
В каждом из туториалов я попытаюсь раскрыть довольно таки сложную и мало изученную тему: написание различных модулей:

• загрузчики;
• плагины;
• дебагер-плагины;
• процессорные модули;
• скрипты.

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

Итак, первая статья из цикла будет посвящена написанию плагина-отладчика, а точнее предварительной теории. В штатной поставке IDA SDK уже имеются исходники основных дебагеров (Windows, Linux, Mac). Но как быть, например, с Amiga, M68000?

В этой статье я расскажу о своём опыте создания отдельного сервера («ферма» уж больно громко сказано) для рендеринга видео в домашних условиях.




Как известно, ренедеринг видео и трёхмерных изображений занимает много времени и требует много ресурсов компьютера. Ещё свежи воспоминания, как будучи студентом я ставил на ночь жужжащий компьютер с запущенной программой сборки фильма, а на утро оказывалось, что либо не хватило места на жёстком диске, либо что-то забыл добавить в ролик и всё приходилось начинать сначала. Сейчас настоящие профессионалы делают эту операцию удалённо. Например, режиссёр Джеймс Камерон во время съёмок фильма «Аватар» специально для себя сделал заказ на создания целого дата-центра, в котором запускались рендеринги сцен. Я пока ещё не настолько крут, чтобы строить свой отдельный дата-центр, но идея того, что эта операция могла бы быть запущена отдельно на другом сервере не давала мне покоя долгое время.

Вторая проблема – это монтаж самого видео. Несмотря на то, что современные компьютеры становятся мощнее, развитие видеокамер тоже не стоит на месте и получившиеся видео файлы становятся всё тяжелее и тяжелее. И, как следствие, их становится проблематично обрабатывать. Когда монтируешь продолжительный фильм, то предпросмотр трека с наложенными фильтрами и переходами начинает подгружать процессор и изображение начинает лагать, делая творческий процесс монтажа утомительным. Из того, что я пробовал, самый продуктивный был iMovie, что предустановлен на всех Маках. Даже фильм продолжительностью в 45 минут можно было редактировать без особых проблем на относительно маломощном макбуке. Можно было применить любой фильтр и увидеть результат в окне предпросмотра без каких-либо лагов. Так что владельцам маков тут повезло. Один минус у iMovie: во время работы он начинает потреблять непомерное количество дискового пространства. Видимо, это связано с агрессивным кэшированием для редактирования и предпросмотра.

В этой статье я опишу свой опыт, как я пытался решить эти две проблемы монтажа и рендеринга на примере домашнего видео ролика.

Итак, в продолжение предыдущей статьи пишу 2-ю часть, где мы попробуем добраться до того, чтобы написать проволочный рендер. Напоминаю, что цель этого цикла статей — написать сильно упрощенный аналог OpenGL на Rust. В качестве основы используется «Краткий курс компьютерной графики» от haqreu, в своих же статьях я сосредоточиваюсь больше не на графике как таковой, а на особенностях реализации при помощи Rust: возникающие проблемы и их решения, личные впечатления, полезные ресурсы для изучающих Rust. Сама получившаяся программа не имеет особенной ценности, польза от этого дела в изучении нового перспективного ЯП и основ трехмерной графики. Наконец, это занятие довольно таки увлекательно.

Напоминаю также, что поскольку я не являюсь профессионалом ни в Rust ни в 3D-графике, а изучаю эти вещи прямо по ходу написания статьи, то в ней могут быть грубые ошибки и упущения, которые я, впрочем, рад исправить, если мне на них укажут в комментариях.


Машинка, которую мы получим в конце статьи

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)линк)

Первая статья данного цикла была воспринята тепло, вследствие чего затягивать с продолжением не имело никакого смысла, но, увы – это произошло. Зимнее наступление захлебнулось и плавно переросло в летнюю кампанию. В конце статьи я объясню почему, не хотелось бы вас огорчать с самых первых строк. Итак. Публика выразила желание ознакомиться с предметом глубже, чем предполагалось изначально. Большое количество писем пришло на почту, наряду с регулярными тычками в социальных сетях. В этом месте мне вспоминается одна фраза – «будьте осторожны в своих желаниях».

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

Не будем мешкать. Возьмем наши пиксельные лопатки и двинемся на врага сплоченной группой. Быть может, нам повезет, и кто-нибудь, выжив, расскажет потомкам о ещё одной битве Теоретического войска возле местечка, вошедшего в историю сети как Хаброва падь.

Реализация поведения юнитов в RTS играх может стать серьезной проблемой. Компьютер, зачастую, контролирует огромное количество юнитов, в том числе и принадлежащих игроку, которые должны передвигаться в большом динамическом мире, попутно избегая столкновения друг с другом, выискивая врагов, защищая собственные базы и координируя атаки для истребления противника. Стратегии реального времени работают в реальном времени, что делает довольно сложным слежение за планированием действий и навигацией.

Этот урок описывает метод планирования течения игры и навигации юнитов, который использует многоагентные потенциальные поля. Он основан на работах под номерами [1, 2, 3]. (Смотри в конце статьи ссылки на используемые материалы)

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Как выглядит процесс обучения? Детсад, школа, университет и эпизодические курсы повышения квалификации, да и то не у всех. До конца жизни человек идет на том багаже знаний, который набрал в начале. Сейчас есть запрос на то, чтобы процесс обучения стал постоянным. Нужно поменять специализацию – пожалуйста. Нужно усилиться – пожалуйста. Делать это виртуально может быть проще и удобнее, ведь нет никаких барьеров. При этом качественные знания можно получить бесплатно. Представляю 8 платформ, на которых можно учиться на русском языке без бюджета.

Оптимизация веб-сайтов, известная под именем А/Б тестирование набрала популярность в качестве рабочей техники для многих команд, создающих сайты. Но до сих пор по ней слишком мало всеобъемлющих книг, статей или обучающих материалов, направленных на одиночных разработчиков, стремящихся ввести эту технику у себя в организации.

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

Основы: что такое оптимизация веб-сайтов?

Это метод экспериментов, проверяющих, какой дизайн лучше подходит для вашего сайта. Идея проста:

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

Показатели выбираются так, чтобы непосредственно отражать ваши бизнес-цели. Они могут включать количество товаров, купленных на сайте; количество людей, подписавшихся на рассылку; количество людей, просмотревших видео с инструкцией. Иногда показатели называют конверсией – это процент посетителей, совершивших нужное действие по отношению к общему числу посетителей.

Заканчивая работу над собственной игрой, я много размышлял о завершении проектов вообще. Я заметил, что есть множество разработчиков, которые не могут довести дело до конца. Если честно, за мной тоже тянется шлейф так и не завершенных игр, думаю, как и за каждым из нас. Не всем проектам суждено «выстрелить» – по разным причинам. Но если вы стали замечать, что постоянно бросаете игровые проекты с хорошим потенциалом, стоит остановиться и задуматься, почему так происходит.

Введение

Если вы когда-либо задумывались о шифровании данных на дисках уже после того, как у вас накопилось их приличное количество, вы, вероятно, расстраивались, прочитав о необходимости переноса данных перед созданием шифрованного раздела и после. Перенос 500 ГБ туда и обратно не представляет никакой особой трудности, такой объем можно временно загрузить даже в облако, но если речь идет о шифровании 6 винчестеров по 4 ТБ каждый, задача заметно усложняется. По какой-то причине, возможность шифрования и перешифровывания томов LUKS без потери данных (in-place re-encryption) слабо освещена в интернете, хотя для этого есть две утилиты: cryptsetup-reencrypt, входящая в состав cryptsetup с 2012 года, и сторонняя luksipc, появившаяся на год раньше. Обе утилиты выполняют, в общем-то, одно и то же — шифруют раздел, если он не был шифрован, либо перешифровывают уже существующий с другими параметрами. Для своих нужд я воспользовался первой, официальной.

Как это работает?

Предположим, у вас типичная разметка диска: один раздел, начинается с 1 МиБ (выравнивание для 4КиБ-секторов), заканчивается в конце диска.


Заголовок LUKS располагается в начале, перед зашифрованными данными. Для заголовка требуется минимум 2056 512-байтных секторов, т.е. чуть больше 1МиБ. Места перед началом раздела нам явно недостаточно, поэтому сначала нужно уменьшить размер файловой системы с ее конца, чтобы cryptsetup-reencrypt перенес блоки правее, в конец диска, освободив таким образом место в начале раздела для LUKS-заголовка. Конечный размер заголовка зависит от длины ключа, количества слотов для парольных фраз и прочих параметров, поэтому я рекомендую быть рачительным и отвести под заголовок 4 МиБ.

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

Это было очень давно, когда я учился классе в десятом. Среди довольно скудного в научном плане фонда районной библиотеки мне попалась книга — Угаров В. А. «Специальная теория относительности». Эта тема интересовала меня в то время, но информации школьных учебников и справочников было явно недостаточно.

Однако, книгу эту я читать не смог, по той причине, что большинство уравнений представлялись там в виде тензорных соотношений. Позже, в университете, программа подготовки по моей специальности не предусматривала изучение тензорного исчисления, хотя малопонятный термин «тензор» всплывал довольно часто в некоторых специальных курсах. Например, было жутко непонятно, почему матрица, содержащая моменты инерции твердого тела гордо именуется тензором инерции.

Продолжение:
Пишем свой упрощенный OpenGL на Rust — часть 2 (проволочный рендер).
Пишем свой упрощенный OpenGL на Rust — часть 3 (растеризатор)

Наверное, мало кто на хабре не в курсе, что такое Rust — новый язык программирования от Mozilla. Уже сейчас он привлекает много интереса, а недавно наконец вышла первая стабильная версия Rust 1.0, что знаменует собой стабилизацию языковых возможностей. Мне всегда импонировали системные ЯП, а уж идея системного языка, предлагающего безопасность превосходящую языки высокого уровня, заинтересовала еще больше. Захотелось новый язык попробовать в деле и, заодно, интересно провести время, программируя что-нибудь увлекательное. Пока думал, что бы такого на расте написать, вспомнился недавний цикл статей про компьютерную графику, который я лишь бегло просмотрел. А очень интересно было бы попробовать все-таки написать все эти красивости самостоятельно. Вот так и родилась идея этого хобби-проекта, а также данной статьи.

Поскольку в оригинальной статье тщательно разжевываются все нюансы, касающиеся программирования непосредственно графической составляющей, то я в своем цикле статей буду сосредотачиваться главным образом на том, что касается непосредственно Rust'а. Постараюсь описать те грабли, на которые довелось наткнуться, а также как решал возникающие проблемы. Расскажу о личных впечатлениях от знакомства с языком. И, конечно, упомяну список ресурсов, которыми пользовался при разработке. Итак, кому интересно, добро пожаловать под кат.

Предупреждение: статья написана с позиции новичка и описывает тупые ошибки новичка. Если вы профи раста, возможно, посмотрев на мои потуги, вы захотите меня больно огреть чем-нибудь тяжелым. В таком случае рекомендую воздержаться от ее чтения.


Here is the Rust, which i hope to get at the end. (игра слов, Rust по-английски «ржавчина»)

Как правильно расширить возможности языка программирования используя перегрузку операторов.

Создателей и майнтайнеров языков программирования часто просят добавить в язык новые возможности. Самый частый ответ который от них можно услышать таков:

«А зачем, ведь то, что вы предлагаете, можно сделать имеющимися средствами языка».

Перегрузка операторов появилась в С++ по просьбе физиков и математиков, которым хотелось удобно оперировать с самодельными типами данных, большими числами, матрицами.

Хотя физикам и математикам эта возможность пришлась по душе, программистам, в том числе создалелям С++ перегрузка операторов никогда особо не нравилась. Слишком сложное дело, много неявностей, поэтому за перегрузкой операторов закрепилось мнение чего-то вредного и применяемого в редких случаях.

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

С появлением у меня в первом классе Dendy вопрос кем я стану отпал сам собой буквально через пару недель — программистом конечно же. Я долго и упорно шел к этому, невзирая на отсутствие информатики в школе, работал в техподдержке известного всем регистратора параллельно с учебой в институте, но полноценная жизнь началась лишь в тот момент, когда меня наконец-то взяли хоть куда-то писать код.

Очень скоро я понял, что мало быть программистом, работающим от звонка до звонка и получающим за это деньги на карточку — всё самое интересное начинается, когда решаешь сам без всяких архитекторов, тестировщиков и тимлидов что-нибудь этакое написать и заставить работать. Желательно что-нибудь веселое и захватывающее. Игру, например.

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

В этом howto мы с вами просто и быстро, шаг за шагом, запустим гипервизор Qemu-KVM в debian 8.



Будем запускать виртуальную машину в qemu-kvm от пользователя username, используя spice, qxl и virtio.
Предполагается, что установлен Debian 8 amd64, с выбранными в tasksel стандартными утилитами и SSH сервером. Доустановим.

aptitude install -y firmware-linux bridge-utils etckeeper

Сначала я и не думал писать статью на эту тему, но похоже, что это уже часть целого цикла статей на Денди-тематику. И да, на этот раз речь в первую очередь именно про отечественную Денди, а не про оригинальные консоли — Famicom или NES. Просто я делал устройство в подарок одному человеку, который снимает очень интересные видеоролики про Денди, и ориентировался на совместимость именно с этим клоном.

Дело в том, что и для Famicom, и для NES выходили самые разные аксессуары: 3D очки, клавиатуры, роботы, считыватели штрих-кодов, всякие игровые контроллеры и очень многое другое. До нас же дошёл только световой пистолет. Передо мной стояла задача собрать устройство, которое совмещало бы в себе разветвитель на четыре игрока (да, были такие игры) и Arkanoid-контроллер.

Несмотря на развитие картографических веб-фреймворков, редактирование векторных географических данных всё ещё, по большей части, происходит в настольных приложениях, но пора бы уже переходить к редактированию в браузерах.

Для отрисовки веб-карт существует несколько открытых библиотек, например, OpenLayers и Leaflet. Довольно давно наш выбор пал на Leaflet и мы продолжаем его активно использовать при реализации проектов. Для редактирования геоданных хотелось бы использовать его же и, при этом, иметь возможность интегрироваться с существующими хранилищами пространственных данных.

Для достижения последней цели как правило используются ГИС-сервера (geoserver, mapserver), которые умеют публиковать большое количество разнообразных форматов данных по стандартам OGC. Так, WMS протокол прекрасно справляется с функцией визуализации готовой карты, но не предполагает функции редактирования, для которой резонно использовать WFS-протокол с возможностью изменения данных. Запросы к WMS возвращают уже отрисованные тайлы — картинки, а к WFS — сырую информацию, «исходный код» за этими тайлами. Leaflet поддерживает модули расширения, соответственно, можно поискать готовый компонент, либо написать свой. Т.к. поиск готовых модулей для Leaflet удовлетворяющих результатов не дал, мы приступили к собственной реализации.

По статистике запросов на leaflet.uservoice.com понятно, что данный модуль интересен не только нам.

В этой статье я хочу рассказать о процессе создания медиаплеера UrbanDenoiser Player. Помимо всяких «прелестей и красивостей» (о которых лучше почитать на практически одноимённом официальном сайте) плеер имеет новаторские режимы воспроизведения:

• Denoiser — повышение разборчивости аудиосигнала несмотря на внешний шум;
• Noise Around — одновременное прослушивание медиаконтента и звуков окружающего пространства;
• Natural — в котором плеер адаптирует выходной сигнал не только к АЧХ конкретных наушников, но и персональным особенностям слуха пользователя.

Версия для iPhone

Docker, если кто умудрился об этом ещё не слышать — фреймворк с открытым исходным кодом для управления контейнерной виртуализацией. Он быстрый, удобный, продуманный и модный. По сути он меняет правила игры в благородном деле управления конфигурацией серверов, сборки приложений, выполнения серверного кода, управления зависимостями и много ещё где.

Архитектура, которую поощряет Docker — это изолированные контейнеры, каждый из которых выполняет одну команду. Эти контейнеры должны знать только как друг друга найти — другими словами, о контейнере нужно знать его fqdn и порт, или ip и порт, то есть, не более, чем о любой внешней службе.

Рекомендованный способ сообщить такие координаты внутрь процесса, выполняемого в Docker — переменные окружения. Типичный пример этого подхода, не применительно к докеру — DATABASE_URL, принятый во фреймворке Rails или NODE_ENV принятый в фрейворке Nodejs.

И вот переменные окружения позволяют приложению внутри контейнера удобно и непринуждённо найти базу данных. Но для этого, человек, который пишет приложение, должен об этом знать. И хотя конфигурация приложения с помощью переменных окружения — это хорошо и правильно, иногда приложения написаны плохо, а запускать их как-то надо.