[Feature Request] Open World Support + Suplemental tools

Hey Lumberyard team,

So I am really interested in large open seamless world support for LumberYard. So here is what I mean by that. Maps that are Larger than 4km x 4km without running into floating point precision issues and The player / players can walk between each map seamlessly with out any loading screens. MMOs, Large scale single player, Cooperative games, Flight sims and Space Sims are the best examples here.

Here is a few examples to show you what I mean - Link, Link,and Link

That
said - There are a bunch of ways to implement large world support. How ever I will list some methods that can be used to achieve this. I will let you fine folks go over the finer technical details.

  1. Double Bit floating point precision - This is the method that Star Citizen and Space engineers use.

  2. Rebasing the player origin - This is the method that Unreal Engine uses. However it does not work in multiplayer YET on Unreal Engines side out of the box.

There also needs to be supplemental tools to help in the content creation side of these large seamless open worlds. Otherwise there will be allot of complaining and headache on the end users side.

Example supplemental tools -

A Procedural Rule Based foliage placement tool - We should be able to define what trees and foliage we want to place and then define a volume to just place the foliage. Similar to this - Link

Open Street map integration for the rapid placement of roads, buildings, and landmark objects. We should be able to tweak the road networks as well. Maybe Similar to this - Link

  1. Some sort of large scale Level of Detail system that can handle lots of LODs with minimal impact on performance.

  2. A robust object Instancing system - Lumberyard / Cryengine already has a robust object instancing system. But it could be better out of the box.

That said - I hope that this helped. :slight_smile:

  • HeadClot

I am sorry to bump this but could an Amazon employee please let us know on the priority of Large world support as listed above? Or at least acknowledge this ticket.

Hey @HeadClot - sorry for the delay, let me ping the team now and see what information they have! It’s definitely feedback that has been noted on our side, but I’ll see what I can do on getting someone in here with more information :slight_smile:

Hi @HeadClot,

Thank you for all the feedback, these sound like great feature requests. We have definitely seen enough interest in a seamless open world and it has been added to the list!

Hey,
Just giving this a bump.
Has there been any movement on this internally at Amazon Games Studio? It has been almost a year and I would like to start development on a very large project with Lumberyard. But large world support is at the core of the project.

Thank you for your time,
HeadClot

Hey @Jason or any amazon staffers any movement on this?

Why would you rebase the player origin if you’re using 64bit precision? It seems like everyone is asking for 64bit precision just because star citizen is doing it. There is a lot of overhead to consider. A cheaper approach would be a segmented/sector system.

Yes me too, as without that LY is a no go. I’d use it for other things, but a huge project I am also moving fwd on needs this desperately.

That’s great feedback.

Large world support is on the roadmap but we don’t have anything to really talk about at this moment in time.

@Kyai

