Open 3D Engine 23.05 Released With Many New Features

[phoronix]

Phoronix: Open 3D Engine 23.05 Released With Many New Features

It's been just under two years since Amazon's Lumberyard game engine was spun into the Open 3D Engine and the Open 3D Foundation established under the Linux Foundation. Today the project is celebrating its newest open-source game engine update with Open 3D Engine 23.05...

https://www.phoronix.com/news/Open-3D-Engine-23.05

[guglovich]

- A new MPS (Multiplayer Sample Game) module is offered, which implements a well-documented example of a simple ready-made multiplayer game. Developers are offered a set of typical game elements, as well as client and server components for organizing a network game, which can be used as a basis for creating their own games. There are examples of generating landscapes, manipulating lighting, creating visual effects, working with sound, connecting scripts, and using advanced rendering modes such as cascading shadows, global illumination, reflective and emitting surfaces. Also included is a set of game assets that can be used in other projects.
- Introduced is the ROS2 module, integrated with the Robot Operating System (ROS2) toolkit, which provides drivers, algorithm implementations, components, resources and utilities for building robot simulators. The module allows you to add code for the ROS 2 platform directly inside your simulator project, use ready-made templates, import resources, and connect virtual sensors.
- Implemented Material Canvas, a node-based scripting interface for creating and visually modifying generative materials and shaders, which combines the flexibility of Script Canvas with the capabilities of the Material Editor.
- Added a Material Pipeline abstraction layer to simplify the setup of rendering stages in order to achieve the right balance between performance and quality, regardless of platform and hardware (works by creating separate shaders for each rendering stage).
- Improved extensibility of the game editor (O3DE Editor), which implemented the Action Manager API, allowing you to add your own menus, hotkeys and contextual actions, as well as connecting scripts in Python.
- PhysX 5.1 physics simulation engine support was added.
- Animation editing interface was updated. New process for Animation Asset Import was added. Added performance visualizer to simplify - AnimGraph profiling and optimization.
- Added Paintbrush tool to the Terrain System for painting within the viewport and creating or modifying terrain.
- Added new interface for navigating through game assets (Asset Browser), which allows performing operations with files and inspecting assets.
- Possibility of simultaneous installation of several different versions of O3DE engine in one system that can be used in conjunction with different projects.
-Gem add-in system allows to specify platform compatibility and filter modules by platform support.
- Integrated support for OpenXR standard for stereoscopic rendering.
- Improved performance on mobile devices.

[rabcor]

Ok i'm a bit curious, i've never seen anyone use lumberyard, and i've never seen anyone use o3de either. Most devs use unreal or unity. We have unreal for top graphics, unity for ur average indie game dev, and godot to scratch that open source game engine itch.

I recently got into game dev, i tried unity for a bit, then went to godot because it seemed easier to learn on and get my feet wet (which it was! definitely recommend a fresh game dev start there.) then went to unreal, and i'm really liking unreal although it's perhaps poorly suited for games that are smaller in scope. Unity,,, The only reason I can really legitimately think of to use Unity over UE5 is documentation and support. In unity if u run into a wall, someone else has done it before you and shared a solution. And even if they haven't, docs will probably cover ur back.

In unreal, if u run into a wall, the docs don't explain jack shit and it's luck of the draw for even the most common of problems whether any web search will yield you results on how to get past them or not.

I admittedly probably would have stuck to godot if the 4.X versions of the engine had a working IK implementation. But it doesn't and that little detail kinda kills the potential for any standard 3D game development on it. IK is not something that can be missing in modern game development.

But where does O3DE even fit in? And for that matter as a cryengine fork, why would anyone use it over just cryengine... if they wanna use cryengine?

[jayrulez]

Ok i'm a bit curious, i've never seen anyone use lumberyard, and i've never seen anyone use o3de either. Most devs use unreal or unity. We have unreal for top graphics, unity for ur average indie game dev, and godot to scratch that open source game engine itch.

I recently got into game dev, i tried unity for a bit, then went to godot because it seemed easier to learn on and get my feet wet (which it was! definitely recommend a fresh game dev start there.) then went to unreal, and i'm really liking unreal although it's perhaps poorly suited for games that are smaller in scope. Unity,,, The only reason I can really legitimately think of to use Unity over UE5 is documentation and support. In unity if u run into a wall, someone else has done it before you and shared a solution. And even if they haven't, docs will probably cover ur back.

