#houdini #whatsnew #release #python

В H20.5 изменилась версия Python, но что дал переход на 3.11 по сравнению с 3.10?
В основном это конечно про импрув по производительности и уменьшению оверхедов.

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

PEP 657: Fine-grained error locations in tracebacks
При печати трассировки интерпретатор теперь будет указывать не просто на строку, а на точное выражение, вызвавшее ошибку.

xs = []
prant(xs.caunt())

Traceback (most recent call last):
  File "/tmp/main.py", line 13, in <module>
    prant(xs.caunt())
    ^^^^^
NameError: name 'prant' is not defined. Did you mean: 'print'?

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

Если мы исправим функцию prant() на print(), то следующая ошибка будет уже про неверный метод в листе.

Traceback (most recent call last):
  File "/tmp/main.py", line 13, in <module>
    print(xs.caunt())
          ^^^^^^^^
AttributeError: 'list' object has no attribute 'caunt'. Did you mean: 'count'?

Правда это помогает не всегда 😐

Python 3.10

Traceback (most recent call last):
  File "/opt/hfs20.0.761/houdini/python3.10libs/hou.py", line 17795, in loadItemsFromFile
    return _hou.OpNode_loadItemsFromFile(self, file_name, ignore_load_warnings)
hou.OperationFailed: The attempted operation failed.

Python 3.11

Traceback (most recent call last):
  File "/opt/hfs20.5.305/houdini/python3.11libs/hou.py", line 18114, in loadItemsFromFile
    return _hou.OpNode_loadItemsFromFile(self, file_name, ignore_load_warnings)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hou.OperationFailed: The attempted operation failed.

Вот трассировка одной функции, одной и той же библиотеки в H20.0 и H20.5. Сразу понятно теперь где нужно и что исправлять. 🤡

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

#houdini #github #opencl #copernicus #cop

Небольшие эксперименты на OpenCL в COP. Некоторые реализации просто порт с OSL, что тоже открывает дополнительные возможности для изучения OpenCL когда есть готовый алгоритм.
Я так понимаю, что автор планирует расширять библиотеку, поэтому полезно следить за обновлениями.

https://github.com/melMass/cops-cl?tab=readme-ov-file

#houdini #whatsnew #release #fx #mpm

После нескольких тестов с MPM Solver решил поискать самостоятельно причины "невысокой производительности" и нашёл тесты годичной давности автора и создателя по всей видимости MPM Solver'а в H20.5.

ICE (Neural Temporal Adaptivity for the Material Point Method Accelerated on the GPU) был создан в рамках магистерской программы в Университете Макгилла и программы Mila. Приложение представляет собой автономный MPM Solver, написанный на C++/CUDA. Оно использует встроенную 3D-конволюционную нейронную сеть для асинхронного определения активных областей моделирования. Экспериментальные результаты показывают улучшение производительности в практических сценариях. Несмотря на то, что это не плагин, был создан небольшой набор HDA, позволяющий создавать сцены в Houdini напрямую. Все симуляции были отрендерены с помощью Karma XPU.

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

Scene        Particle Count  Grid Res.  Timestep (×10-4) Sec/Frame Ad.Speedup
Ship Breach      54.0M   492 x 212 x 492     6.9           16.6      3.38x
Bullet Time      24.1M   688 x 364 x 492     4.2           17.9      1.05x
Avalanche        35.5M   736 x 148 x 760     21.0          7.5       1.53x
Train Push       24.9M   520 x 144 x 174     2.6           28.8      1.55x
Rally Drift      14.9M   1400 x 196 x 536    1.1           40.7      2.00x
Glacier Collapse 39.5M   320 x 184 x 520     6.9           16.4      1.00x

Глядя на результаты в таблице есть 2 соображения:

- В H20.5 я ничего не нашёл про Neural Temporal Adaptivity применительно к MPM Solver для улучшенного и прагматичного солвинга, сейчас это "чисто" расчёты с помощью OpenCL и использование разряженной сетки NanoVDB в фоне. (Проглядел или это задел на следующий релиз?) У автора в работе PDF по его диссертации открывающая детали реализации ICE, но пока у неё статус Coming Soon...

- MPM Solver в целом и не был никогда реалтаймовым (даже у DreamWorks) чего от него многие ожидали глядя на то что это расчёты на GPU, но на то это и презентация 🤪. OpenCL конечно в ряде сценариев намного может быть быстрее чем VEX, но данные (и их не мало), всё равно приходится перегонять по шине так или иначе между хостом и компьют девайсом память, а это зачастую неизбежные потери + H должна менеджерить остальные ресурсы и заниматься красивой отрисовкой во вьюпорте.
Скажем спасибо, что это было реализовано хотя бы не на CPU.

