#jme3

[adi-barda]

Unity 3D Short Review

* this text is 100% human. No AI is involved in generating it In the last year I've been using Unity for my studies in game development. I was able to create and publish 3 small games in quite a short time. I was totally new to Unity, never used it before but I knew that it is one of the most popular game engine on the market.

Night Dancer - A game I've created in Unity in about 3 weeks in my spare time. The game includes video rendering, procedural generation and constant shape changes of the dancing stage in run-time, user input with hand gestures using open source machine learning model for the gesture recognition, AWS dynamo DB integration for presenting a Leader Board and the usual stuff - UI, particle system, Humanoid animation, events, triggers etc. Actually I never programed a game before in any other game engine except for my own SceneMax3D engine which is based on JME3 engine and a custom made programming language. So this is my short review for what I liked and what I didn't like about Unity3D. I consider myself as a Unity beginner level programmer so in that perspective you should read this text.

The good things I'm not going to write about each and every good feature in Unity (there's a lot of them) rather I would like to focus some good general components and concepts. For the most part, I think it is a fantastic game engine, very comprehensive with an amazing assets store and eco system. If I will ever aim for developing a serious full scale game, Unity probably will be my choice for game engine to be used.

Performance - this engine has great performance. I used a lot of scene objects, expensive particle systems, video rendering, just-in-time hundreds of objects (prefabs) loading and creation, music and sound effects and the engine handled them exceptionally good performance wise. Most of the time I don't even think about the performance cost of my game objects - that good is the engine's optimizations. Of course from time to time I do hit the performance limits and the FPS is dropping, then I apply some coding best practices and usually the problem is solved.

Slider Glider - a fast arcade game where you need to slide and jump on monstrous sliders while navigating your way in a procedurally generated maze. It took me about 3 weeks to develop this game in my spare time. The sliders models are placed in run-time and the maze is randomly generated in the beginning of each stage. There is also a simple navigation system assisting you to cope with the complex maze navigation reaching the treasure. The big challenge here was using curves for the sliding movement. Unity curves editor was very helpful in this case. Ease of use - Unity IDE is superb. The technique of dragging a prefab (pre defined composite of objects) onto a public field of some other game object and having it ready to be used at run time is very easy and intuitive to use. The usage of Mono Behaviors for injecting specific logic, the animation state machine, events and triggers are all contributing to the ease of using this engine. Rendering - Unity uses the best graphics APIs available for each targeted platform such as Vulkan and DirectX12. This affects the quality, portability and performance of your project.

Assets store - This one is by far my favorite feature of Unity. Absolutely amazing assets store with every library/graphic asset you can think of for your game and with superb reliable integration to your project for installing / uninstalling it. Some of the assets costs money and some of them are free. I was able to get anything I needed for free but for serious projects I will not hesitate to spend some money for getting state of the art libraries / assets. Build system - Unity supports building your projects for all major platforms including mobile, game consoles, PCs and web. This portability in my opinion is a big advantage Coding - For those of us (myself included) who prefers to build the scene graph using coding as much as possible in run time, Unity allows that freedom leaving you only the need to setup your game's resources (pre-fabs).

