Введение
Честно говоря, я долго не мог решиться написать и опубликовать эту статью. Зачем, думал я, возиться с не самой популярной технологией и изобретать велосипед — реализовывать функции, которые уже где‑то есть? На этот вопрос у меня нет универсального ответа — каждому своё.
Сначала мне казалось, что рассказывать о таких «подвигах» не слишком интересно. Все любят истории об успешном успехе. Потом я вспомнил: главное — не итог, а путь, опыт и знания, которые ты получаешь по дороге. Как только я начал смотреть на материал как на обучающий, делиться им стало намного проще.
Бывает так: с какой то технологией уже разобрался, а вот перейти к новой боязно. Учить новые движки непросто, да и текущий инструмент уже не справляется с задумкой… Сомнения часто мешают двигаться вперёд, но народная мудрость «глаза боятся, а руки делают» никогда не подводит.
В итоге я решился и попробовал FXGL для 3D‑рендеринга. Но не для того, чтобы сделать полноценную игру(хотя она и получилась), а чтобы соединить расчёты по системному моделированию с элементами геймификации. Уточню: я не призываю использовать FXGL во всех случаях. Для серьёзных 3D‑проектов есть отличные инструменты — Unigine, jMonkeyEngine, Godot, Unreal Engine. Я попытался собрать и упорядочить знания, которые получил в ходе своего небольшого эксперимента.
С чем имеем дело или из чего собрать Франкенштейна
У JavaFx в 3D есть некоторые плюсы и минусы, в этом разделе попытаюсь их про них рассказать.
Управление камерой
JavaFX 3D не просто даёт какую‑то камеру она под вашим полным контролем. Что можно делать:
настраивать поле зрения (FOV — Field of View), как в шутерах: хотите широкий обзор — увеличиваете, хотите «зумировать» — уменьшаете;
Можно управлять параметром налету, используя биндинги
camera3D.getPerspectiveCamera().fieldOfViewProperty().bind(cam_val);
регулировать ближнюю и дальнюю плоскости отсечения (near/far clipping planes) — это как фокус в фотоаппарате: отсекаем лишнее, чтобы не нагружать рендер ненужными объектами;
двигать и вращать камеру в 3D‑пространстве с помощью простых трансформаций (Translate, Rotate) — всё как в настоящем движке;
Вот, например, как привязать камеру к автомобилю
var distanceToCamera = -8; var pos = entity.getPosition3D().subtract(entity.getTransformComponent().getDirection3D().multiply(distanceToCamera)); transform.setPosition3D(pos); transform.lookAt(entity.getPosition3D()); transform.setY(entity.getY() + CAMERA_HEIGHT_OFFSET);
И если захочется добавить кинематографичности, то можно добавить «сглаживания» :
double smoothXY = 0.2; double smoothZ = 0.2; var distanceToCamera = -8; var targetPos = entity.getPosition3D().subtract( entity.getTransformComponent().getDirection3D().multiply(distanceToCamera) ); // Интерполяция по осям с разными коэффициентами double newX = cameraPos.getX() + (targetPos.getX() - cameraPos.getX()) * smoothXY; double newY = cameraPos.getY() + (targetPos.getY() - cameraPos.getY()) * smoothXY; double newZ = cameraPos.getZ() + (targetPos.getZ() - cameraPos.getZ()) * smoothZ; cameraPos = new Point3D(newX, newY, newZ); transform.setPosition3D(cameraPos); transform.lookAt(entity.getPosition3D()); transform.setY(cameraPos.getY() + CAMERA_HEIGHT_OFFSET);
Или делать интерактивное управление: например, реализовать вид от первого лица или камеру, которая красиво вращается вокруг объекта. Типа такого.
Применение материалов типа PhongMaterial с поддержкой diffuseMap и normalMap
PhongMaterial — это билет в мир визуально приятных поверхностей. Разберём, что тут есть:
diffuseMap (диффузная карта) — задаёт основной цвет и текстуру. Проще говоря, это «обёртка» объекта: хотите дерево — клеите текстуру дерева, хотите камень — камень;
normalMap (карта нормалей) — магия, которая создаёт иллюзию мелких деталей без увеличения полигонов. Поверхность кажется рельефной, хотя на деле остаётся гладкой — экономия ресурсов налицо. И тут немного про вайб-кодинг. Решил попробовать сгенерировать скрипт с помощью Алисы для созданий кары нормалей для всех изначальных текстур, и результат вышел вполне рабочим. Да, правильнее, наверное, поработать с каждой текстурой в профессиональном редакторе, но это уже совсем другой пилотаж.
ещё есть specularMap — с ним можно контролировать, где и насколько сильно будут бликовать участки модели. Хотите, чтобы часть объекта блестела, как металл, а часть оставалась матовой? Легко;
коэффициент блеска (specularPower) — настраиваете, и вот уже ваша модель может быть как матовым пластиком, так и зеркальным хромированным шаром.
Импорт 3D‑моделей в форматах .obj, .3ds и других
Какие форматы поддерживаются и что потом с ними делать:
загружать готовые модели в популярных форматах — .obj (Wavefront), .3ds (3D Studio), а с дополнительными библиотеками и другие форматы подтянуть можно;
сохранять иерархию объектов и трансформации, которые вы задали в редакторе 3D‑моделирования — всё перенесётся как надо;
автоматически создавать JavaFX‑узлы (MeshView, Group) для импортированной модели. То есть вы загрузили объект — а он уже готов к использованию в сцене, без лишних телодвижений.
Интеграция пользовательских GLSL‑шейдеров через низкоуровневые API
Для тех, кому стандартных возможностей мало, есть доступ к «внутренностям» рендеринга:
пишите свои вершинные (vertex) и фрагментные (fragment) шейдеры на GLSL — и вуаля, у вас полный контроль над тем, как выглядит каждый пиксель;
можете заменить стандартное освещение Фонга на что‑то своё — например, сделать неоновое свечение, стилизованную графику в духе комиксов или эффект «под водой»;
работайте с текстурами и атрибутами вершин внутри шейдеров — создавайте процедурные эффекты прямо на лету;
подключаете через ShaderProgram и PhongMaterial — и стандартный пайплайн уже ваш, можно его подменять и творить что душе угодно.
Ключевые ограничения JavaFX 3D
Отсутствие реализации алгоритмов теневого отображения (shadow mapping)
Тут всё просто: теней нет. Совсем. Ни динамических, ни статических — оно и понятно, ведь это не игровой движок. Что это значит на практике:
объекты не отбрасывают тени друг на друга и на пол — выглядит это, мягко говоря, плоско и неестественно;
хотите простую тень под персонажем — придётся вручную рисовать полигон и приделывать её к модели. Да, вот так топорно;
динамические тени, которые так любят все современные игры, тут недоступны без танцев с бубном и низкоуровневых OpenGL‑вызовов. А это уже убивает весь кайф от использования высокоуровневого фреймворка.
Ограниченная и не интуитивная модель работы с источниками света
Освещение тут — это отдельная песня(смотри видео). Что не так:
выбор источников света скудный: точечный (PointLight), направленный (DirectionalLight), рассеянный (AmbientLight) — и всё. Прожектор (Spotlight)? Забудьте. Хотите подсветить сцену как в театре? Придётся изобретать велосипед;
настройки света какие‑то «деревянные»: интенсивность, радиус затухания, цвет — всё работает не так гибко, как хотелось бы;
освещение считается для вершин (per‑vertex lighting), а не для фрагментов (per‑fragment lighting). На низкополигональных моделях это даёт заметные артефакты и выглядит не очень реалистично по сравнению с современными движками.
Отсутствие встроенного физического движка
Физика? Какая физика? Её тут просто нет. Да и откуда ей взяться, только рендеринг только хардкор. Что это влечёт за собой:
никакой автоматической проверки столкновений (collision detection) — объекты будут проходить друг сквозь друга, как привидения;
гравитация, инерция, трение, отскоки — всё это нужно писать с нуля или искать сторонние библиотеки. Хотите, чтобы мяч отскакивал от пола? Придётся потрудиться;
Отсутствие WYSIWYG‑редактора сцен
Здесь всё по‑старинке: никакой визуальной магии, только код. Что это значит:
вся сцена — иерархия узлов (Group, SubScene, MeshView, Light, Camera) — создаётся и настраивается исключительно кодом на Java. Никаких drag‑and‑drop, никаких визуальных редакторов;
хотите поставить куб в угол комнаты? Пишите код. Повернуть лампу? Снова код. Настроить освещение? Вы уже поняли;
Однако, чтобы работалось слегка комфортнее, я добавил окна настройки для источников света и дерево объектов на сцене. Мелочи, но все же приятные. И да, на вайб кодить такие окна настроек тоже можно. Главное, потом проверить за ИИ помощником)
Собираем нашего монстра
Одна из основных идей этого хобби и обучающего проекта, создавать графические кроссплатформенные приложения на Java, где «под капотом» работают математические модели из платформы системного моделирования. К этой идее подтолкнули пользователи, которые хотели бы обмениваться моделями в виде закрытых приложений с графическим интерфейсом, при этом без браузерного интерфейса.
В платформе, итак, есть задокументированное API, а можно избавиться от накладных расходов подключив библиотеку к приложению.
Собственно, для этого нужно подключить в ваш проект библиотеку RepeatCore любым удобным способом, и в классе контроллера, предварительно скачав свой проект модели с сайта приложения.
RepeatCore.parseClassMap(); //Настраиваем библиотеку для работы в фоновом режиме RepeatCore.runtimeAsService = true; RepeatCore.isSingle = true; RepeatCoreService.runtimeAsService = true; RepeatCoreServiceDocument.verboseLevel = 0; RepeatCoreServiceDocument.startWithoutBinFile = true; var repeatCoreService=new RepeatCoreService(); var tempdoc = new RepeatCoreServiceDocument(); serviceDocument = tempdoc.openDocument(filename); // файл вашего проекта serviceDocument.setParentRepeatCoreService(repeatCoreService); serviceDocument.documentCalculate();
Далее, проинициализировать объекты для управления(входные параметры для модели).
speed_setpoint=(Constant) getObjbyIdFromList(serviceDocument.componentList,"1739110251130"); // это уникальный ID объекта, отображается на схеме
И затем, обновлять данные на графиках, диаграммах и других контролах любым способом, используя биндинги или отдельный поток.
Собственно, вот такое простенькое приложение можно получить, для управления электроприводом
Этот же подход можно использовать и при соединении 3D рендеринга и расчетов, эдакий Франкенштейн получается. Главное не забыть синхронизировать обновление кадра с расчетом.
Франкенштейн оживает
Признаюсь: я просто не смог устоять. Наткнулся на классную статью про перенос карт из старых NFS — и загорелся идеей сделать что‑то похожее. А поскольку NFS 5 для меня — это не просто игра, а настоящая любовь с первого заезда, выбор карты был очевиден.
Взял ассеты из NFS 5 и решил перенести их в FXGL. Звучит просто, да? На деле же это обернулось миллиардами (ну, может, десятками) итераций:
разбирался, как вообще эти модели устроены;
мучился с масштабом — то машина размером с дом, то дорога в три метра шириной. Об этом автор статьи про перенос в UE тоже столкнулся;
настраивал освещение так, чтобы карта не напоминала тёмный подвал(Хотя может и получилось своеобразно).
Итак, по порядку.
Чтобы загрузить карту подгружаем библиотеку jimObjModelImporterJFX и загружаем модель, предварительно создав для нее Entity в фабричном классе.
@Spawns("city") public Entity newCity(SpawnData data) { Group modelRoot = new Group(); var importer = new ObjModelImporter(); importer.read("nfs5_industrial_grouped.obj"); // Загружаем модель в формате .obj, можно в .fbx,.3ds for (MeshView view : importer.getImport()) { modelRoot.getChildren().addAll(view); // здесь можно поиграться с материалами мешей, загрузить карты нормалей и т.д. } importer.clear(); // убираем за собой importer.close(); // Спауним Entity карты var e = entityBuilder(data) .view(modelRoot) .build(); return e; }
Собственно, аналогично спауним и модель автомобиля, задав ей класс-компонент (он отвечает за анимации, физику и т.д.)
@Spawns("obj") public Entity newObj(SpawnData data) { Group modelRoot = new Group(); var importer = new ObjModelImporter(); importer.read("911_92.obj"); var e = entityBuilder(data) .view(modelRoot) .with(new CarComponent()) .build(); e.setScaleUniform(1); return e; }
Добавляем HUD. В main-классе игры добавляем свои элементы в метод initUI(). Я использовал пару собственных классов для графиков и gauge. Выглядит это примерно так
@Override protected void initUI() { super.initUI(); CarComponent carComponent = car.getComponent(CarComponent.class); carSettingsWindow = new CarSettingsWindow(carComponent); torque_chart = new LineChart(new NumberAxis(), new NumberAxis()); CustomLineChart.setup(torque_chart,"Скорость, км/ч"); speedOmeter = new GaugeComponent("км/ч","Скорость",0,300,350,350); RPMmeter = new GaugeComponent("об/мин","",0,9000,350,350); gearratio = new GaugeComponent("","Передача",0,6,250,250); torque_gauge = new GaugeComponent("Н*м","Момент",0,1500,250,250); rpm_chart = new LineChart(new NumberAxis(), new NumberAxis()); xy_chart = new LineChart(new NumberAxis(), new NumberAxis()); gear_chart = new LineChart(new NumberAxis(), new NumberAxis()); CustomLineChart.setup(xy_chart,"Траектория"); CustomLineChart.setup(gear_chart,"Передача"); CustomLineChart.setupMultipleSeries(rpm_chart,"Об/мин"); CustomLineChart.setupMultipleSeries(rpm_chart,"Момент, Н*м"); // Создаем корневую панель BorderPane для разделения на зоны BorderPane root = new BorderPane(); root.setPrefHeight(FXGL.getAppHeight()); root.setPrefWidth(FXGL.getAppWidth()); // Верхняя часть (графики) HBox topPane = new HBox(); topPane.setSpacing(10); topPane.setPadding(new Insets(5, 5, 5, 5)); topPane.getChildren().addAll(rpm_chart, torque_chart, gear_chart, xy_chart); root.setTop(topPane); var hboxLeft = new HBox(); hboxLeft.getChildren().addAll(torque_gauge.gauge,speedOmeter.gauge); hboxLeft.setSpacing(10); hboxLeft.setPadding(new Insets(5, 5, 5, 5)); var hboxrRight = new HBox(); hboxrRight.getChildren().addAll(RPMmeter.gauge,gearratio.gauge); hboxrRight.setSpacing(10); hboxrRight.setPadding(new Insets(5, 5, 5, 5)); root.setLeft(hboxLeft); root.setRight(hboxrRight); getGameScene().addUINode(root);
Про пост эффекты, блюры и всякие блумы. Их можно применить к 2D узлу, но к 3D никакого эффекта не будет. А что если попробовать?
В общем, если наложить эффект на субсцену, то эффект может быть интересным. Ниже пример с легким motion blue эффектом.
Про нейронки, апскейлинг текстур, добавление карт нормалей – и картинка станет лучше. Что-то я попробовал – но возиться в Blendere и других инструментах – увольте, мне это не очень интересно)
А как же не упомянуть производительность и железо — вот на таком ноутбуке с AMD Ryzen 5 7430U with Radeon Graphics (2.30 GHz) и 16 ГБ памяти
я провожу эксперименты над своим Франкенштейном и 60 FPS стабильно выдерживаются.
Скрин с графиком и выкладками из встроенного профилировщика.
Скрытый текст
Для дополнительного профилирования вот строчка с опциями для JVM -Dprism.verbose="true" -Dprism.vsync="false" -Djavafx.animation.fullspeed="true"
Заключение
Вот мы и добрались до заключения. Наблюдать за крупными и крутыми результатами команд с огромными бюджетами — это всегда восторг. Однако, мы забываем какого это реального труда стоит каждому из членов команды, поэтому, когда сам в одиночку пробуешь что-то сделать, да, ожидания размазывают тебе о твердыню реальности. Столько раз руки опускались, видя результаты своего творения, забывая о том, сколько было пройдено и реализовано.
Что я понял на практике:
визуализация расчётов — это быстро и доступно даже без продвинутых инструментов;
HUD‑интерфейс собирается из готовых библиотек буквально за полчаса, главное определить дизайн и концепцию;
Начав с «неподходящего» на первый взгляд инструмента (JavaFX в 3D), можно создать рабочий прототип фреймворка для аркадных гоночных симуляторов — с физикой, рендерингом и интерфейсом в одном флаконе.
А теперь — главный посыл: не бойтесь экспериментировать и не опускайте руки! В моделировании и компьютерной симуляции именно нестандартные подходы часто дают лучшие результаты. Возьмите привычный инструмент, попробуйте применить его в неожиданном контексте, соедините с вашими расчётами — и вы можете получить что‑то уникальное.
Дерзайте: каждый эксперимент приближает вас к собственному решению, которое однажды может перерасти в полноценный фреймворк или продукт. Даже если сначала кажется, что вы просто «изобретаете велосипед» — возможно, именно этот велосипед станет основой для чего‑то большего.
