Потребность делать железо периодически возникает у многих технарей. Иногда задача позволяет нафигачить всё проводами на макетке, а иногда, к сожалению, нужно нечто посерьёзнее. Вот и меня однажды настигла потребность делать печатные платы… Лазерно-утюжная технология кустарного изготовления плат по началу сильно отталкивает своей рандомностью (на чём печатать, как греть, с какой силой давить, как отдирать, и т.д.), но друзья поделились опытом, и оказалось, что это действительно не так уж сложно. ЛУТ бесспорно дешевле любого другого варианта, и (внезапно) вполне подходит для двухслойных плат.

Кому интересно посложнее, подороже и поточнее, можно делать фоторезистом, но наша методика (основным элементом которой является особая бумага) позволяет стабильно прорабатывать шины 0.3/0.3 мм, так что в нашем сообществе бытует мнение что тян фоторезисты не нужны.

Кто не видит смысла в кустарном производстве плат, скорее всего сможет вспомнить пару случаев, когда приходилось пилить дорожки и припаивать проводки на целой партии плат. А сделав одну плату дома, можно её хорошенько отладить и приобрести уверенность в фабричных платах.

Под катом я поделюсь детерминированной методикой изготовления двухслойных печатных плат по технологии ЛУТ с различными резервными схемами на случай косяков. От идеи до включения. Будем работать с KiCad, Inkscape, наждачкой, утюгом, персульфатом аммония и гравёром.

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

Преломление и эффекты постобработки

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

Постобработка

В общем случае эффект постобработки — это любой эффект, применяемый к всей сцене после её рендеринга, например, оттенки цвета или эффект старого ЭЛТ-экрана. Вместо рендеринга сцены непосредственно на экран, мы сначала рендерим её в буфер или текстуру, а затем, пропустив сцену через свой шейдер, выполняем рендеринг на экран.

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

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

• Добавил модели маяка и осьминога.
• Добавил модель земли с цветом #FFA457.
• Добавил камере цвет неба #6CC8FF.
• Добавил в сцену цвет подсветки #FFC480 (эти параметры можно найти в настройках сцены).

Моя исходная сцена теперь выглядит так.

В своём туториале «Создание шейдеров» я в основном рассматривал фрагментные шейдеры, которых достаточно для реализации любых 2D-эффектов и примеров на ShaderToy. Но существует целая категория техник, требующих использования вершинных шейдеров. В этом туториале я расскажу о создании стилизованного мультяшного шейдера воды и познакомлю вас с вершинными шейдерами (vertex shaders). Также я расскажу о буфере глубин и о том, как использовать его для получения дополнительной информации о сцене и для создания линий морской пены.

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


Этот эффект состоит из следующих элементов:

1. Просвечивающий меш воды с разбитыми на части (subdivided) полигонами и смещёнными вершинами для создания волн.
2. Статичные линии воды на поверхности.
3. Имитируемая плавучесть лодок.
4. Динамические линии пены вокруг границ объектов в воде.
5. Постобработка для создания искажений всего, что находится под водой.

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

При разработке современных веб-сайтов интенсивно используются возможности JavaScript по работе с DOM. Скрипты позволяют отображать и скрывать элементы, из которых строятся страницы, настраивать свойства этих элементов. У объектов DOM, с которыми взаимодействуют из программ, имеются свойства и методы. О некоторых из них, по мнению автора материала, перевод которого мы сегодня публикуем, знают практически все веб-программисты. А вот некоторые, о которых он и хочет здесь рассказать, пользуются куда меньшей известностью.

Я все еще не до конца понял, как так получилось, но в прошлом году я слово за слово подписался прочитать курс по Deep Learning и вот, на удивление, прочитал. Обещал — выкладываю!

Курс не претендует на полноту, скорее это способ поиграться руками с основными областями, где deep learning устоялся как практический инструмент, и получить достаточную базу, чтобы свободно читать и понимать современные статьи.

Материалы курса были опробованы на студентах кафедры АФТИ Новосибирского Государственного Университета, поэтому есть шанс, что по ним действительно можно чему-то научиться.

В одной из предыдущих статей мы провели обзор технологий, которые используются на нашем новом проекте — fast paced шутере для мобильных устройств. Теперь хочу поделиться, как устроена клиентская часть сетевого кода будущей игры, с какими трудностями мы столкнулись и как их решали.