Dark Chaos - my first ever Unity game. Made in 3 weeks with absolutely no prior knowledge. Tons of particle systems, no best practices used, 3D models from Mixamo, Sketchfab and some I assembled by myself using Asset Forge. I think that demonstrates the ease of creating your first game with Unity Generative AI - Unity is probably the most popular game engine in the market using one the most popular general purpose programming language available (C#) so it makes it really easy for Vibe programing - letting an LLM to create some of your coding and code reviews for you. Harnessing Gen AI for writing some of your game's code is truly a revolution in game creation. Really hard tasks which might take days or even weeks for research and implementation is reduced to minutes. Let me give you an example - in my Night Dancer game I wanted a 10 by 10 dancing floor which changes its shape in real-time from "O" shape to "X" to "Love" to "Square" etc. in random sizes at random speed. That would take me quite a bit of time to code myself and it was perfectly done by the Gen AI in just a few minutes. Absolutely amazing. The bad things

As I mentioned earlier, I consider myself as a beginner programmer in Unity and also don't have much experience in any other game engines so the "bad things" that I'm going to list here might not be that bad if I had a wider perspective. External code editor - I find it really annoying that you can't code inside Unity IDE and need to switch back and forth from Unity IDE to an external code editor such as MS Visual Studio or VS Code. Each time you switch from one IDE to another, a compilation process starts followed by a synchronization process. It take a few seconds (sometimes quite a few!) and you need to wait for those processes to end before switching IDEs. Not fun especially for developers like myself who spend a lot of their time coding. UI Canvas - I find it a little bit confusing to arrange my UI components (2D) in the game's 3D world IDE freezes - It happened to me a few times that the IDE froze for some reason and sometimes the build process was stuck forever. I suspect that it is related to the anti virus installed on my Windows machine. Anyway I needed to hard stop Unity's process and restart the system risking some state loss

Summarize

I was really impressed with what Unity offers you out of the box and as an extension from its assets store and I highly recommend using this game engine for any serious game you have in mind. it is guaranteed that the engine will not be the one stopping you from completing your game. As for myself I'll probably be back working on simple games using my SceneMax3D and JME3 because this what I enjoy most - creating tools and software engineering. Cheers!

[jme3adventures-blog]

Introduction

I've been fascinated by large-scale procedural 3D worlds for many years. After taking a class on 3D graphics that brought me some deeper insights last year, I felt very motivated for digging deeper into the whole thing.

I had made many experiences with raw OpenGL programming. I think this is good because it is important to understand what is going on under the hood in order to achieve great results even when working with some sort of abstraction layers.

Framework

So I looked around for a 3D engine that I could built upon. Let me outline shortly what my criteria have been. The engine should have been free and preferably open-source, because I wanted to learn more about 3D engines and how they are designed. It should have a broad users base and community, so I wouldn't end up on my own if I get stucked at some point. And it should be modern and preferably lightweight.

I dumped Ogre and Irrlicht quite fast because both have became somewhat "dusty" and bloated over the years. Before looking closer on Unity, I stumbled over JMonkey. My decision arised kind of from a comparison of these two candidates that wasn't easy, but the aspects of being open-source and more lightweight tipped the scales in favor of the JMonkey Engine 3, JME3 briefly. Furthermore JMonkey is said to be an "engine by the book" which is very important at the sight of my desire to learn.

I consider it as a benefit that I can (must) use Java when working with JMonkey for two reasons. First, I know Java well, although I am very familiar with C++ either. Second, prototyping is just much more efficient with high level languages like Java. I consider myself somewhat inexperienced in the field of 3D applications that complex. At some point, when I have gotten a feeling for good and bad decisions in the design process of such 3D applications, I could still take the leap towards porting the whole thing to C++ and raw OpenGL.

First Results

I started maybe three or four weeks ago and here is what I got so far:

The solar systems are generated randomly at start up. For each star and planet a set of parameters (i.e. the color, the size, ...) is diced. All textures are then generated procedurally by the shaders. Also the "nebulae" are generated procedurally. They are rendered through ray marching, which is the main reason why the frame rate is somewhat meagre. Maybe I will switch to a particle system later.

Every star and every planet can be approached:

Let me state that at this point I'm very happy with JMonkey. I like most how well it is structured. I plan on sharing my experiences on JME3 and this little project in particular from time to time.

[voyager3]

I will explain soon. :)

[voyager3]

Xiaohan and I have aggreed that we want to switch to a game engine to speed up development. We've worked out that going with raw OpenGL (with LWJGL) would require us to build an entire engine from scratch which could take forever (life is short). I've looked into the C++ libraries I mentioned before, but they're a pain to set up, and the language isn't that conducive to rapid, creative development. After a two week quest, we've finally decided that jMonkeyEngine looks like it's the best fit for us. It's a real relief to get that big decision out of the way and finally get back to being creative. :)

[linuxgamenews]

jME3 and Android Java 3D Game Development

The open source community is always providing an amazing array of useful software. It also has great set of tools to work with. I'll introduce you to a combination of a couple tools that I'm using for 3d game development. First of all it wouldn't be 3d with out Blender. Blender is a free and open-source 3D computer graphics software product used for creating animated films, visual effects, interactive 3D applications or video games. Blender's features include 3D modeling, UV unwrapping, texturing, rigging and skinning, fluid and smoke simulation, particle simulation, animating, rendering, video editing and compositing. Here is a Demo reel of Blender made in 2011

