На каналі вийшов новий відос, продовжуємо робити гру у кості. У цьому випуску ми переходимо до програмування гри використовуючи модель з минулого випуску, бібліотеки threejs для графіки та cannonjs для фізики

👉 https://youtu.be/4ZlP-ATpp9Y

Якщо вам сподобався випуск, закиньте пару гривень на збір дрону для ЗСУ 💵 https://send.monobank.ua/jar/7k7wWbnWHv

Також приймаю заявки на теми для майбутніх випусків, пишіть в коментарях під постом.

​​Я давно хотів спробувати збудувати свій 3D рушій, зробити невеличку гру і в процесі роздуплитись як працює графічний пайплайн. Насправді пробував це робити разів п’ять, але кожного разу щось не виходило і тому забивав.

Тут нещодавно втрапив на канал хлопця, який робить свій рушій та гру про ферму, дуже кльовий блог, рекомендую https://youtube.com/playlist?list=PLRIWtICgwaX02ANbLFknXLbLsHdhS_e-Z

Мені сподобалось, як він працює над проєктом: розставляє пріоритети, не витрачає час на другорядні штуки і додає в рушій виключно ті функції які потрібні для гри.

Я надихнувся його відосами і вирішив ще раз спробувати пірнути у цей світ, і як не дивно, поки що все йде добре.

Я пішов шляхом Java, бо там вже все є і воно для мене зрозуміліше ніж сішка, і звичайно що є можливість обмазати це все кложурою щоб почуватись як вдома.

На разі маю вікно, завантаження та відображення моделей, шейдер з базовим освітленням та систему обробки подій.

Далі буду робити контроллер для камери, дороблю матеріали та шейдер і буду пробувати робити невеличкі демки для тестування.

По бібліотекам:
lwjgl — менеджер вікон
bgfx — кросс платформний рендеринг (OpenGL, Metal, Vulkan, etc)
assimp — парсер форматів 3D моделей
nuklear — рендеринг UI
yoga — флексбокс лейаут для UI
joml — векторна на матрична математика

Ресурси для вивчення:
- https://learnopengl.com/ все про OpenGL
- https://lwjglgamedev.gitbooks.io/3d-game-development-with-lwjgl/content/ більше конкретно про побудову ігор з lwjgl
- https://lettier.github.io/3d-game-shaders-for-beginners/index.html про базові шейдери в іграх

На каналі вийшов новий випуск/туторіл, аж на півтори години, у якому ми створюємо реалістичну модель гасової лампи у Blender.

Процес включає моделювання, шейдинг, створення оточення, освітлення сцени та пост обробку.

Лайк, шер, підписка, якщо вам подобаються такі відоси або вони допомогли вам вивчити щось нове.

👉 https://youtu.be/CmxdjRt75TY

Повертаючись до гри у кості: вийшов відос де ми робимо реалістичний кубик у Blender для гри. А за тиждень вийде фінальний випуск с закінченням розробки гри, плюс бонусне відео по процедурним шейдерам.

👉 https://www.youtube.com/watch?v=8nwLDM6uS7o

Трейтій заключний випуск по створенню гри у кості 👉 https://youtu.be/f02ctsytnlM

Створюємо логіку визначення очок та пробуємо кинути 50 кубиків 🙌

Трохи про старлінк і екофлоу після пари місяців користування.

Про старлінк багато не розкажу, бо в умовах міста і не маючи можливість встановити його на даху — це бляшанка. На балконі він ще так сяк працює, але з постійними перебоями. Ідеально ставити на дах або у полі.
Плюс конструкція не дозволяє від’єднати дріт, щоб протягнути його через просвердлену дірку у стіні, тому його або треба розбирати або свердлити дірку побільше.

Екофлоу на пів кіловата — топчік! Небагато, але для відносно недовгих відключень вистачає з головою для домашніх справ, ще й на пару годин подивитись проектор ввечері. Час заряду (до години) супер тєма, бо я хотів брати якийсь упс і акум, але воно довше заряджається та і в цілому вся конструкція громіздка та не мобільна.

