Данная статья является продолжением рассмотра основ GLTF и GLB форматов. Вы можете найти первую часть статьи здесь. В первой части мы рассмотрели с вами зачем изначально планировался формат, а также такие артефакты и их атрибуты GLTF формата как Scene, Node, Buffer, BufferView, Accessor и Mesh. В данной же статье мы рассмотрим Material, Texture, Animations, Skin, Camera, а также закончим формировать минимальный валидный GLTF файл.

Material и Texture

С мешем неразрывно связаны материалы и текстуры. При необходимости меш может быть анимирован. Материал хранит информацию о том, как модель будет отрендерена движком. GLTF определяет материалы, используя общий набор параметров, которые основаны на Physical-Based Rendering (PBR). PBR модель позволяет создавать “физически корректное” отображение объекта в разных световых условиях благодаря тому, что шейдинговая модель должна работать с “физическими” свойствами поверхности. Есть несколько способов описания PBR. Самая распространенная модель — это metallic-roughness model, которая и используется по умолчанию в GLTF. Также можно использовать и specular-glosiness модель, но только при помощи отдельного расширения (extenstion). Основные атрибуты материала следующие:

1. name — имя меша.
2. baseColorFactor/baseColorTexture — хранит инфомрацию о цвете. В случае атрибута Factor информация хранится в числовом значении для RGBA, в случае Texture — хранится ссылка на текстуру в объекте textures.
3. metallicFactor — хранит информцию о Metallic
4. roughnessFactor — хранит информцию об Roughness
5. doubleSided — имеет значение true либо false (значение по умолчанию) и указывает на то, будет ли меш рендериться с обоих сторон или только с "лицевой" стороны.

Физически-корректный рендеринг

PBR, или физически-корректный рендеринг (physically-based rendering) это набор техник визуализации, в основе которых лежит теория, довольно хорошо согласующаяся с реальной теорией распространения света. Поскольку целью PBR является физически достоверная имитация света, он выглядит гораздо более реалистичным по сравнению с использованными нами ранее моделями освещения Фонга и Блинна-Фонга. Он не только лучше выглядит, но и дает неплохое приближение к реальной физике, что позволяет нам (и в частности художникам) создавать материалы, основанные на физических свойствах поверхностей, не прибегая к дешевым трюкам дабы заставить освещение выглядеть реалистично. Главным преимуществом такого подхода является то, что создаваемые нами материалы будут выглядеть как задумано независимо от условий освещения, чего нельзя сказать о других, не PBR подходах.

Привет, Хабр! Решил написать статью-заметку о небольших трюках, которые использую в своем скромном движке. Это скорее заметка самому-себе, и матёрые программисты лишь усмехнутся, но, думаю, новичкам она может пригодится.

Современная история противостояния Intel и AMD на процессорном рынке ведёт свой отсчет еще со второй половины 90-х. Эпоха грандиозных преобразований и выхода в мэйнстрим, когда Intel Pentium позиционировался как универсальное решение, а Intel Inside стал чуть ли не самым узнаваемым слоганом в мире, ознаменовалась яркими страницами в истории не только синих, но и красных – начиная с поколения K6, AMD неустанно соперничали с Intel во многих сегментах рынка. Однако именно события чуть более позднего этапа – первой половины нулевых – и сыграли важнейшую роль в появлении легендарной архитектуры Core, до сих пор лежащей в основе процессорной линейки Intel.

Немного истории, истоков и революции

Начало 2000-х годов во многом связывают с несколькими этапами в развитии процессоров – это и гонка за заветной частотой 1 ГГц, и появление первого двухъядерного процессора, и ожесточение борьбы за первенство в массовом десктопном сегменте. После безнадежного устаревания Pentium, и выхода на рынок Athlon 64 X2 Intel представила процессоры поколения Core, ставшие в итоге поворотной точкой в развитии индустрии.



Первые процессоры Core 2 Duo были анонсированы в конце июля 2006 года – более чем через год после выхода Athlon 64 X2. В работе над новым поколением Intel руководствовалась в первую очередь вопросами архитектурной оптимизации, добившись высочайших показателей энергоэффективности уже в первых поколениях моделей на базе архитектуры Core под кодовым названием Conroe – они превосходили Pentium 4 в полтора раза, и при заявленном теплопакете в 65 Вт стали, пожалуй, самыми энергоэффективными процессорами на рынке на тот момент. Выступая в роли догоняющей (что бывало нечасто), Intel реализовала в новом поколении поддержку 64-битных операций с архитектурой EM64T, новый набор инструкций SSSE3, а также обширный пакет технологий виртуализации на базе х86.


Кристалл микропроцессора Core 2 Duo

В этой статье я хочу рассказать об архитектуре советских программируемых микрокалькуляторов на примере калькулятора «Электроника МК-52» и как можно внедриться в его архитектуру.

Советские калькуляторы семейства "Электроника Б3-34" («Электроника МК-56», «Электроника МК-61» и «Электроника МК-52») были особенно популярны в СССР. Причиной этому была не только доступная цена в 65 рублей за МК-54, 85 рублей за МК-61 или 115 рублей за МК-52, но и развитой язык программирования. Это семейство калькуляторов стало де-факто стандартным для многочисленных пользователей. Огромное количество книг было посвящено программированию на этих машинках и публикацией готовых алгоритмов. Электроника МК-52 даже летала в космос на корабле Союз ТМ-7, где предполагалось его использование в качестве резервного на случай неисправности спускаемого навигационного оборудования. Даже в военно-морском флоте СССР калькулятор «Электроника МК-52» с блоком расширения памяти БРП «Астро» какое-то время был стандартным средством для навигационных расчетов.