Blender has so many features it is more like a studio of software it's just amazing what it can do. Being Open Source and free there is a huge community of users helping noobs! Such as Andrew Price's website www.blenderguru.com where there are many in depth tutorials on using blender, plus a file that you can open in Blender and compare yours with his. There is also place to download free models such as www.blendswap.com and with creative commons licenses they can be reused and built upon. Blender has a physics engine and tools in place to create games without know any programming, which is awesome but for programmers to simple. That's where jMonkey Platform comes in, jMonkeyEngine (jME) is a game engine made especially for modern 3D development, as it uses shader technology extensively. jMonkeyEngine is written purely in Java and uses LWJGL as its default renderer.OpenGL 2 through OpenGL 4 is fully supported. jMonkeyEngine is a community-centric open source project released under the new BSD license. It is used by several commercial game studios and educational institutions. The default jMonkeyEngine 3 download comes readily integrated with an advanced SDK that makes it more like a studio. By itself, jMonkeyEngine is a collection of libraries, making it a low-level game development tool. Coupled with an IDE like the official jMonkeyEngine 3 SDK it becomes a higher level game development environment with multiple graphical components. Here is a Demo reel of jME from early 2011

Using Blender3d you can save models with textures, animations, particles and more as a blend file then open them in the jME3 SDK and drop them into your game. On top of all that jME3 will compile to an android install package, if you point it to the android sdk. Another piece of free and open source software in jME3 is the Nifty GUI. Below is a video demonstration of some of Nifty GUI's features. More on jME3 to come soon.

Nifty 1.3 Controls Example/Demonstration from void on Vimeo.

Check out the links, get the software and have fun developing!

[lbolgatz-blog]

  Features Added:

-Fading HUD text

-Multiple instances of identical sound playing at once

-3D position-based audio

-Position-based dual (near and far) audio track support

-Background music

[alexsaintx-blog]

Grinding gears with JavaMonkeyEngine 3

For the last five or six days I've been working very diligently to build a simple 3D isometric terrain rendering engine using JavaMonkeyEngine 3 (JME3).  I was delighted when, by the end of the first night I had assembled the necessary geometries for my surface tiles and textured them.  By the end of the second night I'd forced the camera into a parallel projection mode and positioned the scene with respect to the camera so that everything was rendered at the requisite angle. From this point on, all I really need is to light the scene.  However, this disarmingly simple thing has turned into a frustrating and heart-wrenching struggle.  I have to conclude, after several days of hammering, chiseling, scraping, poring through source code, online tutorials, and relevant books on the subject, that JME3 is not going to work for my project. After several confusing false starts, I decided to simplify the lighting problem.  I ditched my complex models and implemented a Mesh that is, functionally, half of a cube.  Just the 3 quads that face the camera.  I computed the surface normals for these quads (this is very simple, because the object is a cube, and it is aligned to the X,Y, and Z axes), and then set up three directional spotlights.  One red, one green, and one blue.  The goal of my experiment was to shine each of these lights on a different face of the mesh.  For comparison, I included a com.jme3.scene.shape.Box in the same node as my mesh. One of the first things that I noticed was that the Box model had to be rotated slightly in order for its normal vectors to align properly--in other words, shining a light straight down from above (0,1,0) lit one of the back-facing quads on the cube.  That was straightforward to resolve by rotating the cube. Still, as the days marched on, no combination of effort and experimentation would result in the effect that I was attempting to produce, which was a light shining down on the tile nearly vertically, while lighting the two vertical faces of the tile at noticeably different degrees. Eventually, I realized that even if I did manage to tweak and torque the normals around and the lights to get the effect I was after, it would almost certainly break or behave counterintuitively once I began to vary the angle of the top of my tiles, which is the whole point of this work. I've decided to give up JME and work more directly with the Lightweight Java Games Library (LWJGL). I don't need physics, collision detection, particle systems from a massive game engine. I just need rendering. Triangles, textures, and light. Still, it's a big surprise, to come so frustratingly close to completion only to turn away from an otherwise excellent library.