На данный момент важный и основной вопрос почему в MPM Solver такое высокое количество сабстепов по умолчанию и почему такая медленная компиляция ядер?

Документация говорит, что:
Солвер динамически выбирает наименьшее количество сабстепов, основываясь на типе и скорости материала. Хотя по умолчанию максимальное значение установлено на 10 000, это не означает, что обязательно будет использовано 10 000. Фактическое количество сабстепов можно увидеть на выведенной геометрии в качестве дитэйл аттрибута. Высокое значение по умолчанию предназначено для более жестких материалов, таких как бетон или металл, которые требуют большего количества подшагов и, как ожидается, будут медленными.

Это значит что и CFL, и Material Conditions накладывают свои собственные независимые ограничения на максимально допустимый интервал таймстэпа. При солвинге очень жестких материалов (ограниченных условием материала, например металла или бетона) объекты будут двигаться относительно быстро без заметных изменений в количестве сабстепов требуемых условием CFL.

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

Но будем надеяться, что скорейший мастер-класс сможет прояснить ситуацию на эти вопросы включая и не быструю компиляцию ядер 😕

https://www.youtube.com/watch?v=md_UXDYrlL4&ab_channel=AlexandreSirois-Vigneux

#houdini #whatsnew #release #fx #mpm

███▄ ▄███▓ ██▓███ ███▄ ▄███▓
▓██▒▀█▀ ██▒▓██░ ██▒▓██▒▀█▀ ██▒
▓██ ▓██░▓██░ ██▓▒▓██ ▓██░
▒██ ▒██ ▒██▄█▓▒ ▒▒██ ▒██
▒██▒ ░██▒▒██▒ ░ ░▒██▒ ░██▒
░ ▒░ ░ ░▒▓▒░ ░ ░░ ▒░ ░ ░
░ ░ ░░▒ ░ ░ ░ ░
░ ░ ░░ ░ ░
░ ░

Не верьте блогерам, знакомым, коллегам которые пиарят MPM как "blazing fast" решение, они показывают флипбук 😅

Ещё немного эксклюзива ⚡️ про MPM Solver. Я не стал дожидаться появления мастер-классов и попутно пока делал предыдущий пост про MPM написал автору чтобы уточнить пару вопросов про его работу над этим солвером.

- Почему в H20.5 в настройках солвера по-умолчанию установлены такие высокие сабстепы?

Я слышал, что многие люди были разочарованы тем, что, хотя MPM активно использует OpenCL, но отзывчивость тестовых примеров в H20.5 во вьюпорте очень низкая даже на очень хороших рабочих станциях с видеокартами Nvidia 4090.
Хотя если значительно снизить количество сабстепов то становится намного лучше, но стабильность симуляции падает.
Может быть есть какие-то оптимальные настройки для старта?

Alexandre Sirois-Vigneux:
- MPM печально известен своей медлительностью. По моему скромному мнению, CPU MPM просто непригоден для использования. Я сделал GPU MPM только для того, чтобы сделать его пригодным для использования в производстве, но он не быстрый, если сравнивать его с более простыми алгоритмами флюидной динамики.
Он быстр, только если сравнивать его с CPU MPM, который большинство людей никогда не использовали. Учитывая это, я постараюсь сделать его быстрее в будущем, но я не ожидаю увеличения скорости на порядки.
Явное интегрирование в паре с жесткими материалами действительно требует большого количества сабстепов.

- Правильно ли я понимаю, что ваша диссертация по использованию нейронной временной адаптивности для MPM все еще в работе? И в H20.5 этот метод не реализован? Сейчас реализованы только GPU-вычисления?

Alexandre Sirois-Vigneux:
- В настоящее время мы не используем никаких нейронных сетей и не делаем локальную временную адаптивность. Причина в том, что мы хотим сохранить как можно больше памяти для самого сима.
Фризинг партиклов появится в следующей итерации (здесь он не поясняет это, но я так понимаю, что имеется ввиду, что сейчас неактивные партиклы всё равно участвуют в симе), но оно, скорее всего, не будет опираться на нейронные сети. Сначала будут протестированы более простые подходы.

Продолжение следует...

#houdini #opencl #cop #sop