Єдиною проблемою залишається інтернет, нажаль опції з оптикою в квартиру нема, але поки шо 3G у Vodafone вистачало.

Доречі живучи у старому будинкові я зацінив газ та газову колонку, бо з цим проблем не буває.

Бонусний випуск про процедурні геометричні фігури у шейдерах, на прикладі того ж грального кубика.

Створення складних геометричних шейдерів за допомогою вбудованої математики — це окремий вид мистецтва. Але мінус 100% процедурних шейдерів у тому, що вони менш реалістичні, тому що в реальному житті об’єкти мають варіативність яка ніколи не повторюється: мікродефоомація поверхні, нерівномірне відбивання світла, подряпини, пил, відбитки пальців і тд.

👉 https://youtu.be/Fj9PRSUy34c

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

Це був гарний досвід, мені вдалось створити свою невеличку сервісну команду, провести її від роботи в стилі реагування на проблеми до проактивної роботи з проблемними місцями і їх виявленням. За цей час поміж усього ми побудували систему спостереження за перформансом фронтенду та інтегрували її у продуктові команди, паралельно навчаючи інженерів роботі з перфомансом.

З часом команда змінила свій фокус на архітектуру фронту і так як це співпало з моментом реструктуризації у компанії, наступним природним кроком для нас було розподілити членів команди між декількома продуктовими командами, щоб розширити зону впливу.

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

​​Замітка про форматування коду.

Побачив у Твіттері оцей пост про плагін для Prettier для форматування масивів. Це цілком валідний кейс, і у той же час іронічний з точки зору єдиного правила форматування коду.

У даному випадку масив значень насправді відображає набір значень кольорів у форматі rgba, тобто візуально, для читання, має сенс групувати значення по 4 штуки на рядок.

Форматування коду у свою чергу побудовано на синтаксисі конкретної мови програмування. У випадку з масивом розробник якби додає неявний синтаксис (структуру) у звичайний масив. Звичайно форматтер про це знати не може, тому людині треба проінформувати програму як саме форматувати конкретний блок коду.

Напевне ця проблема зустрічається рідко у JS, а от наприклад у ліспах (типу Clojure), це більш росповсюджено, бо нерідко використовуються макроси, які додають свій синтаксис, а отже і форматування яке має сенс для читання коду. Також конкретно у Clojure розповсюджений підхід до створення data-driven DSL, коли невеличка мова описується даними. В таких DSL теж є свій синтаксис і форматування.

У форматтерах для Clojure також є система налаштування форматування макросів, а форматування даних менш жорстке і часто форматтер не змінює написане розробником. Це цікавий трейдофф заради кращого UX.

​​Йобана русня не дала сьогодні нормально виспатися. Поки у Києві працювало ППО ми робили млинці 🥞

Повертаючись до проєкту 3D рушію: за два тижні я все ж таки роздуплив і зробив тіні методом проеціювання карти тіней.

Не менш цікава проблема — згладжування тіней, бо текстура з тінями на виході має відносно невелику роздільну здатність і виглядає зубчато.

Все це описано у туторіалі за посиланням http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/

Наступним кроком роблю механізм вибору об’єкту на екрані, щоб знати який саме об’єкт знаходить під курсором миші.

Це можна зробити правильно і проеціювати позицію курсору на окремі полігони, а можна схитрувати і рендерити сцену у кольорову текстуру де кожен об’єкт заповнений унікальним кольором. Тоді по кольору під курсором можна визначати який саме об’єкт був обраний. Недолік такого підходу у тому, що текстуру треба копіювати з GPU у RAM, що начебто повільно. Але насправді все залежить від складності сцени.

Багато часу йде на склеювання C та Java, але в цілому я задоволений і динамічне середовище мені все ж більш до душі.

​​Отже знов про графіку та програмування. За минулі три тижні я зробив і переробив досить багато, вивчив багато нового і подивився купу відосів, встиг заїбатись і прийшов до висновку, що треба вчити C++, але про все за порядком.