UPD: так как тема хорошо зашла и показала наличие спроса на такой сервис, буду развивать его дальше. Завел паблик вконтакте для сбора фидбека и публикации информации об обновлениях https://vk.com/sightsafari

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

Ситуация еще больше осложняется, если рядом нет никаких крупных достопримечательностей, о которых все знают и которые можно было бы включить в свой маршрут после короткого поиска в интернете. Что делать если вы застряли в каком-нибудь Купчино, про которое вы только и слышали, что там лучше не застревать? Приходится идти по навигатору, надеясь, что на пути встретится что-то интересное. Однако популярные навигаторы учитывают лишь расстояние и время в пути, но не принимают во внимание интересность маршрута. Мне попадались еще проекты, пытающиеся учитывать удобство пешего маршрута (ведущие в обход шумных магистралей), но хочется же пройти не только комфортно, но и увидеть какие-нибудь красоты.



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

Описание алгоритма и примеры работы под катом, ссылка в конце.

UPDATE: Объявления для участников.
UPDATE 2: Промежуточные результаты и объявления.

Компания Hola вновь объявляет конкурс по программированию! Победителей ожидают призы:

1. Первое место: 3000 USD.
2. Второе место: 2000 USD.
3. Третье место: 1000 USD.
4. Жюри может присудить по своему усмотрению специальный приз в 400 USD.
5. Если Вы отправите кому-то ссылку на этот конкурс, поставив наш адрес в CC, и этот человек займёт призовое место, Вы получите половину суммы приза (разумеется, не в ущерб награде победителя). За одного победителя такую награду может получить только один человек — тот, кто отправил ссылку первым.

Авторы интересных решений будут приглашены на собеседования.

Правила

Условия конкурса на английском языке размещены на GitHub. Ниже — перевод на русский язык.

Объявления для участников конкурса по программированию.

Порядок окончательного тестирования

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

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

Каждый раз как на новую планету.

Когда мы взлетали из Кефлавика, из-за сильного ветра мимо окна пролетел один из конусов ограждения. Капитан самолёта тоже его заметил и сразу обратился к пассажирам:

— Сейчас мы начнём взлетать. Будет трясти. Пожалуйста, кричите тише.

Да, тут всё в духе Firefly.

Мы пообщались с потрясающими разработчиками Atomontage, пытаясь разобраться, смогут ли воксели вернуться и победить пиксели.

Воксельная разработка

Бранислав: в 2000-2002 годах я участвовал в соревнованиях европейской демосцены. Я написал несколько 256-байтных демо (также называемых intro) под ником Silique/Bizzare Devs (см. «Njufnjuf», «Oxlpka», «I like ya, Tweety» и «Comatose»). Каждое из интро генерировало в реальном времени воксели или графику из облака точек. И воксели, и облака точек являются примерами сэмплированной геометрии.

Интро выполняли свою задачу всего в 100 инструкциях процессора, таких как ADD, MUL, STOSB, PUSH и им подобных. Однако из-за самой природы такого типа программ на самом деле десятки инструкций использовались просто для правильной настройки, а не для генерации самой графики. Тем не менее этих 50 с лишним инструкций, которые по сути являлись элементарными математическими операциями или операциями с памятью, оказалось достаточно для генерации довольно красивой подвижной 3D-графики в реальном времени. Все эти 256-байтные интро выигрывали с первого по третье места. Это заставило меня осознать, что если такую 3D-графику возможно создавать без полигонов, то в играх и других приложениях можно достичь гораздо большего с помощью того же принципа: использования сэмплированной геометрии вместо полигональных мешей. Решение заключается в простоте. Я понял, что доминировавшая тогда парадигма, основанная на сложных и фундаментально ограниченном (необъёмном) представлении данных, уже готова была упереться в потолок возможностей. То есть настало подходящее время испробовать эту «новую», более простую парадигму: объёмную сэмплируемую геометрию.

Часть 1. Знакомство с Marching cubes

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

Вот пример из No Man’s Sky: видео.

Аналогичная техника применяется для отображения изображений с МРТ, metaball-ов и для вокселизации рельефа.

В этой части я расскажу о технике создания разрушаемого рельефа Marching Cubes, а в более общем применении — для создания плавного граничного меша твёрдого объекта. В этой статье мы начнём с рассмотрения двухмерной техники, затем трёхмерной, а в третьей части рассмотрим Dual Contouring. Dual Contouring — это более совершенная техника, создающая тот же эффект.

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



