В предпросмотре не надо рендерить всё рабочее окно
При виде из камеры в предпросмотре рендерится даже та область экрана, которая не попадает в камеру. Это лишняя работа компьютера.



Можно задать собственный размер участка рендера нажав в рабочем окне Ctrl+B (Render Border). Сбросить размеры этого участка Ctrl+Alt+B.

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

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

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

Этой статьёй хочется облегчить порог вхождения в чистый WebGL, дать начальное представление и подсказать, куда двигаться дальше.

Вступление от переводчика

Данная статья является переводом ASP.NET 5 — A Deep Dive into the ASP.NET 5 Runtime — введения в архитектуру DNX и построенного на нем ASP.NET 5. Так как оригинальная статья была написана в марте 2015 года, во время, когда ASP.NET 5 был еще в стадии активной разработки (примерно beta 3), многое в ней устарело. Поэтому при переводе вся информация была актуализирована до текущей версии ASP.NET 5 (RC1), также были добавлены ссылки на связанные ресурсы (в основном на docs.asp.net) и исходный код на GitHub (смотрите только в случаях, если вам интересна реализация). Приятного погружения!

.NET Runtime Environment (DNX)

ASP.NET 5 базируется на гибком, кроссплатформенном runtime, который может работать с разными .NET CLR (.NET Core CLR, Mono CLR, .NET Framework CLR). Вы можете запустить ASP.NET 5 используя полный .NET Framework или можете запустить используя новый .NET Core ^docs, который позволяет вам просто копировать все необходимые библиотеки вместе с приложением в существующее окружение, без изменения чего-либо еще на вашей машине. Используя .NET Core вы также можете запустить ASP.NET 5 кроссплатформенно на Linux ^docs и Mac OS ^docs.

Инфраструктура позволяющая запускать и исполнять приложения ASP.NET 5 называется .NET Runtime Environment ^docs или кратко DNX. DNX предоставляет все что необходимо для работы .NET приложений: host process, CLR hosting логику, обнаружение управляемой Entry Point и т.д.

Логически архитектура DNX имеет пять слоев. Я опишу каждый из этих слоев вместе с их обязанностями.
Изображение взято из статьи DNX-structure ^wiki

Данная статья содержит в себе описание основных возможностей шаблонизатора Handlebars и является свободным переводом его официальной документации. Итак, поехали…

Here comes.

Это будет длинный пост.

Сфера деятельности нашей компании распространяется далеко за пределы игровой разработки. Параллельно с ней мы ведем десятки внутренних проектов, и Data Driven Realtime Rule Engine (DDRRE) – один из наиболее амбициозных.

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

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

Архитектура DDRRE

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

Цель — создать сенсор работающий, условно говоря, в коробке с искусственным освещением и передающий температуру и статус освещения с немедленной реакцией на изменение освещения: включилось, отключилось, мигнуло. Сенсор решено было сделать мобильным и питать от элемента CR2032, иначе говоря, при разряде до 2.7V (предел для датчика TMP36), можно рассчитывать на 200mAh.

Микроконтроллер ATtiny85 имеет всего 5 портов ввода/вывода и возможность отключить RESET в пользу дополнительного порта. Данный бюджет был распределён следующим образом:

• 3 порта — радиомодуль NRF24L01+, спецификация требует пять портов, но в данном случае это не приемлемо и будет использована 3-х пиновая конфигурация;
• 1 порт — датчик освещения на базе фототранзистора BPW17N;
• 2 порта — температурный датчик на базе TMP36, второй порт нужен для подачи питания, чтобы иметь возможность отключать датчик при необходимости.

Элементная база определена, можно приступать к проектированию.

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

Под катом много картинок, аккуратнее с траффиком.

Вторая часть

От переводчика. Статью написал Итай Керен, основатель инди-студии Untame, автор игры Mushroom 11. Получился настоящий учебник по управлению камерой в играх с боковой прокруткой. Хоть там нет ни строчки кода ни на каком языке (вру, одна есть), думаю, несложно будет перевести всё это в инструкции для компьютера. Обязательно к прочтению всем программистам и дизайнерам, которые занимаются динамичными 2D-играми. Терминологию я переводил больше по смыслу: например, position-locking — «привязанная камера». Да, и для многих игр до 1983 года показана версия для Dendy — немного неисторично, но простим.

Введение

Работая над игрой Mushroom 11, я натолкнулся на множество дизайнерских и технических вопросов. Я не рассчитывал, что кто-то напишет о вершинной анимации или плавном изменении формы, но я удивился, что по работе с камерой, задаче с 30-летней историей, тоже практически не пишут.

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

Вопросы ставившие меня в тупик когда я начинал осваивать Blender.

Перенос центра трансформации

Нужно, чтобы дверь поворачивалась вокруг петель, а не вокруг центра двери. Петли условно сейчас находятся на ребре. Переносим 3D курсор точно на центр ребра: Shift+S (Snap)> Cursor to Selected. Потом даём команду перенести центр трансформации в 3D курсор.

Возможно, многие из читателей пытались собрать кубик Рубика 3×3 самостоятельно, но после множества неудачных попыток либо бросали это занятие, либо искали готовое решение. Целью этой статьи является показать на примере кубика Рубика что найти решение любой (из класса решаемых) задачи самостоятельно, есть вполне выполнимая задача для каждого, если при этом руководствоваться определенным набором правил. Данное решение получено мною за 10 часов, плюс этого алгоритма что он не требует запоминать сложные комбинации и длительное время тренироваться — достаточно собрать данным способом всего несколько раз.