З візуального я встиг зробити UI систему поверх NanoVG — бібліотека для рендерингу векторної графіки та тексту, та Yoga — алгоритм flexbox лейауту. Працює швидко, 60fps без кешування, просто все разом рендериться з нуля на кожен кадр, включаючи лейаут. Після браузеру це звичайно пушка ракета по відчуттям. Звичайно що поверх цього ще треба було зробити систему подій, компоненти зі станом, кнопки та прокрутку мишкою, все це вийшло не так складно зробити як я то собі придумав. Єдине до чого не дійшов поки що — це текстові поля, там найбільше гемору. Поки робив UI систему, зробив собі дебагер сцени. Це все показано у прікріпленому відосі, також приклади з кодом UI компонентів отут.

Врешті я вперся в витік пам'яті при зміні розміру вікна. За 10 секунд ресайзу процес застосунку виїдав десь 3 гігабайти пам'яті в GPU. Так ставалося, бо на кожну зміну розміру вікна треба створювати текстуру нового розміру для відображення на екрані та вивілняти пам'ять видаленої текстури, проблема була якраз з вивільненням пам'яті. Я так і не розібрався де саме у коді стається витік, але дійшов висновку, що проблема десь у шарі між Java та C. На цьому етапі я задумався чи хочу надалі боротися з таким типом неявних проблем, чи краще вже вивчити C++ і отримати ті ж самі проблеми з пам'яттю, але більш явні, хехе.

Насправді для програмування графіки все ж таки вже є багато бібліотек та туторіалів на плюсах, не враховуючи Unity та C#. Плюс в Java всі ті бібліотеки все одно змушують тебе оперувати буферами даних, самому менеджети пам'ять та ручками виділяти пам'ять на стеку, і це няпряжно, коли треба робити штуки неканонічні для динамічного середовища.

Отже поки що я вчу плюси по туторілам оцього чувака https://www.youtube.com/@TheCherno (доречі в нього також є кльова серія по створенню ігрового рушію, контент топ і подача також супер) і переписую кложуру на плюси. Подивимось як воно буде далі 🙂

​​Ось я переписав все на плюсах щоб з'ясувати, що витік пам'яті був не у моєму коді і не у прослойці між Java та C, а у бібліотеці яку я використовую під капотом для кросплатформенного рендерингу, лол. Виявилось, що проблема пов'язана з апаратним зглажуванням, тому поки шо я його відключив. Можливо доречі це проблема конкретної платформи або рендеринг бекенду (в мене на ноуті це macOS та Metal).

Це добрі новини, бо тепер я можу повернутись до Clojure, хоча було цікаво вперше написати щось "реальне" на плюсах. Очікувано той самий код на плюсах стартує десь півсекунди, коли JVM розганяється секунди 3-4. Але я поки що неготовий жертвувати продуктивністю заради швидкості. Чого тільки коштувало зібрати усі бібліотеки до купи та налаштувати білд, мені менше нервів зробив конфіг Webpack ніж cmake. Хоча от для VS Code є розширення CMake Tools, воно прям добре працює. Чого не скажеш про IntelliSense для C/C++, він нерідко тормозить і видає автодоповнення з затримкою у декілька секунд.

Повернувшись до початкового проєкту я додав базову аудіо систему за допомогою OpenAL. Взагалі мені як веб розробнику достатньо цікаво подивитись як оці усі штуки зроблені "під капотом". Бо працюючи з браузером я по факту пишу код для системи, де усі базові компоненти вже інтегровані і готові до використання. Саме тому доречі частково Electron/Chromium так багато і важить, бо там вже все є, для всіх платформ і зверху (чи знизу) помазано роками легасі.

Далі я почав працювати над тим, що називається instanced rendering — це коли один об'єкт можна відрендирити мільйон разів на екрані і нічо не буде тормозити, бо більшість роботи виконує GPU, по суті ця техніка знімає оверхед на коммунікацію з CPU. Найросповсюдженіший приклад застосування instanced rendering — системи частинок, тобто візуальні ефекти (дим, іскри, тощо). Також незабаром планую довести до нормального стану UI систему, бо зараз там нахачено з усіх боків.