In unreal, if u run into a wall, the docs don't explain jack shit and it's luck of the draw for even the most common of problems whether any web search will yield you results on how to get past them or not.

I admittedly probably would have stuck to godot if the 4.X versions of the engine had a working IK implementation. But it doesn't and that little detail kinda kills the potential for any standard 3D game development on it. IK is not something that can be missing in modern game development.

But where does O3DE even fit in? And for that matter as a cryengine fork, why would anyone use it over just cryengine... if they wanna use cryengine?

It fits in where you want an engine that is usable for AAA development and is liberally licensed.
While it still has a little CryEngine heritage, the engine is completely different from CryEngine.
The engine is almost completely rewritten and works very differently from CryEngine.
Also, CryTek has removed CryEngine source from Github. There is not much information about the state of the development. They've missed a lot of development milestones over the past few years. A lot of people have lost faith in that engine. You can see this on their discord.
O3DE is developed in the open and has a lot of industry support. I would say it has a much brighter future than CryEngine so I would opt to use O3DE over CryEngine.

Godot is open source and works well when used the way the devs expect. However, it is not as flexible as O3DE when you want to take it apart and build things the way you want.
Also, O3DE is suitable for other domains like robotics simulation that Godot doesn't care about. Engines like Unigine or Evergine are usually mentioned here but it is nice to have a completely free option in O3DE.

It is still early days for O3DE and we are yet to see what they are fully capable of delivering. However, they have been doing a good job and making great strides with each release.

[rabcor]

Snip

Sounds like O3DE is an up and coming open source 3D game development engine. It's not accurate that godot is less flexible than O3DE when you want to take it apart and build things the way you want. Godot's source code is somewhat famous among it's fans for being easy to understand and extend. It's also very easy to develop plugins for Godot to add missing featuers in. I can't quite imagine an engine being more flexible than godot, more feature complete easily, but not more flexible.

After trying Unity, Godot and UE5 I ended up on UE5 though, it's too bad O3DE is such a latecomer, it doesn't seem like it's quite ready for prime time yet (neither is Godot, although imo the only things it's missing is a working 3D IK implementation and a stable editor that doesn't frequently crash, sure it's missing some other big features like texture streaming but you can make great games withuot that, it's harder to make great games without IK these days).

[jayrulez]

Sounds like O3DE is an up and coming open source 3D game development engine. It's not accurate that godot is less flexible than O3DE when you want to take it apart and build things the way you want. Godot's source code is somewhat famous among it's fans for being easy to understand and extend. It's also very easy to develop plugins for Godot to add missing featuers in. I can't quite imagine an engine being more flexible than godot, more feature complete easily, but not more flexible.

After trying Unity, Godot and UE5 I ended up on UE5 though, it's too bad O3DE is such a latecomer, it doesn't seem like it's quite ready for prime time yet (neither is Godot, although imo the only things it's missing is a working 3D IK implementation and a stable editor that doesn't frequently crash, sure it's missing some other big features like texture streaming but you can make great games withuot that, it's harder to make great games without IK these days).

When I talk about flexibility, I am talking about how feasible it is to replace or extend parts of the engine. While it is possible to replace and extend stuff in Godot, more of the engine is developed in a coupled manner.
For example: If you replace the renderer. The Godot renderer is inherently tied to the engine. It is possible to replace it but it would take a lot more work.
In O3DE, even the renderer is just an optional module. The renderer can be replaced without having to change too many things. The renderer can even be used outside of O3DE (though it would still depend on the AzCore and AzFramework library). You could take AzCore, AzFramework, and other individual libs and build up your own engine if you would like which works differently from O3DE. That's how O3DE is architected. Most features are developed as optional/replaceable modules. When you want to replace parts of Godot or extend it, the changes are usually more invasive. depending on what you want to change.

Don't take this as a criticism of Godot. The Godot devs made a conscious effort to design the engine this way. It is easier to make all parts work better and more seamlessly together without the need for glue code or glue layers that you would find in O3DE. It is a trade-off. The approach O3DE takes makes the code-base more complex, while offering more flexibility.