При использовании OpenCL в SOP, а теперь ещё в COP можно столкнуться с неожиданными ошибками приводящими к неопределённому поведению.

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

OpenCL очень редко сообщает когда вы совершаете логическую ошибку, а в некоторых случаях и синтаксическую.

Например, неявное приведение типов из float в и int в VEX

int x = 10.5;

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

OpenCL же не выдаёт по-умолчанию никаких предупреждений или намёков на что-то подобное, но можно этому процессу помочь используя Kernel Options или Compiler Options чтобы сделать предупреждения явными, а так же сделать предупреждения строгими ошибками компиляции.

В OpenCL SOP это указывается в Kernel Options флагом -Werror, а в OpenCL COP Compiler Options, после этого компилятор будет под прицелом смотреть на весь код, что будет очень полезно чтобы избежать ошибок на ранних стадиях.

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

int x = 1.9f;

// OpenCL Exception: <kernel>:1581:13: 
// error: implicit conversion from 'double' to 'int' 
// changes value from 1.9 to 1

int x = (int)1.9f;

Здесь та же самая ситуация, мы используем несовместимые типы в сигнатуре функции и передаваемом аргументе.

void foo(int* ptr){}
foo(10);

// OpenCL Exception: <kernel>:15:9: 
// error: incompatible integer to pointer conversion 
// passing 'int' to parameter of type '__generic int *'

int x = 10;
foo(&x);

Мне очень нравится, что таким образом можно проверить находится ли значение в границах массива, не вызывая падения Kernel в неожиданных местах.

int arr[] = {1,2,3};
int x = arr[100];

// OpenCL Exception: <kernel>:1582:13: 
// error: array index 100 is past the end of the array 
// (which contains 3 elements)

Это разумеется не все ошибки, но одни из популярных с какими сталкиваются часто.

#houdini #nodeinfo #network

Кто ещё находится на стадии отрицания с новым UI в Node Info всё ещё можно вернуться к "старому виду" используя недокументированную переменную окружения:

HOUDINI_USE_OLD_INFO_WINDOW=1

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

#houdini #meme

Когда изучил всю документацию, посмотрел фоном все курсы и стримы Horikawa от корки до корки и теперь готов написать свой первый, рабочий код..

#check #github #pipeline #python #cpp #rust

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

Вот с такой на данный момент структурой:

#[derive(Debug)]
#[cfg_attr(feature = "arbitrary", derive(arbitrary::Arbitrary))]
pub struct CheckResult<Item: crate::Item, Items: std::iter::IntoIterator<Item = Item>> {
    status: crate::Status,
    message: String,
    items: Option<Items>,
    can_fix: bool,
    can_skip: bool,
    error: Option<crate::Error>,
    check_duration: std::time::Duration,
    fix_duration: std::time::Duration,
}

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

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

https://github.com/scott-wilson/openchecks

#houdini #vellum #rnd #github #opencl #cpp #hard

Возможно кого-то вдохновит этот небольшой плэйлист по созданию Vellum Solver(XPBD) с нуля, но с позиции более "упрощённого" солвера.
Автор с ангельским голосом проведёт вас через бОльшую часть этапов создания от идеи до реализации, но это конечно не подробный обзор каждого атрибута, параметра, значения, поскольку здесь всё таки нужно уловить суть.
⚠️ Это несомненно хард и конечно и не для всех, но такой материал редко можно увидеть в свободном доступе.

https://www.youtube.com/playlist?list=PL9mEiwkYhL1Y55UYIUuRLmwA3re5c7hAy

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

GitHub: https://github.com/Jingzheng-Li/Houdini_Learn_Microsolvers

⚡️На закуску: по страничке видно, что автор так же делал попытки написать свой MPM Solver, который выложен с исходниками на HDK с парой сцен для тестирования.
Может скопилировать и посмотреть? 🙂

#houdini #meme #group #syntax

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

#houdini #nextrelease #topic

▄████ ▓█████▄ ▄▄▄▄
██▒ ▀█▒▒██▀ ██▌▓█████▄
▒██░▄▄▄░░██ █▌▒██▒ ▄██
░▓█ ██▓░▓█▄ ▌▒██░█▀
░▒▓███▀▒░▒████▓ ░▓█ ▀█▓
░▒ ▒ ▒▒▓ ▒ ░▒▓███▀▒
░ ░ ░ ▒ ▒ ▒░▒ ░
░ ░ ░ ░ ░ ░ ░ ░
░ ░ ░
░ ░
💥По доброй традиции, ставшей уже классикой в мире H, после каждого минорного и мажорного релиза каким-то случайным юзером форума (раньше и сейчас был OdForce) создаётся новая тема с листом ожиданий от следующего релиза где юзеры могут накидать на вентилятор идей чего бы хотелось видеть уже в следующем релизе.