I actually completely disagree. I do believe that 64-bit Double-Precision Floating Point (f64) units for position is a required feature, and the best feature. The “overhead” (that you so claim) is extremely marginal, and modern computers can easily handle this. We don’t want a “segmented” (sector/segmented) system, and we want a SEAMLESS system (using 64-bit Double-Precision Floating Point (f64), and yes we do want something identical to “Star Citizen” and “Space Engineers”.

If you look at the “optimizations” that Sean Tracy (Technical Director - CryTek / Cloud Imperium Games) has done to Lumberyard, you’ll see that the optimized 64-bit double-precision (optimized and multi-threaded code) that Star Citizen (and Cloud Imperium Games) is currently using is actually substantially FASTER than the current/latest legacy Lumberyard 1.12.0.0 code. I believe this should be a major priority, 64-bit double precision floating point, and procedural content-generation tools should be a very high priority.

I also agree that we do need powerful procedural content-generation tools (similar to what CIG/Star Citizen has built for Lumberyard), a very small team of developers can customize and build a “AAA-quality” game using procedural content generation. Small developers and indie studios need Advanced Procedural Tools for Procedural Planets, Pre-built Biomes (Mountain, Desert, Woodland, etc.), Advanced Character Tech, Planet Editor, Advanced Weather System, Item/Inventory 2.0, etc.

For flight/space simulators, and even large Train maps, we need very large open maps (with highly detailed photo-realistic terrain) and we need extremely photorealistic “procedural content generation” (with various LOD’s).

We definitely need 64-bit Double-Precision Floating Point (f64), as well as powerful procedural content-generation tools (for Procedural Planets, Pre-built Biomes (Mountain, Desert, Woodland, etc.), Advanced Character Tech, Planet Editor, Advanced Weather System, Item/Inventory 2.0, etc.

Extremely powerful and advanced content and games can be created by very small teams of Indie developers (3 to 13 developers). We just need the tools (and tutorials).

These content-generation tools (and sample assets) need to be “built once” but can be used by many. If these advanced features/tools were added to the Lumberyard engine (like CIG/Star Citizen has done), if these tools/features were added to the engine, users can easily build large high-quality AAA-quality universes (using advanced procedural generation tools), and build “infinitely” large Universes with a very small team of 3 to 13 developers.

We also need an “Amazon Lumberyard Storefront” where we can post/share/sell ultra high-resolution game assets (additional vehicles, Flora, Fauna, etc.) that can be used/re-used in games.

Yes, we have several projects and have been waiting on this same exact thing. Unfortunately we’ve been waiting over 4+ years for this now. I’m really hoping that 64-bit Double-Precision Floating Point (f64), as well as powerful procedural content-generation tools (for Procedural Planets, Pre-built Biomes (Mountain, Desert, Woodland, etc.), Advanced Character Tech, Planet Editor, Advanced Weather System, Item/Inventory 2.0, etc. can be added to Lumberyard fairly soon.

Most/All of these tools have already been created/implemented (and are being used) by CIG/Star Citizen (Chris Roberts).

I just wish that Amazon/Lumberyard would “partner” with CIG, and begin adding all of these advanced engine features/tools to Lumberyard (either “refactor” the code modifications and add them as “gems” to Lumberyard, so that users can add 64-bit Double-Precision Floating Point (f64) to Lumberyard by installing a new “64-bit Double-Precision Floating Point” gem. If possible, please add these additional features (64-bit Double-Precision Floating Point) to the latest version of Lumberyard as “gems”.

Also create some new/powerful procedural content-generation tools (such as those created by CIG/Star Citizen) so that we have “Planet Editors” (for editing/modifying planets/terrain) and also “Universe Editors” (for editing/modifying/adding planets/moons, planetary orbits, etc.) as well as Advanced Procedural Tools for Procedural Planets.

I do hope that Lumberyard devs can collaborate and work closely with the Star Citizen dev team. I hope many of these tools (and code) can be re-factored (as gems) and integrated into Lumberyard (as “Gems”) that we can add to Lumberyard, and we definitely need Advanced Procedural Tools for Procedural Planets, Pre-built Biomes (Mountain, Desert, Woodland, etc.), Advanced Character Tech (as well as “culling”), Planet Editor, Advanced Weather System, Item/Inventory 2.0, etc.

Has any progress on this been made?

Thanks,

Mark

Any updated information on this? Can this please be put on the latest Roadmap, and please give us a timeline as to when these features will be implemented (and expected release/timeline)?

It’s already been 2+ years (since this post) and we’ve been waiting for over 4+ years for these features. Any updated information on this? Can this please be put on the latest Roadmap, and please give us a timeline as to when these features will be implemented (and expected release/timeline)?

I would have to agree with @Mark.Malewski - Any info on this would be nice.

@Binky_LMBR
Any news on this? We have several large projects as well, that we’d like to use Lumberyard for, but we’ve been waiting on “Large World Support”. Our only options at this point is Unreal Engine, but we’ve been following “Star Citizen” (CIG) and see that they have modified Lumberyard (to support Large World Support) and we need these same exact features in Lumberyard. Any idea as to when this will get done? It’s been 2+ years (since this original post) and we’ve been waiting for over 4+ years for these features. Any updated information on this? Can this please be put on the latest Roadmap, and please give us a public timeline as to when these features will be implemented (and expected release/timeline)? Thank-you! (and Happy Holidays to the Lumberyard Dev Group!)

I agree, there are more and more open world games hitting the market. There needs to be an engine for Indie Devs that can handle large open worlds. I’m not sure why all the existing free engines don’t think this is an important feature. There are a lot of us that have been fighting for it in Unreal Engine for years. Are we going to have to wait years for LY to figure out that it’s important? I would just like to point out that a good percentage of the best selling console and PC games released in 2017 had large open worlds. Look it up, I did.

Hey Chef_JC - Thank you for your reply. This really makes me happy that large worlds are being worked on at Amazon and the various partner studios.

Cannot wait to see the fruits of your folks labors :slight_smile:

It’s not new to us that today’s most popular games are both multiplayer
and massive scale (we’re big fans of data, too!). As you probably know, many of
the game teams and people building with Lumberyard have created games of
incredible scale in the past, and it won’t surprise you that some of those
teams are planning to keep pushing the boundaries of large, open worlds. We’re
working closely with these teams (including some of our own game teams) to make
sure that Lumberyard can build the ambitious games they’re inventing.

As this thread has already pointed out, big worlds is challenging
problem to solve across many axes (coordinates, performance, terrain, content tools
– and like Mark above points out, just because you can run a huge open world, doesn’t mean it gets any easier to create the square miles of great
content to fill it…). In 2017, we focused heavily on the core foundational workflows our customers needed to build games with lots of content (e.g. slices were built with large-scale content in mind, and I think you’ll agree EMotion FX makes it easier and faster to create a game with lots of animated characters). While we don’t have anything specific to reveal about big worlds just yet, we’re working very closely with some of the customers mentioned above, and we think you’ll like what we have planned for this year.

I don’t believe it’s that bad, having worked on a couple of MMO’s and RPG’s there’s methodologies I’ve come across from other engines that seem to hit the nail.

Voxel and massive inter-planetary (like Star Citizen) aside it’s just a matter of streaming in chunks (tiles) at vector boundaries and having physyx (or the equivalent system) perform a point of origin reset (a la Unreal’s world editor).

It’s been a long while since I’ve used LY or CE but as far as I was aware it has texture streaming tile boundaries and async streaming capabilities already. It’s a matter of applying it to terrain to be stitched at co-ordinate boundaries.

Of course you’d want to do it properly, so en mass instancing and auto terain LOD / Foliage LOD’s are a must but in practice it’s not that difficult to do. Well that’s if you understand the engine and the underlying dependancies…

A lot of these issues were solved decades ago. I’ll agree with 64-bit precision though, it WILL have a lot of overhead compared to standard physics libraries for games. Chances are if you need that sort of functionality you’ll have a team who can deal with it.

Whereas a 40 tile semi-openworld game with procedural placement, even a lone wolf can deal with that.

Just to note (for others reading), Unreal has had large world support for a long time it’s called world composition (it’s in their docs)… Although it’s lacking a major advantage, real-time GI.!