Найголовніше, зробив собі борду щоб було подорослому.

​​Пограв пару годин в “Hi-Fi Rush”, дуже сподобався візуальний стиль у грі, у поєднанні з музикою під яку рухається увесь світ навколо і сам персонаж. Виглядає як мікс американських коміксів та японського аніме, бойова складова нагадує Devil May Cry. Кльова динамічна гра, рекомендую 👌

Може ви вже бачили черговий срач за участі автора бібліотеки core-js. Колись вже про нього шуміло, коли він збив на смерть людину і сів за грати.

Як з людиною з цим чуваком все зрозуміло, судячи з його відгуків про людину яку він вбив, з тексту судового рішення та його позиції щодо війни.

Мені також було цікаво прочитати його ниття на рахунок опенсорсу, бо це показовий кейс. Хлопець пілить ту бібліотеку десь 10 років, видно що вклався в неї морально і фізично, жаліється що отримує хейт в коменти по різним фічам, і більш за все поносить увесь світ за те що йому нічого не платять за його роботу.

Як на мене, то його проблема полягає саме в романтизації опен сорсу. Дійсно прикольно щось робити відкрито і бути частиною чогось більшого. Але також вкрай наївно чекати, що тобі будуть платити за продукт, який ти не продаєш.

Опенсорс хєрово монетизується, якщо єдиний твій товар — це сам опенсорс. Тобто, навіщо комусь платити за те, що він і так робить?

Зрозуміло, що я і ви як людина, як окрема одиниця проецює його трагедію на себе і думає що ну дійсно несправедливо. І можливо насправді він зміг би заробляти з індивідуальних донатів, але для цього треба продавати продукт, і не бути мудаком.

Нормальні гроші можна підняти з компаній. А от бізнесу вже до сраки трагедія індивіда, бо там основний ресурс — гроші, а не емпатія до людини.

З іншого боку, скоріш за все, ця бібліотека і не злетіла б, якби він з першого дня поставив її за пейвол. Тому можливо можна було б піти шляхом розвитку ком'юніті, набирати аудиторію та монетизуватися донатами. Але знов ж таки: для цього треба робити більше, ніж мейнтейнити продукт (і не бути мудаком).

Коротче, мій посил у тому, що у будь-якій моделі потенційного заробітку треба робити більше, ніж мати тільки сам продукт власної праці. Бо тих продуктів на розкладці дохєра, але з усих що мене влаштовують я оберу той, який мені краще продадуть.

Насправді судячи з його історії проблема саме в тому, що в житті сталася пизда і треба багато грошей, і от його безоплатна відданість опенсорсу гарно лягла на реальність і вийшло розчарування.

Я не додаю посилання, бо цю історію і додаткові матеріали легко нагуглити.

​​Поки в нас на роботі йде AI хакатон, а я трохи прихворів, то вирішив погратися з Stable Diffusion, бо до цього пробував тільки Midjourney.

Зробив собі локальний сетап через webui. На вінді прям топ, воно само все сетапить практично в один клік. Потім накачав собі моделей і сидів день роздупляв як правильно писати запроси, поняв що означає бути «prompt engineer».

Вцілому прикольно, особливо з controlnet щоб «направляти» генерацію зображення. Але якогось цікавого профіту окрім «прикольно потикати» я поки що не побачив.

Є от відео редактор Runaway, але я думаю там під капотом все набагато простіше і передбачуваніше.

Прикріпляю пару фото та відео експериментів з controlnet (більше в коментарях під постом)

Розкажу ще трохи про експерименти з ШІ на роботі.

Нещодавно OpenAI зробили публічною апішку до моделі gpt-3.5-turbo, це та що інтегрована у ChatGPT. Вона дешевша і типу більш продвинутіша.

Я погрався з нею, підключив у Pitch і замінив наше quick menu з командами на один інпут, який приймає будь-який текст, додає до нього додаткові інструкції та структури даних і відправляє це все до OpenAI (демо відео отут).