Обычно большинство пожеланий выглядят так:
- больше GPU вычислений (везде где только можно, SOP, DOP, COP и т.д)
- больше AI, ML в H (больше ассистентов для кода, хочется ML для разного рода симульни с предсказуемым результатом),
- больше понятного и классного UI/UX
- больше современных решений и подходов (кто-то уже там на fVDB замахнулся, а он только был анонсирован недавно...)

Ну вы поняли в общем..

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

В H ~35 переменных окружения которые должны помогать решить проблему отладки: HOUDINI_*_ASSERT, HOUDINI_*_DEBUG, HOUDINI_*_ERROR, HOUDINI_* (undoc).
Некоторые помогают справиться с некоторыми проблемами, но флагам отладки неподвластны unrecoverable errors такие как Karma Error: Command Exit, Fatal Error (сидеть в обнимку с gdb houdini-bin мало кто захочет) и тому подобные ошибки. Ведь сколько раз мы задавали себе и друг другу этот вопрос, что означает Mantra: Render Error -123456789 ? Очень большая часть вопросов на форуме, группах посвящена только этому, что ознают коды ошибок и что с этим делать?

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

Мой небольшой список улучшений выглядит вот так:
- More flags for debugging (General, OpenCL, COP, DOP, etc.)
- Redesigned or new error handling system
- Built-in system for sending error reports
- Reworked HDK documentation
- Documentation of VEX, OpenCL, OSL, etc. code (which is connected by #include directives in snippets)
- Ability to save more settings in configuration files, as well as use the Python API for this

Загадываю желание, что в H23 это всё будет!

https://www.sidefx.com/forum/topic/97475/

#houdini #cop #opencl

Hello, COPernicus!

И как не посмотреть на этот новый COP контекст в H20.5, о котором уже слышал достаточно отзывов, что сыро, баговано и работает криво. Надо посмотреть!
Поэтому решил сразу проверить его каноничным примером после Hello,World! это генерацией множества Мандельброта на OpenCL.

Я честно говоря ожидал, что этот пример будет идти из коробки для разного рода тестов, но там был другой эстетический фрактал Julia неразрывно связанный с множеством Мандельброта.
Поэтому быстро сделаем его сами, пока игрался с подбором параметров резко и неожиданно словил багу, что Tile Size у OpenCL лучше не устанавливать отрицательным значением иначе H уходит в бесконечный цикл , я это сделал случайно когда у Ladder Slider сдвинул параметр мышкой не туда 🙂

Кому захочется поиграться или добавить в свои пресеты рецепы, вот исходный код (который уже не поместится в это сообщение):
https://pastebin.com/8UmqJEkk
(у параметра dst нужно изменить тип с Varying на RGBA для красивой отрисовки цветов)

#houdini #vex #hda #std #todayilearned

Не особо популярные возможности использования AttribWrangle взятые из стандартной библиотеки SideFX HDA которые можно так же использовать в своей работе или хотя бы взять на заметку. Картинки пронумерованы поэтому пойдём по пунктам:

TD;LR:

1. Чтение данных из второго входа и запись в атрибут Detail выходной геометрии.
2. Вычисление результатов на месте без создания промежуточной копии геометрии.
3. Создавайте атрибуты только в том случае, если их имена соответствуют шаблону.
4. Обработка ошибок на VEX, так же и в графе.
5. Референс снипетов кода в другие снипеты.

А теперь подробно:

1. Это довольно распространённый приём во всей библиотеки, где основная суть прочитать данные (атрибуты) со второго входа и записать их на Detail выходной геометрии. Однако это так же может использоваться как ещё один способ создания и новой геометрии, избегая создания ещё одного цикла в конце снипета чтобы удалить входящую геометрию, т.е вместо такого:

for(int i = 0; i < nprimitives(0); ++i)
    addpoint(0, vector(prim(0, "P", i)));

for(int i = 0; i < nprimitives(0); ++i)
    removeprim(0, i, 1);

можно будет просто написать

for(int i = 0; i < nprimitives(1); ++i)
    addpoint(0, vector(prim(1, "P", i)));

Добавили чуть оптимизации и меньше написали!

2. Compute In Place. При компиляции Attribute VOP может работать с входящей геометрией на месте, не создавая ее копию. Это может ускорить обработку, так как создается на одну копию меньше, но требует, чтобы код VEX не связывал для записи любые атрибуты, которые считываются из первого входа.
Вы можете записывать в любые атрибуты, только НЕ в те, из которых вы читаете, так как он не создаст копию геометрии, поэтому не сможет прочитать оригинальные значения, если они будут перезаписаны.
При попытка сделать запись вида @P = point(0, "P", @ptnum); будет выброшена ошибка вида Error: Attempt to read from actively streamed attribute P.

Эта особенность так же активно эксплуатируется во всей библиотеки там где можно и не нужно. И наибольшую выгоду от использования можно почувствовать если использовать её именно в блоке компиляции на большом количестве геометрии (>10 лямов). Некоторые люди отмечали внушительный 3-4х кратный прирост при обработке, но в других сценариях польза может быть более изотерична и не так выражена.

Здесь вопрос оптимизации отрытый и более тонкий (много где включено по-умолчанию в ассетах).

3. Шаблон по умолчанию позволяет создать любой атрибут. Вы можете ограничить создаваемые атрибуты, заменив * на список разрешенных имен.
Стандартная библиотека смотрит это как на своего рода иммутабельность атрибутов, те которые явно экспортируются те и используются, все остальные только для чтения. Это предотвращает ситуации когда вы случайно хотите поменять значение в атрибуте который менять нежелательно. В таком случае компилятор скажет: Error: Read-only expression on left side of assignment (1)).

