Я работаю с движком jme3 используя только code-only подход. Имеющимся SDK не пользовался. Так как исходный код самого движка открыт, если Вас что-то не устраивает, теоретически можно это переделать под себя)
Либо посмотреть на другие OSS проекты, как там реализовано, может даже [пере]использовать. Написано уже множество всяких редакторов и библиотек. Около года назад, даже FSR1 пытались реализовать, правда в движок это пока не попало.
После пары глобальных очень долгих рефакторингов (которые по классике бизнес-ценности не имели, но без них было не обойтись) я теперь сразу стараюсь делать компоненты игры расширяемыми, чтобы в дальнейшем можно было легко наращивать функциональность.
Я пока никак не решал, ибо у меня пока нет зданий со входом с улицы. Вообще зданий пока нет. Но, кажется это можно решить именно с использованием BoundingBox - проверяются координаты частиц и попавшие в него убираются. Этот метод кажется самым точным но и самым тяжелым.
Внутри здания совершенно точно можно управлять этим через бакет (очередности) отрисовки RenderQueue.Bucket.Transparent. Снаружи использовать такой подход не выйдет, так как будет нарушена очередность отрисовки травы, неба и удалённых гор.
Ещё можно проверять положение ноды игрока - если он внутри дома отключать отображение полусферы с частицами через particleGeom.setCullHint(Spatial.CullHint.Always);
Но это должно визуально полностью отключить дождь. То есть в дверной проём будет видно что снаружи дождя нет.
В библиотеках движка есть ParticleEmitter. Я использую его для реализации осадков. Но дело в том, что у него есть "форма" - в пределах которой эти частицы и испускаются и видны.
Постепенно количество объектов в кадре увеличивается и требования начинают подрастать. Также это зависит от размеров текстур и используемых моделей (low poly/high poly).
Требуется система имеющая от 4Gb RAM (бывают скачки выделения в пике до 6Gb) и от 2Gb до 4Gb Video RAM.
Траву можно через шейдер рисовать, это правда, но шейдер пишется не на Java а уже на другом языке - GLSL OpenGL Shading Language, он кажется довольно сложным, надо отдельно изучать. И в шейдере для травы придется учитывать неровности ландшафта, место посадки (не сажать на скалах и под водой) и тогда уж надо бы сделать эффект ветра - колышащуюся траву. С шейдерами я планирую как-нибудь попозже поразбираться.
С одной стороны - make sense, приобрести опыт и попробовать идеи.
С другой стороны - а зачем? Если целевым вариантом является 3D с процедурным миром и попытка воссоздать Gothic/Oblivion. В процессе всё равно приходится делать standalone мини-приложения для проверки гипотез. То есть создание 2D игры в данном случае кажется потерей времени на не-релевантные задачи.
Привет!
Я работаю с движком jme3 используя только code-only подход. Имеющимся SDK не пользовался. Так как исходный код самого движка открыт, если Вас что-то не устраивает, теоретически можно это переделать под себя)
Либо посмотреть на другие OSS проекты, как там реализовано, может даже [пере]использовать. Написано уже множество всяких редакторов и библиотек. Около года назад, даже FSR1 пытались реализовать, правда в движок это пока не попало.
После пары глобальных очень долгих рефакторингов (которые по классике бизнес-ценности не имели, но без них было не обойтись) я теперь сразу стараюсь делать компоненты игры расширяемыми, чтобы в дальнейшем можно было легко наращивать функциональность.
Спасибо, исправлено.
Благодарю за совет! Действительно, есть такой момент.
HDR фильтра для пост-процессинга всей сцены в движке jme3 нет.
При включении auto gamma-correction и настройке tone mapping кажется сразу стало лучше:
Привет!
Это более низкоуровневые библиотеки для рендеринга видео и аудио
Движок jme3 использует lwjgl для рендеринга через OpenGL
Другой вариант - jogl
Я пока никак не решал, ибо у меня пока нет зданий со входом с улицы. Вообще зданий пока нет. Но, кажется это можно решить именно с использованием BoundingBox - проверяются координаты частиц и попавшие в него убираются. Этот метод кажется самым точным но и самым тяжелым.
Внутри здания совершенно точно можно управлять этим через бакет (очередности) отрисовки
RenderQueue.Bucket.Transparent. Снаружи использовать такой подход не выйдет, так как будет нарушена очередность отрисовки травы, неба и удалённых гор.Ещё можно проверять положение ноды игрока - если он внутри дома отключать отображение полусферы с частицами через
particleGeom.setCullHint(Spatial.CullHint.Always);Но это должно визуально полностью отключить дождь. То есть в дверной проём будет видно что снаружи дождя нет.
В библиотеках движка есть ParticleEmitter. Я использую его для реализации осадков. Но дело в том, что у него есть "форма" - в пределах которой эти частицы и испускаются и видны.
Постепенно количество объектов в кадре увеличивается и требования начинают подрастать. Также это зависит от размеров текстур и используемых моделей (low poly/high poly).
Требуется система имеющая от 4Gb RAM (бывают скачки выделения в пике до 6Gb) и от 2Gb до 4Gb Video RAM.
Траву можно через шейдер рисовать, это правда, но шейдер пишется не на Java а уже на другом языке - GLSL OpenGL Shading Language, он кажется довольно сложным, надо отдельно изучать. И в шейдере для травы придется учитывать неровности ландшафта, место посадки (не сажать на скалах и под водой) и тогда уж надо бы сделать эффект ветра - колышащуюся траву. С шейдерами я планирую как-нибудь попозже поразбираться.
С одной стороны - make sense, приобрести опыт и попробовать идеи.
С другой стороны - а зачем? Если целевым вариантом является 3D с процедурным миром и попытка воссоздать Gothic/Oblivion. В процессе всё равно приходится делать standalone мини-приложения для проверки гипотез. То есть создание 2D игры в данном случае кажется потерей времени на не-релевантные задачи.
Удобнее всего пользоваться плагинами к IDE, например к Idea, плагины сразу по завершении ввода перерисовывают картинку.
Ещё можно рендерить PlantUML используя сервер в локальном докер-контейнере.
И, наконец, есть плагины для Confluence которые позволяют хранить и рендерить код прямо там, на странице.