Эволюция современных графических процессоров началась с появления в 1995 году первых 3D-карт, за которым последовало широкое распространение 32-битных операционных систем и недорогих персональных компьютеров.

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

Первые дни потребительской 3D-графики были Диким Западом конкурирующих идей: от способов реализации оборудования до использования различных техник рендеринга и интерфейсов приложений и данных. У первых графических систем имелся фиксированный конвейер функций (fixed function pipeline, FFP) и архитектура, следовавшая по очень строгому пути обработки; при этом графические API практически у каждого производителя 3D-чипов были собственные.

3D-графика превратила довольно унылую PC-индустрию в шоу света и магии, но своим существованием она обязана многим поколениям инноваций. В этой серии статей мы подробно рассмотрим историю GPU: первые дни потребительской 3D-графики, совершившую переворот 3Dfx Voodoo, консолидацию отрасли в начале века и современные GPGPU.

Продвинутое освещение

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

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

Здравствуй Хабр!

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

Все современные процессоры Intel и AMD поддерживают технологию аппаратной виртулизации.
И так, в моем распоряжении был ноутбук с H77 чипсетом и Intel Core i7-3820QM процессором. Согласно спецификации от производителя, мой процессор поддерживал Intel Virtualization Technology (VT-x) и Intel Virtualization Technology for Directed I/O (VT-d) технологии. Если первая имеется почти на всех новых ноутбуках, то вторая технология встречается только на топовых моделях. Но она дает много преимуществ, как например прямой проброс GDU в виртуальную среду, соответственно клиентская машина получает полную поддержку 3D. Но давайте не будем углубляться в технологии, отличные от тематики данной статьи.

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

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


Кадр из сериала

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

Я хотел бы подарить сообществу Хабра статью, в которой стараюсь дать достаточно полное описание подходов к алгоритмам подсчёта единичных битов в переменных размером от 8 до 64 битов. Эти алгоритмы относятся к разделу так называемой «битовой магии» или «битовой алхимии», которая завораживает своей красотой и неочевидностью многих программистов. Я хочу показать, что в основах этой алхимии нет ничего сложного, и вы даже сможете разработать собственные методы подсчёта единичных битов, познакомившись с фундаментальными приёмами, составляющими подобные алгоритмы.

Большинство компиляторов имеют следующую архитектуру:



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

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

Статья ни в коем случае не посвящена современным производственным компиляторам с миллионами строк кода — нет, это краткий курс «компиляторы для чайников», помогающий разобраться, что такое компилятор.

«Мы начинаем разработку новой игры, и нам нужна классная вода. Такую сможешь?»


, — cпросили меня. «Да не вопрос! Конечно, смогу», — ответил я, но голос предательски задрожал. «А, еще и на Unity?», — и мне стало понятно, что впереди очень много работы.

Недавно я начал разбираться с рендерингом «Ведьмака 3». В этой игре есть потрясающие приёмы рендеринга. Кроме того, она великолепна с точки зрения сюжета/музыки/геймплея.



В этой статье я расскажу о решениях, использованных для рендеринга The Witcher 3. Она не будет такой всеобъемлющей, как анализ графики GTA V Адриана Корреже, по крайней мере, пока.

Мы начнём с реверс-инжиниринга тональной коррекции.

Гамма-коррекция

Итак, мы вычислили цвета всех пикселей сцены, самое время отобразить их на мониторе. На заре цифровой обработки изображений большинство мониторов имели электронно-лучевые трубки (ЭЛТ). Этот тип мониторов имел физическую особенность: повышение входного напряжение в два раза не означало двукратного увеличения яркости. Зависимость между входным напряжением и яркостью выражалась степенной функцией, с показателем примерно 2.2, также известным как гамма монитора.

В данной статье рассматривается перехват функций графического API на примере DirectX 9 под x64 применительно к игре Dota 2.

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

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

Первая часть
Вторая часть

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

Как я уже говорил в первой статье, я решил использовать страницы размером 4 МБ, чтобы упростить себе жизнь и не иметь дела с иерархическими таблицами. В дальнейшем я надеюсь перейти на страницы размером 4 КБ, как большинство современных систем. Я мог бы использовать готовый (например, такой блочный аллокатор), но написать свой было чуть интереснее и хотелось чуть больше понять, как живет память, так что мне есть, что вам рассказать.

Всем привет! Вот и закончились длинные мартовские выходные. Первую послепраздничную публикацию мы хотим посвятить полюбившемуся многим курсу — «Разработчик Python», который стартует менее, чем через 2 недели. Поехали.

Содержание

1. Память – пустая книга
2. Управление памятью: от оборудования к программному обеспечению
3. Базовая реализация Python
4. Концепция глобальной блокировки интерпретатора (Global Interpreter Lock, GIL)
5. Сборщик мусора
6. Управление памятью в CPython:
   
   • Пулы
   • Блоки
   • Арены
7. Заключение

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

Прочитав эту статью, вы:

• Узнаете больше о низкоуровневых операциях, особенно касательно памяти.
• Поймете, как Python абстрагирует низкоуровневые операции.
• Узнаете об алгоритмах управления памятью в Python.

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

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

Этот блог выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий тикет. Все исходники для статьи здесь.

Введение

Из прошлой статьи мы узнали о принципах страничной организации памяти и о том, как работают четырёхуровневые страничные таблицы на x86_64. Мы также обнаружили, что загрузчик уже настроил иерархию таблиц страниц для нашего ядра, поэтому ядро работает на виртуальных адресах. Это повышает безопасность, но возникает проблема: как получить доступ к настоящим физическим адресам, которые хранятся в записях таблицы страниц или регистре CR3?