Працює офігенно, особливо вражає, коли просиш шось зробити, але не прямими командами типу «зроби мені презентацію з шаблону для мітингу», а більш абстрактно «у мене скоро мітинг з босом, треба розказати про продажі цього місяця». Воно це все інтерпретує маючи вхідні дані і видає мені список шаблонів які підходять під запит користувача, з яких вже можна створити презентацію.

Незначна проблема моделі gpt-3.5-turbo полягає у тому, що ШІ заточений під розмову у стилі чату, тому його треба вчити відповідати чітко, без додаткових фраз типу «так, звичайно, я знаю що це…»

Але найбільша проблема — це stateless сервер, сам ШІ не запам’ятовує контекст розмови, тому йому треба кожного разу відправляти усю інфу. З огляду на те що ця модель дуже дешева у використанні, воно все одно буде дорого у такому сетапі. Ну і звичайно що гігабайти даних йому відправляти ніхто не буде.

Тому я відкрив для себе світ векторних баз даних. Через апі OpenAI текст перетворюється у вектор чисел (embedding) які зберігаються у базі (наприклад Pinecone чи Postgres), наприклад уся ваша робоча документація. Тоді при пошуку ваш запит також перетворюється у вектор, по ньому знаходяться релевантні частини документації у базі і вже тоді питання разом з контекстом відправляються до OpenAI і gpt-3.5-turbo видає вам гарно оформлену відповідь базуючись на запитанні та тексту документації.

Особливо крутий результат виходить на векторизованих зображеннях. Коротко: з’являється можливість текстом шукати зображення по вмісту самих зображень. Шось типу «дай мені картинку з котом який їсть рибу», або навіть можна дати йому фото картини і поставити якесь філософське питання. Перше враження наче це якась магія. Також можна векторизувати та шукати по аудіо контенту. Ну і якщо є зображення, то можна робити базу для відео (по кадрам).

Назбиралось трохи цікавих ресурсів та тулів по ШІ, ділюсь з вами списочком.

В мережу злили фейсбучну модель llama, хакери оптимізували її під процесори Apple і тепер їх можна ганяти локально. Найменша модель 7B на моєму M1 Pro 16GB видає 5 токенів у секунду, правда вона тупенька. 30B з’їдає до 30гб оперативки і видає один токен за 2хв. Хтось вже підняв найменшу модель на Raspberry PI та Pixel 6. Коротше ШІ зараз летить швидше ніж у фронтенді виходять нові фреймворки, скоро воно буде в холодильниках, цікаво спостерігати за розвитком https://github.com/ggerganov/llama.cpp

LangChain — абстракція поверх LLM та векторних баз даних, по суті дає загальний інтерфейс для композиції моделей, баз та зовнішніх сервісів як кубиків лего https://langchain.readthedocs.io/en/latest/

Я думаю що оцей пошуковий ШІ для девелоперів https://www.phind.com/ побудований якраз на LangChain, бо він комбінує у собі щось типу ChatGPT та Google і інші сайти як джерела даних. Я десь вже тиждень користуюсь Phind і поки цілком задоволений, результат точно кращий ніж гугл.

З’явилась open source альтернатива ghatgpt https://twitter.com/itakgol/status/1634590622286741504

Стаття про швидкий розвиток LLM https://simonwillison.net/2023/Mar/11/llama/, буквально кожного дня з’являється щось нове

По StableDiffusion теж є новини, більше про стабілізацію картинки при генерації кадрів для відео https://xanthius.itch.io/multi-frame-rendering-for-stablediffusion

Ну шо, вже поганяли gpt4? Я посидів трохи з ним вчора і сьогодні. Можу сказати, що з першого погляду модель дійсно «розумніша» за gpt3.

Сьогодні відтестували на генерації фільтрів для ffmpeg, бо в них там свій dsl для опису фільтрів і gpt3 зазвичай фейлив правильно описати трансформацію.

