Open 3D Engine (O3DE) from the Open 3D Foundation is what was once Amazon Lumberyard, now open source it's just had a first major stable release. This 21.11 version comes as a result of work done together with the likes of Adobe, AWS, Huawei, Intel, and Niantic and hundreds of community contributors.
“With the first major release of the engine, developers and content creators can get started faster—and have confidence that the core components of the engine are stable and supported,” said Royal O’Brien, GM of Digital Media and Games for the Linux Foundation. “Engine builders, 3D simulation developers, and metaverse developers can use O3DE’s open standards and wide range of content creation tools to build the multiplatform 3D experiences of the future, today.”
On the subject of Linux support, it's now officially in the preview stage for both the editor and runtime.
Lots of features were added to the engine including performance profiling and benchmarking tools, an experimental terrain system, a Script Canvas integration for the multiplayer networking system, and an SDK to facilitate engine customization with platform support for Windows, Linux, MacOS, iOS, and Android and much more.
See the official announcement for more.
https://issueexplorer.com/issue/o3de/o3de/4898
Last edited by Binogure on 2 December 2021 at 5:27 pm UTC
That's funny cause I recently tried this engine, and I can tell the binary will work only with the specified Ubuntu version. Its broken on Arch and Debian. But there is a workaround, sharing a link to the root issue:
https://issueexplorer.com/issue/o3de/o3de/4898
Bummer. You're right. It is broken. In my case it fails with clang/libclang bein' the wrong version, rather than libssl issues, and it's unable to install the right version due to conflicts. Guess I'm stickin' with Godot for now while they get the early issues worked out of this one.
Yeah, let's all just keep our attention on Godot because this is a waste of our collective time imo...
Last edited by TrainDoc on 11 January 2022 at 3:02 pm UTC
Yeah, let's all just keep our attention on Godot because this is a waste of our collective time imo...
To be fair, I don't think this engine is meant for small Indie studios and one-person devs. This is more for large projects that need all the advanced features and can handle the complexity in return.
It's still great to have, because it's the only FREE engine of its kind, and it might be of interest for large studios that want 100% full control over their project, but still don't necessarily wish to develop their own in-house engine.
Personally, I guess I will stick to Godot, haha!
Last edited by Kimyrielle on 2 December 2021 at 7:31 pm UTC
I got nothin' against this existing, if for no other reason than having one more choice available in the cross-platform game engine space. Still gonna use Godot myself, but happy there's another option out there, even if it's not the right choice for me. Looking forward to Godot 4.
Based on latest Steam Next Fest, indie developers have really started adopting Godot, so you will surely not be alone.
I got nothin' against this existing, if for no other reason than having one more choice available in the cross-platform game engine space. Still gonna use Godot myself, but happy there's another option out there, even if it's not the right choice for me. Looking forward to Godot 4.Lotta people looking forward to Godot 4, near as I can tell.
Yeah, let's all just keep our attention on Godot because this is a waste of our collective time imo...To be fair, I don't think this engine is meant for small Indie studios and one-person devs.
...
Personally, I guess I will stick to Godot, haha!
While I agree with your reasoning, Godot can absolutely be done at scale and has been done (see sonic colors ultimate) it's just that Godot has been focusing on getting engine fundamentals out of the way before going into larger scale tooling like that. Stand by my waste of time assessment but I totally see where you're coming from. Here's hoping that this actually becomes something useful, but of course I would rather use tooling and code originally developed as FOSS/OSS which tends to have a "right solution" quality to it.
Edit: I would communicate that I would hope that developers in the FOSS community aren't focusing on this because personally I think there time is better spent elsewhere is more what I meant to imply.
Last edited by TrainDoc on 3 December 2021 at 6:29 am UTC
Godot 4 is looking too far into the future as well as they drop OpenGL support and 3.x branch does have major bottlenecks preventing creating large 3D projects with it...actually, godot 4 will drop openGL support, but godot 4.x will add it back, they had 3 options at hand:
1)try to make both renders at once and delay both renders.
2)try to make the vulkan render first and delay the openGL render for an 4.x version.
3)try to make the openGL render first and delay the vulkan render for an 4.x version.
they chose the second option, so if you absolutelly need to have GL suport you have to stick with the 3.x branch, in any case some features were backported to it from the 4.x branch =p
I wonder what is easier to do - add OpenGL support back to Godot 4 or O3DE? Also I don't see major improvements overall for Godot 4 except for graphics, so I guess most major bottlenecks are still there, right?well godot 3.x added more features than i was expecting, so i think the 4.0 may have more features than initially planned as well.
in any case both engines come from different dictions.
lumbeyard was so painfull/hard to use that no one wanted to use it, but they had an triple A quality render.
godot was so good and easy to use that many indies are migrating to it or starting to learn game development on it, and now its geting an better render to better compete in the market of engines with cuting edge graphics.
only the future can tell what engine will be more sucessfull, i think both will co exist for a long time, and i hope both can borrow code from each other, o3de (formely know as lumbeyard) can learn from godot how to be easier to use (and maybe even add gdscript support or some similiar script lang)
and godot may be able to borrow advanced code techniques from lumbeyard or maybe even have a lot of options of renders (the same way blender do have with cycles, eevee, the intel developed one, the amd developed one etc)
*im not sure if it was amd or nvidia or both have their own solutions.
Everything can be bypassed in Godot except that, and that is major problem preventing implementation of streaming systems = no larger worlds :(
Updating geometry produce major stuttering and consumes most of frame, and it is impossible to do partial updates (i.e. index buffer only).
To me, Godot 3.x weak point lies not in render but in data model design, especially how it handles geometry.you mean stuff like level of details? i saw an plugin for that.
Everything can be bypassed in Godot except that, and that is major problem preventing implementation of streaming systems = no larger worlds :(
Updating geometry produce major stuttering and consumes most of frame, and it is impossible to do partial updates (i.e. index buffer only).
but texture stream is an feature that godot indeed lack.
now, if only we could have something like nanite, lumen and asset stream...
So this is lumberyard? what happened to lumberyard, discontinued? Also if this is lumberyard then its open-source crytek engine 3 or 4? Does it currently support DX12 and Vulkan?
I took quick trip to Wikipedia and project page and found some answers to those questions.
So O3DE is successor to Lumberyard that took some parts from it and some parts are written from scratch. I checked also the Lumberyard Git repository activity and there hasn't been anything for a while, so successor part must be true.
Crytek connection might still be there, but it's getting bit muddier as some code has been rewritten. I guess over time situation will be like Source Engine and Quake.
DX12 and Vulkan is supported on Windows, Linux only has Vulkan. Which makes sense.
To me, Godot 3.x weak point lies not in render but in data model design, especially how it handles geometry.you mean stuff like level of details? i saw an plugin for that.
Everything can be bypassed in Godot except that, and that is major problem preventing implementation of streaming systems = no larger worlds :(
Updating geometry produce major stuttering and consumes most of frame, and it is impossible to do partial updates (i.e. index buffer only).
but texture stream is an feature that godot indeed lack.
now, if only we could have something like nanite, lumen and asset stream...
Not only texture, geometry, audio, etc. are not streamable. It is just not there in any way.
For 2D games that is not issue, but for 3D that hits quite hard.
See more from me