О спикере: Александр Хаёров (@allexx) руководит отделом разработки в компании Ingram Micro Cloud. Ребята в команде Александра считают себя не просто отличными инженерами, а называют себя великой командой voxel джедаями, мастерами оптимизации, гуру 3D и повелителями больших данных! [примечание: по аналогии с названиями должностей в LinkedIn и Medium]

Эта классная команда, готовясь к выступлению на Highload++ 2017, решила развлечь аудиторию и сделать что-то новое и интересное для стенда. Поэтому они запилили игру, о создании которой и пойдет дальше речь.

Хозяйке на заметку: со стороны организаторов, мы очень приветствуем усилия по подготовке к участию в конференции. Они многократно окупаются, привлекая участников, и, как выясняется, идут на пользу команде.

Итак, поехали!

Могут ли кнопки быть шестиугольными?

Google I/O 2018 оставила огромное количество материала для осмысления. Что нового? Как жить дальше? Устарело ли моё приложение? Могут ли кнопки быть шестиугольными? Дизайнеры снова больше не нужны? Осмысливать приятней не спеша и маленькими порциями. Эта порция — про дизайн.

Творчество с применением искусственного интеллекта теперь включает и использование программ для написания музыки, которыми может управлять любой

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

Что же делать начинающему, в лучшем случае, музыканту? Я маршировал в колледже, поэтому понимаю, что такое ритм, фразировка и темп, но мои возможности по созданию музыки остановились где-то на уровне средней школы.

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

Привет, Хабр. Мы недавно перевели на арабский язык 2ГИС Онлайн, и хотим поделиться своим опытом адаптации интерфейса под RTL (right-to-left). Это будет актуально и для иврита, и для персидского языка.

Я разделю этот опыт на две статьи — теоретическую и практическую. Сегодня — больше про теорию. Я расскажу, зачем нам понадобилось переворачивать весь интерфейс, что для разработчика интерфейсов значит фраза «сделать арабскую версию» и как справиться с арабским языком, смешанным с английским. Особое внимание уделю алгоритму, по которому строится отображение текста смешанной направленности — unicode bidirectional algorithm.

В JS API Яндекс.Карт существует возможность создавать различные объекты на карте. Один из их них – многоугольник, с помощью которого можно улучшить интерактивность пользовательской карты: выделить отдельные области или отобразить местоположение неточечного объекта. К примеру, так можно показать план строительства нового квартала или зоны доставки пиццы.

У пользователей API Яндекс.Карт давно появился вопрос о добавлении подписей поверх многоугольников. Люди предлагали хитрые решения, чтобы добавить подпись на объект в нужном месте, скрыть ее, перекрасить и т.п., но такие решения получались сложными и негибкими.

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


Отображения региональных слов из словаря Даля, т.е слова которые ищут значительно чаще, чем в среднем по России

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

Продолжаем смотреть технические приемы создания различных анимаций в интерфейсах. Мы уже познакомились с частицами, масками и изменением форм различных объектов — настал черед рисовать пунктирные линии.

Перед тем, как перейти к статье, сделаю небольшое отступление. Эта серия статей предназначена для разработчиков (в первую очередь начинающих), которые хотят делать красивые вещи, но совершенно запутались в сложных инструментах. Каждый раз мы затрагиваем какой-то один прием использования того или иного инструмента и смотрим, к созданию какиих эффектов его можно применить. Комментарии о том, что “во времена флеша было лучше” или что “нужно анимации рисовать в AfterEffects” безусловно имеют право на существование, но будут вырваны из контекста и совершенно не помогут начинающим в решении их задачи.

О существовании SVG знают все, кто занимается фронтендом. Этой технологии уже не один год, про нее уже не раз писали на хабре. Но есть один момент. Частенько на разных ресурсах, в том числе и на тостере, начинающие задают вопросы о создании определенного семейства анимаций на сайте и получают довольно странные ответы от “бывалых” разработчиков. Возникает ощущение, что в такие моменты все думают в контексте HTML+CSS+JS и просто забывают о существовании SVG, предлагая все рисовать на canvas и попутно давая обещания дать тому, кто это придумал, клавиатурой по голове. Но этот путь (рисование на canvas) зачастую слишком сложен относительно решаемой задачи. В предыдущей статье мы обсуждали идеи создания частичных вау-эффектов, а в этой поговорим о масках и посмотрим пару анимаций, которые с их помощью можно сделать.