Ще воно добре розуміє контекст, сирі данні і може видавати цікаву аналітику та поради.

Наприклад я залив у нього вектор транзакцій які записуються під час роботи над презентацією в Pitch і попросив описати що робив користувач, хто ця людина і як ШІ може домогти йому зі створенням презентації.

gpt правильно описав що користувач створив текст, перетягнув його, додав зображення і збільшив його. Сказав що людина може бути дизайнером і порекомендував додати автокомпліт, автолейаут та контекстний пошук зображень.

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

Ще з ним цікаво і водночас дивно писати код, бо виходить так, що я як людина стаю компом, який отримує код від ШІ який вдає з себе людину, інтерпретую його у себе на компі і віддаю ШІ помилки щоб він їх пофіксив.

Так я за годину написав веб апку на реакті і ноді яка з зображень та тексту генерує відео для сторіс в інсту. 99% коду написано ШІ. Думаю це топ для чорнового коду під прототип.

Ще кльовий юзкейс — це питати у gpt як можна вдосконалити продукт. Наприклад я спитав у нього як ШІ може допомогати створювати презентації. Воно розписало концепцію та юзерфлоу. Потім я попросив у нього прикинутись системою яку він тільки що описав і тоді я по факту протестував концепт розроблений ШІ.

Це я до чого, за цей рік багато продуктів будуть мати якийсь пошук по даним чи QA систему на базі ШІ, бо це перше що спадає на думку і зараз легко зробити. Але більш цікаві та успішні будуть продукти які зможуть інтегрувати ШІ у процес роботи, наприклад створення контенту. Це не так очевидно і потребує часу та досліджень.

Доброго вечора. Я відкрив збір на тачку дядькові на фронт, бо вони там зараз їздять на вбитому Т3. Треба 300,000, тому буду вдячний за вашу допомогу 🫙👉 https://send.monobank.ua/jar/56tpYRGJyS

Також приймаю ваші поради щодо прискорення збору. Можу дати якісь консультації за донат чи зробити стрім.

Сьогодні натрапив на пейпер від Microsoft Research, вони ще з минулого року пл всякому ганяли GPT4 щоб зрозуміти на шо воно здатне, і усі результати записали там. Ось короткий відос про найцікавіше https://youtu.be/Mqg3aTGNxZ0

Ви можливо вже бачили що OpenAI додав «магазин» плагінів для GPT4. Пацани вирішили рубить бабло і забили на відкритість платформи. Але то таке.

По суті оті плагіни це інтеграція gpt у навколишній світ: пошук у гуглі, купівля квитків на поїзд чи літак, редагування відео, і тд. Треба лише надати йому API по якому він навчиться комунікувати з сервісом. Це те що робить опенсорсний LangChain (абстракція для компонування LLM та зовнішніх сервісів), але перевага OpenAI саме у тому, що мозком тут виступає модель GPT4, яка краще за інші (поки що) вміє все це робити.

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

Можливо інтеграція працює за підходом ReAct — це коли ви просите модель не просто відповісти на питання, але також описати процес мислення у форматі команд, які сама модель потім і виконує, типу: «щоб відповісти на це питання, мені треба дізнатись про оце, значить із всіх тулів які в мене є я скористаюсь гуглом». Таким чином модель може сама собі створити ланцюг дій, що призведе до бажаного результату.

Далі ще цікавіше, підпишіться на оцього науковця бо він пише кльові штуки https://twitter.com/geoffreylitt/status/1639044690166030337

Він описує прикольну ідею, про те що сьогодні ChatGPT це такий дженерік інтерфейс у модель, типу як текстовий термінал у мейнфрейм. І наводить приклад як з часом людство пересіло з текстового управління сервісами на компі до графічного UI, де під кожну задачу люди собі створювали що називається domain-specific інтерфейс.

І от уявіть собі якщо б GPT навчився робити ці графічні інтерфейси під кожен з інструментів, якими він вміє користуватись. З огляду на те, що модель вже вміє писати +- непоганий код, я думаю це реально в короткостроковій перспективі 🤯