4. Обработка ошибок в VEX 💣 представлена разными функциями: warning,error. error cообщает о пользовательском предупреждении VEX во время выполнения. При этом используется тот же синтаксис строки формата, что и в printf. Так же нередко используется и одноимённая нода Error которая так же может полезна когда вы хотите дать обратную связь сразу если входные данные невалидны со своим сообщением. Приятней видеть всё таки понятные ошибки вида: Ты не видишь бл*ть!? Атрибута нет! вместо id not found.
(На этом скрине так же видно, что автор вообще не экспортирует никакие атрибуты явно показывая, что тут не происходит создания новых атрибутов, поэтому параметр Attributes to Create пуст)

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

На этом пока всё 🙂

https://imgur.com/a/fTRUtbq

#houdin #apex #cop #whatsnew #release

APEX isn't JUST for rigging!!!

Да, начиная с H20.5 в APEX можно теперь собирать дебажить COP граф. Что можно с этим сделать в APEX?

Пока немного, COP может генерировать граф APEX, который был скомпилирован и выводит его в виде геометрии, а не как результат целенаправленной обработки COP во вьюере.
Это в основном для отладки или эзотерического использования, например для генерации slap-comp-файлов формата bgeo или bgeo.sc, простыми словами, возможность применять одинаковый пре-комп к разными USD файлам.

Например, husk --slap-comp geo/defocus.bgeo geo/test.usdnc, а не копировать из сцены slap-comp каждый раз в новую сцену. Этот параметр может встречаться несколько раз, и каждая операция выполняется последовательно.
Это так же может быть запущенно непосредственно с ROP ноды в Solaris.

Нооо, поскольку COP это бета, всё чего я добился это:

55225: Fatal error: Segmentation fault (sent by pid 0)
-- TRACEBACK BEGIN --
...
-- TRACEBACK END --

Видимо надо подождать ещё 🙂

#asfw #materialx #openpbr

MaterialX Virtual Town Hall 2024

Про новый стандарт OpenPBR Surface и релиз MateriaX 1.39 с тайм-кодами.

Если коротко то референсная имплементация есть уже в MaterialX 1.39, в Adobe Substance тюнится, Arnold (3ds Max, Maya, Katana), Omniverse уже есть, в Houdini будет в следующем релизе.

- Intro

New Features:
- Energy-preserving Oren-Nayar
- New fuzz model
- Coat darkening
- Dispersion scale
- More expenssive layer ordering
- Art-directable metal model
- Other user-friendly tweaks

- Future Work

MaterialX Updated:
- Pixar (OpenUSD & Hydra)
- Omniverse
- LookdevX in Maya
- V-Ray
- Houdini

Вообще на их канале вышло много свежего видео про разные опенсорсные разработки (видеоплееры, рендер-менеджер, форматы изображений).

Это. Просто. Интересно.