Англійська для розробників Babylon.js

Розмови про Babylon.js рухаються між рендерингом словника — сітки, матеріали, світла — і проблемами продуктивності, специфічними для запуску 3D-двигуна в реальному часі всередині вкладки браузера, тому обидві сторони постійно переглядаються.

Ключовий словник

** Scene ** — контейнер верхнього рівня у Babylon. js, у якому містяться всі сітки, світла, камери і матеріали, які складають те, що буде відтворено на даному кадрі. “Ми створюємо нову сцену кожного разу, коли відкривається цей модальний — спочатку утилізуйте стару, інакше при кожному відкритті буде витікати пам’ ять графічного процесора.”

** Сетка ** — геометричний об’ єкт, відтворений у сцені, складається з вершин і визначає форму, яку слід намалювати, незалежно від того, як вона виглядає.

• “Встановіть екземпляр цієї сітки замість того, щоб клонувати її сотні разів — клонування ділить геометрію з графічним процесором, клонування дублює її.” *

** Матеріал ** — дані, які описують, яким чином слід затінювати поверхню сітки, зокрема текстури, колір і відповідь на освітлення, які застосовуються незалежно від форми сітки.

• “Повторне використання одного матеріалу у всіх деревах замість створення нового для кожного екземпляра — зараз ми компіляємо один і той же шейдер сотні разів.” *

** Цикл відтворення ** — функція, що виконується безперервно, перемальовує сцену кожного кадру, у якій зазвичай відбувається логіка кадрового відтворення, наприклад, оновлення анімації і фізики. “Не виконуйте дорогі обчислення всередині циклу відтворення безумовно — закріпіть його за брудним прапорцем, щоб ми не перераховували це кожен кадр незалежно від того, чи щось змінилося.”

** Disposal ** — явне звільнення ресурсів GPU (сіток, матеріалів, текстур), які Babylon. js не буде автоматично збирати, що критично для уникнення витоку пам’ яті під час довгих сеансів. “Викликати розкладання на старих сітках перед завантаженням нового рівня — ресурси WebGL не звільняються лише тому, що об’ єкт JavaScript вийшов за межі обсягу.”

Звичайні фрази

• Чи ми створюємо цю сітку, або клонуємо її таким чином, що дублює геометрію на GPU?»
• Чи є цей матеріал спільним, чи ми компіляємо майже ідентичний шейдер один раз на об’єкт?
• Чи є ця логіка воротами, чи вона працює безумовно на кожному проходженні через петлю відтворення?»
• Чи ми знищили ресурси старої сцени, чи ми витікаємо з пам’яті GPU кожен раз, коли це перезавантажується?

Приклади висловлювань

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

Обговорення підходу до відтворення: “Використовувати інстансування для цих сотень ідентичних скель — клонування сітки, яка багато разів дублює геометрію, яку графічний процесор не повинен дублювати.”

Пояснення проблеми з циклом відтворення:

• “Це перерахування фізичних величин не потребує запуску кожного кадру — закривається за брудним прапорцем, тому воно запускається лише тоді, коли щось у сцені дійсно змінюється.” *

Професійні поради

• Перевага ** сітки інстанцій ** над клонуванням, коли у сцені з’ являється багато майже ідентичних об’ єктів — це один з найкращих способів поліпшення швидкодії.
• Обережно дотримуйтесь нерозподілених ** матеріалів ** при перегляді коду — надлишкове компілювання шейдерів є поширеною, легко пропущеною витратою.
• Перевірити все, що безумовно працює всередині ** циклу відтворення ** — робота на кадр, яка не повинна бути на кадрі, є частим джерелом зниження частоти кадрів.
• Створити ** утилізацію ** як частину шляху коду будь- якого переходу сцени — витік ресурсів GPU має тенденцію з’ являтися лише після тривалих сеансів відтворення, що робить їх легкою метою для коротких проходжень QA.

Практичні вправи

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

Навигація по лінії — практичний підхід

Погляньмо правді в очі: технічне спілкування рідко буває простим. Як розробник Babylon.js, ви витрачаєте значну кількість часу на вираження своєї роботи, отримання зворотнього зв’язку і співпрацю з іншими. Освоєння нюансів професійної англійської мови в цих сценаріях не стосується використання витонченого жаргону; воно стосується передачі точної інформації чітко і ефективно - щось, що легко може бути втрачено в перекладі. Неясний коментар на кшталт «це виглядає неправильно» набагато менш корисний, ніж докладне пояснення того, що ви спостерігали, чому ви вважаєте, що це проблема, і ваше запропоноване рішення. Аналогічно, створення чітких описів PR забезпечує, що всі розуміють зміни, які ви зробили.

Розглянемо такий сценарій: Ви переглядаєте запит на звантаження від колеги, який стосується введення нової сітки з деякими складними ефектами освітлення. У початковому коментарі перегляду просто написано: « Виправити швидкодію ». Хоча це технічно вірно — ефект * є * обчислювально інтенсивним — у ньому не наведено жодних вказівок щодо розв’ язання проблеми. Більш конструктивною відповіддю буде: « Я помітив, що застосування квіткового шейдера до цієї сітки викликає значне зниження частоти кадрів, особливо з текстурами високої роздільної здатності. Чи можете ви розглянути оптимізацію розрахунків освітлення або зменшення інтенсивності розцвітання? Можливо, використовувати текстуру з меншою роздільною здатністю для початкового перегляду?» Цей підхід надає конкретні пропозиції і демонструє розуміння потенційної проблеми.

Інша поширена ситуація виникає при поясненні концепцій Babylon.js комусь, хто менш знайомий з 3D-графікою - можливо, член маркетингової команди обговорює нову функцію. Замість того, щоб занурюватися в технічні деталі про WebGL- шейдери або цикл відтворення, ви можете сказати: « По суті, ми використовуємо систему, яка імітує світло і перспективу, щоб створити ілюзію глибини в 2D- зображенні. Уявіть, що ви малюєте за допомогою світла; ми контролюємо кількість світла, яке отримує кожен об’ єкт, щоб зробити його реалістичним. » Ключовим моментом є адаптація вашої мови до рівня розуміння аудиторії, завжди віддаючи перевагу ясності перед технічною точністю, коли це необхідно.

Нарешті, пам’ятайте, що перегляд коду - це співпраця, а не критика. Слід вказати позитивні оцінки і зосередитись на * впливі * змін, а не просто на помилках. Хорошим прикладом того, як це працює на практиці, є використання babylonjs для створення простої сцени:

import { Scene } from "@babylonjs/core/scene";
import { Engine } from "@babylonjs/core/engines";
import { WebGLRenderer } from "@babylonjs/core/webglrenderer";

const engine = new Engine();
const scene = new Scene(engine);
const renderer = new WebGLRenderer(engine);
scene.registerDefaultPlugins([renderer]);

// Add a sphere to the scene
const sphere = BABYLON.MeshBuilder.CreateSphere("sphere", { diameter: 2 }, scene);

scene.createDefaultCameraPositionWithControl({maintainRotation: true});

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