КДПВ 2.

Продолжение рассказа о том, что Blender — это несложно, написанный непрофессионалом. Вот начало рассказа.

Эта статья — вторая часть перевода выступления Джона Нески (John Nesky) с GDC14.

Первая часть тут.

#26 Оставлять угол съёмки постоянным в то время, как персонаж бежит по склону

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

Когда мы общаемся с нашими заказчиками, то, будучи специалистами в этой области, активно используем соответствующую терминологию, в частности слово «распознавание». При этом слушающая аудитория, воспитанная на Cuneiform и FineReader, часто вкладывает в этот термин именно задачу сопоставления вырезанного участка изображения некоторому числу (коду символа), которая в наши дни решается нейросетевым подходом и является далеко не первым этапом в задаче распознавания информации. В начале необходимо локализовать карточку на изображении, найти информационные поля, выполнить сегментацию на символы. Каждая перечисленная подзадача с формальной точки зрения является самостоятельной задачей распознавания. И если для обучения нейронных сетей существуют зарекомендовавшие себя подходы и инструменты, то в задачах ориентации и сегментации каждый раз требуется индивидуальный подход. Если вам интересно узнать про подходы, которые мы использовали при решении задачи распознавания банковской карточки, тогда добро пожаловать под кат!

Прим. переводчика: Это перевод статьи Питера Брайта (Peter Bright) «How security flaws work: The buffer overflow» о том, как работает переполнение буфера и как развивались уязвимости и методы защиты.

Беря своё начало с Червя Морриса (Morris Worm) 1988 года, эта проблема поразила всех, и Linux, и Windows.



Переполнение буфера (buffer overflow) давно известно в области компьютерной безопасности. Даже первый само-распространяющийся Интернет-червь — Червь Морриса 1988 года — использовал переполнение буфера в Unix-демоне finger для распространения между машинами. Двадцать семь лет спустя, переполнение буфера остаётся источником проблем. Разработчики Windows изменили свой подход к безопасности после двух основанных на переполнении буфера эксплойтов в начале двухтысячных. А обнаруженное в мае сего года переполнение буфера в Linux драйвере (потенциально) подставляет под удар миллионы домашних и SMB маршрутизаторов.

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

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

От переводчика:

Данная публикация является продолжением материала «Как происходит рендеринг кадра в GTA V». Теперь автор рассматривает вопросы детализации, освещения и пост-обработки кадра. Приятного чтения.

Уровень детализации

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

Огни ночного города

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

Именно с таким заявлением Аарон Гарбут, один из основателей и арт-директоров Rockstar North, выступил незадолго до релиза игры на PS3.

Так ли это? Давайте рассмотрим вот такую ночную сцену:


Огоньки «До»
Осторожно! Трафик!

Космос сам себя не наложит

Предпосылки

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

Давно хотел сделать какой-нибудь проект под Android, а, как известно, основная масса проектов разрабатывается на Android SDK и Java, а NDK рекомендуют использовать только в “критичных по скорости” местах и не делать на нем все целиком.

Но кому нужны все эти рекомендации и правила, когда есть Qt? Java я не знаю в той степени, которую считаю достаточной для качественной разработки игры, и изучать мне ее не хотелось, зато у меня имеются в запасе знания C++. После нескольких тестовых проектов на Qt под Android я понял, что на нем вполне можно разработать полноценное приложение, да еще и перенести его на другие платформы. Так же, посмотрев видео Shia LaBeouf — Just Do it, стало понятно, что я обречен это сделать.

Итак, я хочу рассказать про опыт разработки игры под Android на Qt 5.5.1 и С++.

КДПВ. По мотивам.

О чем пост

Пост написан по мотивам этого комментария . Особенно вдохновила картинка в ответах к этому комментарию. Изначально хотел здесь написать про UI и основы моделлинга в Blender, но выходит многовато (я словообилен). Поэтому, про моделлинг — позже (если публика захочет). А здесь — про UI Blender с точки зрения непрофессионала.

В наши дни, МКЭ — это наверное самый распространенный метод для решения широкого спектра прикладных инженерных задач. Исторически, он появился из механики, однако впоследствии был применен к всевозможным не механическим задачам.

Сегодня имеется большое разнообразие программных пакетов, таких как ANSYS, Abaqus, Patran, Cosmos, и т.д. Эти программные пакеты позволяют решать задачи строительной механики, механики жидкости, термодинамики, электродинамики и многие другие. Сама реализация метода, как правило считается достаточно сложной и объемной.

Здесь я хочу показать, что в настоящее время, используя современные инструменты, написание простейшего МКЭ расчетчика с нуля, для двумерной задачи плоско-напряженного состояния не является чем-то очень сложным и громоздким. Я выбрал этот вид задачи потому, что это был первый успешный пример применения метода конечных элементов. Ну и конечно он являются самым простым для реализации. Я собираюсь использовать линейный, трех-узловой элемент, так как это единственный плоский элемент, в случае которого не требуется численное интегрирования, как это будет показано ниже. Для элементов более высокого порядка, за исключением операции интегрирования (которая не совсем тривиальная, но при этом ее реализация достаточно интересная) идея абсолютно такая же.

Картинка для привлечения внимания: