[MUSIC PLAYING]
[WIND WHISTLING]
[MUSIC SWELLS]
AMANDA: Hey, everyone!
Meet The Ancient One, a 50-million-polygon character
imagined by Aaron Sims Creative for our latest Unreal Engine
5 demo, Valley of the Ancient!
With a reputation for creating incredible creatures,
learn more about The Ancient One's development,
and how ASC pushed the animation tools to the limits,
animating them entirely in-engine.
And for the educators in the audience,
we've created a brand new guide to help you learn everything
you want to know about Unreal Engine 5 Early Access,
including when to start incorporating it
into your classroom.
Download it via the feed today!
Sweden-based studio Experiment 101's first title, Biomutant,
takes a unique approach to the post-apocalyptic
genre--creating a "weird, but in a good way" action RPG.
Discover more about the relatively small team's
experience as a new studio shipping their first game,
and how they developed such a massive world.
And now over to this week's top karma earners.
Many thanks to:
Everynone, CtnDev, ClockworkOcean, mightyenigma,
chrudimer, L1z4rD89, LogierJan, Mahoukyou,
Jacky, and Zegi_assets.
Master physics-defying magic in Cypher
Creations' action-puzzler Strawhart--go on a quest
to start a brand-new cult and resurrect an ancient evil
in the realm of Acre.
Wishlist Strawhart on Steam.
Once you've finished taking over the world,
pop into this lovely kitchen created
by Justin Jager for a snack.
Built to experiment with UE5 and Lumen,
they've leveraged Quixel Megascans, in addition to
their own models.
Head over to Justin's ArtStation to see more of their work!
Set sail in The Black Swan, a short film by Gianpietro Fabre
inspired by their work with Oslo-based production company
Bacon--and Master & Commander.
Watch the full short and see more of Gianpietro's work
on their ArtStation page.
Thanks for watching this week's News and Community Spotlight!
VICTOR: Hi, everyone and welcome to Inside Unreal,
a weekly show where we learn, explore, and celebrate
everything Unreal.
I'm your host, Victor Brodin.
And today I would like to introduce-- once again,
thank you for being here--
Chance Ivey, senior technical product designer.
CHANCE: Glad to be back.
Thanks for having me, Victor.
Excited.
VICTOR: Awesome.
And we are going to talk about new world-building features
today.
And to help us in this endeavor, we invited Jean-Francois Dube.
Welcome to the show.
Principal programmer, got to make sure I mention that.
JEAN-FRANCOIS: Happy to be here.
CHANCE: Now we're super glad to have you.
Yeah, this is one of the workflow tools
that we employed for Valley of the Ancient in Unreal Engine 5
that I think had--
I guess it required us to change the way we thought quite a bit
whenever we came to approach world-building in general.
So I'm really excited today to hear more
about some of the thinking behind it
and have you share a lot of the details about how it all works,
and what all is in it with the community.
I think you've got some slides you wanted
to walk through for starters?
JEAN-FRANCOIS: Yes.
Yes, I have some slides, so--
CHANCE: Great.
JEAN-FRANCOIS: --I'll start with that.
CHANCE: Great.
All right.
JEAN-FRANCOIS: Are they showing up?
VICTOR: Not just yet.
Houston, can we get the sides up, please?
You're good to go.
CHANCE: Thank you, Houston.
JEAN-FRANCOIS: Yes, thank you.
Yes, so I'm going to start off talking
about what are the motivations between doing
all these changes.
So just a little bit of history.
In UE4, Actors are saved in a specific level, right?
So a world is composed of a list of sublevels
in a persistent level.
And the Engine can stream in and out of the sublevels,
and the persistent level is always loaded.
Moving Actors between levels is a manual operation,
so the user has to keep track of the current level.
You have to select the target level
you want to move your Actors in, right click on the Actors,
select Move To Current Level.
And it's essentially doing a cut-and-paste,
so it can lead to broken references
and all kinds of problems.
And just moving Actors around in space
is not enough because, it's just growing the level downs,
right, the current level downs.
It's not moving Actors between the [AUDIO OUT].
So this is one thing that we wanted to fix.
And then each Actor is saved in its own file, its own level
file, I mean.
So if I work in a specific level and I'm changing some actors,
and let's say that Chance is [AUDIO OUT]
I think [AUDIO OUT] he wants to change some other Actors that
are in the same level, but maybe they are hundreds meters away.
So we're not competing for the same things.
Even with that Chance cannot work because I
have to level file and check out.
So he has to contact me and say hey,
when are you going to release the file?
And I might say 10 minutes, and then release it
somewhere after lunch.
CHANCE: Yeah, that never happens.
JEAN-FRANCOIS: No, no, exactly.
And then you can network in the meantime, because you
have to get my changes before.
So since we don't support merging map files,
you have to wait.
So you have to figure out, work on something else.
So it's one of the big problems.
So to overcome this, the user would make changes
to how they organize their levels in the editor.
So making smaller level sizes or making layers,
like a sound layer, a gameplay layer, lighting layers.
But one problem with that is that it also
affects the cook build, right?
So when going into a cook build, you still
have all these layers.
All these levels to stream, and it's not
ideal for streaming performances.
So what we really wanted to do with World Partition
was to break how we organize the data in the editor,
and how it is organized in a cook field.
CHANCE: Right.
Real quick, on that note.
Yeah, you talk about building things in layers
so people can work better together.
But still it's this finite bucket of all those things
inside that layer, right?
And that's things need to talk between those layers,
it's really tricky.
You still have to think really hard about where
you put things.
You break things up a little bit by discipline type,
but still spatially it might be similar to where
something else is, and without having that other level loaded
you know--
and you still have a finite set of bounds as to how
far out those things go.
So building further out this way,
there might be not items in the layers below that.
You still have to have the holistic view of everything
else that everybody is still working on in those big, binary
blobs, right?
JEAN-FRANCOIS: Yes.
So it forces teams to have some level of organization
to make sure that everything is at least
[AUDIO OUT] fine-grained enough so people can work,
but it doesn't have that much impact on the streaming
performance at runtime.
CHANCE: Right.
Right.
Yeah, it just loads the whole thing in anyway, just clump.
JEAN-FRANCOIS: Right.
Yeah, exactly.
So with that in mind there are four goals to World Partition.
Is to first reduce contention, then completely remove
the manual level management, and to allow tweaking
of the runtime levels topology.
So make a complete distinction between editor
and the runtime levels.
And also to add automatic distance based level streaming.
So you don't have to put level streaming volumes,
or have some kind of--
have to write code to stream depending on some conditions.
CHANCE: Right.
The user enters the elevator, and so you're
streaming all the stuff behind the elevator
out and all the new stuff in this new location, right?
It's not something you have to think about the same way
anymore.
JEAN-FRANCOIS: Yeah, exactly.
But we'll have some-- some things are in the works,
to handle this specific case.
Yeah, 99% of the time, what you want
is distance based streaming.
Yeah.
So the first thing to that we want to address
is file contention.
So that's why we introduced one file per Actor.
So that's a separate feature.
So it can be used without the word partition,
but World Partition cannot be used without one file per
Actor.
CHANCE: Got it.
Oh, so you're saying that one file per Actor
can be used in existing non-World Partition
maps in UE5?
JEAN-FRANCOIS: Yes.
CHANCE: Great.
OK, cool.
JEAN-FRANCOIS: So it can be involved directly
in the editor, and the editor will just
do all the job to convert and add the files to Perforce.
CHANCE: Awesome.
JEAN-FRANCOIS: So in a nutshell, one file per Actor
is saving Actors in their own file.
So it's going to create a USF file per Actor.
And these files are going to be stored in the specific folder
that you can see here, just below my mouse.
So that way the level does not track anymore
what Actors it's holding.
So the level is just containing an empty Actor array,
and that way we can add and remove Actors
without having to check out the level file.
So when you load the level, which
is when it's one file per Actor, the level
will just go into that folder and parse--
it's just going to parse all the files there and load them.
So it's auto-discovering the Actors
instead of keeping a list inside of the file.
So if you're just modifying Actors,
you don't have to check out the level file anymore.
So that fixes most of the contention that teams have.
CHANCE: Right.
And one thing we noticed specifically
on that was-- well, something that I've
run into quite a bit with UE4, or UE3 development in general,
is occasionally it will think that the UMAP is dirtied,
and I don't think I changed anything in it.
And it's not clear to me what got changed.
Whereas with this, it tells me exactly the Actor
that I, as a designer, accidentally
bumped that rock over and I don't want to save that change.
But maybe I was doing something later next to that,
and it was, maybe, some mission checkpoints
or a volume that's for gameplay that I do want to have changed.
And so instead of just checking the whole map back
in, hoping that I didn't accidentally touch stuff
that I didn't need to touch, I've
got a nice fine list, that you can see here
in that Change List view, that shows me, oh, I only
need these changes, these other ones were accidents.
And it's very clear to me.
Which is super nice.
JEAN-FRANCOIS: Yeah.
And another thing that is a great improvement with that
is that if you have a level that contains 1,000 Actors,
you just change one, you're going to submit the whole file
to Perforce.
And it means that if the file is, let's say, 100 megs.
With one file per Actor, you're just
going to submit a one-key or two-key Actor to Perforce.
So it's greatly to reduce the sync times and the storage
on Perforce.
And probably has an impact on integrations also,
division times and--
CHANCE: I'm sure for integrations, absolutely.
I think multiple times on working
at Valley of the Ancient, we would sync things,
and parts of the map would be repopulated
and then other ones would be what I still have currently,
and those kinds of things too.
And there was no real contention whenever Team A versus Team
B that are working on specific things,
or stepping on each other's toes,
unless they're already talking about
stuff they're placing in the same spots.
Yeah.
Just a real quick question on that.
You talk about the actual molecular asset change
that you'd be checking in versus having to throw a whole 100
megabyte map.
Do we have any idea of--
since we're breaking up the concept
of where that data lives, what does it
mean for memory overall?
I think for Valley of the Ancient,
all of our external Actors were only a few megs overall,
and there was like 15,000 of them in there.
Do we expect to see disk sizes for, say,
a map that had all those in it, and then those separately,
to be about the same?
JEAN-FRANCOIS: Yes, it's going to be about the same.
Because we're not changing how the file is saved or it's--
it's going to be a little bit bigger,
because each USF file has a file editor and some stuff.
But it's going to be quite small, I think.
CHANCE: Great.
JEAN-FRANCOIS: It's not some data that we've gathered,
but I would expect it to not be that much bigger.
CHANCE: Yeah.
So there's not really a whole lot of compromise.
You're adding a bunch of files to disk,
but the disk space is still the same.
And it makes those molecular exchanges
with source control or other teammates
way easier than passing them a gigantic blob.
JEAN-FRANCOIS DUBE: Yes, exactly.
CHANCE: Great, cool.
JEAN-FRANCOIS: And you know exactly-- as you said,
you know exactly what you've changed.
Yeah.
CHANCE: That's great.
JEAN-FRANCOIS: So having that
it means that you're going to have larger changes.
So instead of having a change just with one UMAP file,
you're going to end up with changes with maybe 10 or 100
Actor files.
So we decided to add source control integration
directly into the editor to manage the changes.
To be able to create changes, move files around.
And the one specific thing that is super important
is that we added changes validations.
So let's say that you have two Actors,
and you've modified the two Actors, and one of these Actors
has as a direct reference to the other one,
so it needs to be checked in at the same time.
So we have validations that will not
let you submit if you have these two
files in two different changes.
So it's going to tell you this file
has a strong dependency to the other one,
you need to move them to the same changes before submitting.
CHANCE: Interesting.
So it's like if I were to update a reference on a material,
that material will dirty the static mesh, for instance.
Because it knows that it needs that.
Say, hey, you changed this that might have changed something
else here that you need to save.
Or if I move a texture, it knows that.
It's kind of that same kind of concept,
but brought to the source control management.
So you know that your change that affects other things,
it's going to bring those things along
with you through this validation whenever you go to submit.
JEAN-FRANCOIS: Exactly.
CHANCE: Great.
OK.
JEAN-FRANCOIS: And the system
is then-- that we provide a subset of validations,
but projects and licensees can write their own validations
and can add to the existing validations.
So if you have custom stuff that needs
to be checked in at the same time, as your NavMesh,
for instance.
You can write a validation.
So every time you end up having a problem on the production
floor, and you can just say OK, I
can write to a test to avoid that in the future.
So it greatly helps avoiding pushing stuff
to break everyone's day.
CHANCE: Right.
Yeah, it seems flexible.
And since every game is going to be a little bit different,
people can go through and have their own sets of validations.
And make sure that teams are working and submitting
things that don't break the build here and there.
But in general, some of the validation that's there
helped us quite a bit with that.
We didn't run into a ton of that on working on Valley.
Now a lot of our world building stuff
was mostly placement, but a few things that we did go in there
and add, I did get dinged to say oh, you're
missing the important things here
that I didn't know that someone else had hooked up to that.
And it was really helpful, because it
allowed me to then not revert somebody else's
work on accident.
JEAN-FRANCOIS: Yeah.
So the goal of the source control integration
is to be agnostic of the underlying source control
software.
So someone working in UE5, it will not
be lost if he goes to another team
and they use Git, for instance, or something like that.
You are using the same source control software and--
some features may not be there, some source control software
might not support shelving, for instance,
or something like that.
But the core of the experience will be the same.
CHANCE: And the color coding, too, is quite nice too.
Because it tells you what type of asset
you're going to be putting in, which is good.
Great breakdown.
Super cool.
JEAN-FRANCOIS: Yeah.
So with World Partition, we introduce a new way
to work in the editor.
So to be able to support very large worlds, we decided that--
it's impossible to load the whole world in the editor,
so we need to figure a way to be able to select
a region that you want to work in, and then
just load that part.
So when you load a partitioned world,
at first it's going to load an empty world.
The only thing that will be there
are the Actors that are specifically
marked as always loaded.
So this is usually backdrop and vista Actors
and things like that.
And then the users select some cells.
Here, we just selected a 2 by 2 region, and then
right-clicked Load Selected Cells,
and it's going to load the actual editor cells that
contains these Actors.
And then you can start working there.
I said before, it's needed for a very large world.
I think the value of the--
if you have a good enough PC, you can probably
load the entire thing.
But for a normal PC, if I can say.
It's not possible.
So you have to load a subregion in.
CHANCE: Yes.
Yes, this definitely comes in handy
whenever you're trying to work in a big space,
and you can move around.
If you're doing just set dressing and things like that,
you can operate section by section.
But even if you're building gameplay,
say you're setting up a spline that's
going to move through an entire large space, or you need to--
say you're going to drive down a street,
you want to add checkpoints specifically.
You can still get a lot of the benefits of this system
by just loading the cell you need,
and maybe the one next to it, and then unloading
the next one, and then moving all the way down.
And that doesn't just remove it from the viewport, that
hides it and actually takes out memory as well too, right?
So you're not paying for those resources at edit time
at all until you need them.
JEAN-FRANCOIS: Yeah, exactly.
Yeah, so the only thing is that if you
load some cell, and the trigger loading of some static meshes,
or some textures, unloading the cells
will still keep these meshes and textures in memory.
But that's how the Unreal engine works, right?
As soon as you load some assets, they will stay there forever.
But there's no garbage collection in the editor.
CHANCE: Right, right.
Yeah, which is why if you load Valley of the Ancient
and you run all the cells, you run through it the first time,
it's doing all of its first, oh right,
I'll pull all this stuff in for you now
and we'll move from there.
Cool.
JEAN-FRANCOIS: And the minimap
is generated using a commandlet, so it's
meant to be run nightly, or maybe hijacking
some other systems.
I'll talk about it when we go over the HLOD generation,
because we piggyback HLOD generation to generate
the minimaps.
CHANCE: Oh, cool.
Very cool.
JEAN-FRANCOIS: OK, so since the editor cells are completely
disconnected from the runtime cells,
we need to have a way to define the settings.
So we are providing a grid, which is a 2D spatial hash.
That's the first grid that we'll be providing
for UE5 initial release.
We're planning to release other type of grids, like maybe a 3D
grid, or something more adapted for corridor-based games.
But for now, we're just focusing on to 2D spatial hash grid,
because it's the most common case with landscape and things
like that.
So you can see here the settings for the grid
for the Ancient World demo.
So the cell size is 64 meters, so it's 64 by 64 meters.
And the loading range is also 64 meters.
It means that when playing the game in a cook build
or in a PIE session, the engine will automatically
load every cell that's inside the radius of 64
meters around the player.
CHANCE: And that's a radius, of 64 from the location
all the way around.
So 128 total.
So if there are 64 sized, that could be up to about four
at a time?
JEAN-FRANCOIS: Yeah, exactly.
So you can tweak these numbers, and hit PIE,
and everything will be automatically updated.
And it takes less than the second to go in PIE.
So doing that with UE4, it would mean
going through all the levels, taking all the Actors,
moving them back to the new level sizes
that you want to stream.
It's a completely different type of--
CHANCE: Different beast.
JEAN-FRANCOIS: --way to work.
Yes, exactly.
You were probably write a commandlet to do that or--
I don't know how teams ended up doing that.
Right now you're just change the value, hit PIE, and it's there.
CHANCE: Well, this is good for you
to be able to test really quickly.
You just make this change, and you
can redeploy to other targets just
to see how streaming is going to work on your target platforms
as well.
Because you have this, what, memory envelope
you're trying to fit everything into.
You got to test if your player can
see the difference between the HLOD version
and the full resolution version of things as you go.
So this is a really powerful way to tweak that out, make
sure your performance is feeling just right,
make sure you're fitting inside your budgets.
As well as your levels are designed in a way
that the player doesn't even see that the streaming is
taking place.
JEAN-FRANCOIS: Yeah, exactly.
And I'm going to show a demo after the presentation.
CHANCE: Oh, great.
Cool, cool, cool.
Hate to jump ahead.
JEAN-FRANCOIS: It's fine, it's fine.
Yes, so we have advanced settings there,
so you can create several grids if you want.
If you want to have some objects that maybe will have a smaller
loading radius, you can create another grid for that.
It's important to know that when generating the cook build,
it's going to generate sublevels.
So if you have two grids, it's going
to generate twice the number of sublevels to stream it.
So you need to be careful.
So that's why it's in the advanced section.
CHANCE: OK.
JEAN-FRANCOIS: Some words about the grid generation.
So at cook and PIE time, the engine
will generate sublevels, as I just said.
And we need to generate a hierarchy of sublevels
because Actors can only fit in one sublevel.
So in this case, we have 64 by 64 meters sublevels.
And then the higher level grid will have 128
by 128 sublevels, and then 256 by 256,
until we reach the point where we have a single level that
encompasses the whole world.
And that cell we call the Always Loaded cell,
because it's always loaded.
The radius will always be inside of it.
So if you have an Actor that has a reference to another Actor,
they need to be loaded at the same time.
So we need to compute the bounding box of all
the references and find which level in the grid
they fit into.
CHANCE: That's smart.
Yeah, so that way if you have something that's way far away
and you need to, for some reason, get some data on it
or react to some data on it, those
will be moved up this hierarchy as to where they live
and how they're loaded.
I see.
JEAN-FRANCOIS: Exactly.
And so if you have two Actors, and one that each of the map,
they will end up always loaded because of that.
CHANCE: Right.
Got it.
JEAN-FRANCOIS: So we do an automatic reference
gathering pass before moving Actors into the cells.
And then we decide in which level they will end up.
And also there's an advanced setting
on Actors, which is called Replacement.
So there's three different values.
You can set Actors to be always loaded so they will always
go inside the Always Loaded cell, for backdrop things
and things at the distance that you always want to be loaded.
Then you have the location, so it
takes the location of the bounding volume of the Actor
to select in which level they will end up.
So they will never get promoted to a higher
level, because we just use their position
to place them in the grid.
So 99% of the Actors show the location.
And then you have some Actors that you
want to set them by bounds, because they are very big.
So these Actors will use their bounds similar to the actor
referencing problem.
So they will take their bounds to select
which level can encompass them in this hierarchy.
CHANCE: Got it.
JEAN-FRANCOIS: And we have some heuristics
going behind the scenes, where if an Actor is too big,
but you've set it to be location, but if it's too big
it's going to be promoted to using its bounds.
CHANCE: OK.
JEAN-FRANCOIS: That was a problem in--
not a problem but that was happening a lot
in the Ancient demo, because the mass objects were very, very
big.
CHANCE: Yes.
JEAN-FRANCOIS: Some of them were very big, right?
CHANCE: Very large.
JEAN-FRANCOIS: So they were promoted to the higher level
cells.
CHANCE: Larger cells.
JEAN-FRANCOIS: Yes.
So that explains why when you run the game without HLODs,
you can see some objects popping before others.
That's because they are in higher level cells.
CHANCE: That makes sense.
And the same thing, too, if you go
into the Valley of the Ancient, and you drag
and you unload all cells, you'll see our character
on the ground and some of the stuff that's
right there in front of you, as well as some of the mountain
top pieces that were easier for us to keep always loaded.
They're fairly inexpensive.
We may not even show the full geometry
because the player can never get to those points.
But it would look a little Swiss-cheesy
if everything's out there, because we've
marked some of those things as always loaded,
because that was the best result we could get using this system
as we got there.
And it's generally pretty light, even in that level,
if you just loaded that, if you loaded nothing else.
Which is great.
JEAN-FRANCOIS: Yes, yeah.
CHANCE: Cool.
JEAN-FRANCOIS: And then once the grid is generated,
we have the automatic runtime streaming.
So the engine will use the streaming sources.
What we call streaming services, it's
defined by a position and some other settings,
mainly a radius in that case.
Players are automatically acting as streaming sources.
So when you go into drone, the drone
is acting as a streaming sources.
And we also added a streaming source component
to the character, as you can see on the right.
Because we want to be able to go back instantly,
so we want to keep things loaded around the player.
So that's how it's done.
CHANCE: Yeah.
And the little line there is the heading, right?
It's where the camera is facing so you
can tell the direction, if it's moving,
that's the way it's going to go.
JEAN-FRANCOIS: Exactly.
So here you see the loaded cells in green,
the unloaded cells in the red.
And there are some empty cells here,
which means that there was no--
because we're only showing the first level in the hierarchy,
so these cells are empty because there was no Actors in it.
Because these Actors that were touching
these cells are promoted to higher levels.
CHANCE: Higher levels of the hierarchy.
JEAN-FRANCOIS: Yes.
So it's not obvious at first, when you look at this debug
screen, but there's some debug options
to show the other levels.
So using streaming sources, you can use streaming sources
to pre-fetch a part of the world, also, so you can--
let's say that the player is going
to be teleported somewhere.
You can spawn an Actor there with their streaming service
component, and set the settings to be pre-fetched, not active.
So it's going to be pre-fetched, and once you're
ready to teleport, you can just switch the active state
of this streaming source and then
teleport-- do an instant teleport.
CHANCE: And you can query the state of that, the cells,
once you know them.
To know, hey, these are ready to go when you
can get that teleport there.
So it's always ready to go by the time you actually
fire the event to move them, which is great.
JEAN-FRANCOIS: Exactly.
So that's how they did the transition to the dark world.
So we can activate--
I'm going there to the data layers,
but when you activate a data layer,
it's just going to stream Actors in this layer that
are around the player.
So if you know that you're going to teleport somewhere before,
you can also say this streaming source activate these data
layers.
CHANCE: From where I am-- from where the player is?
JEAN-FRANCOIS: Exactly.
CHANCE: Yeah
JEAN-FRANCOIS: Yes.
HLOD.
So one thing that we wanted to do for HLOD
was to make sure that everything is automatic.
So there is no need to make complex HLOD settings.
You just set up a hierarchy of HLOD layers.
So each layer is going to generate its representation,
based on the child layer.
So the first layer doesn't have a child,
because it's the first layer.
So it's using the main world as an input
to generate the low resolution representation.
And then the parent layer is using the other layer
to generate.
So if you have a very big world, you
can set up several HLOD layers, which
are less and less and less expensive in memory.
But you can represent the whole world with that.
We have multiple labor types.
One of layer type is instancing.
So it's creating one Actor per cell,
with a single component per compatible asset.
So if you have 10 static meshes in your world, 10 static mesh
Actors that use the same static mesh,
they're going to end up in this Actor,
using a single instance component with 10 instances.
So it's creating a representation
of the world that is very lightweight to render.
So the instancing layer doesn't have visual quality loss
because it's using the same meshes, same textures.
But it's just stripping away all the physics and gameplay stuff,
right?
So the instancing layer is just the visual representation
optimized for rendering.
CHANCE: Right on.
JEAN-FRANCOIS: And then you can create
merge and simplified layers.
So these layers will work on their child layer.
So in this case, an instancing layer probably.
What they do is still create one Actor per cell,
but they take all the meshes inside the cell,
and they merge that into a new static mesh representing
the whole cell.
We run simplifying algorithms on that,
and pre-render the materials, also, into a single texture.
So it's really one draw call per cell
for a very distant subject.
CHANCE: That's great.
So depending on your cell size, that
can be relatively inexpensive across the board
to get everything loaded and running.
JEAN-FRANCOIS DUBE: Yes, exactly.
So if you take a look here, a typical use case
for a very open large world would be,
let's say you have a loading range of 128 meters.
So everything is fully streamed, physics, gameplay, everything
is there.
Then you can set up an instance layer, up to 768 meters.
This layer is still streamed, so its distance-based streaming
also, but it doesn't contain physics.
So from the 128 meters to 768 meters,
it's just a visual representation.
And then you can set up another merge layer
that will take the instanced layer as an input,
generate merge meshes up to two kilometers.
And then finally, you can have another merge layer that
will take this merge layer as an input
to generate two kilometers to infinity,
and set that layer to be always loaded.
So at any time you can like grab a helicopter, go in the sky,
and see the whole world, right and everything looks fine.
CHANCE: And as you come down,
it takes from that big chunk and it gives a smaller chunk
representations, all the way down to the final pro-res
that you'd want once you're actually
really up nice and close to it.
Cool.
JEAN-FRANCOIS: So you can achieve this
by just setting up 3 layers in the editor,
and setting up the parent layer.
And then you have a nightly presence
that runs with support-distributed generation
on the build farm.
So I think on Valley of the Ancient,
we were using 20 machines at some point to generate HLODs.
CHANCE: And you can generate
these via command line, right?
JEAN-FRANCOIS: Mm-hmm.
CHANCE: And just running a command.
So if you're just working locally,
you can regenerate these things yourself and just have them.
JEAN-FRANCOIS: Exactly.
CHANCE: Yeah, cool.
JEAN-FRANCOIS DUBE: But the thing
is that the merge layers are very long to compute.
So if you want to do a local test,
you can just remove the parent layers which are merged,
and just regenerate the HLOD 0, the instanced layer.
And as I said before, we piggyback on the HLOD process
to render the world minimaps.
So we're just using the last HLOD layer
to generate a top-view, because it's always loaded.
So we just use that.
CHANCE: Right, right.
Oh, it makes sense.
And I think we're ran into this on the project-- you
can correct me if I'm wrong-- but I think we had times
in our minimap where there were holes in the map
because it didn't have all of the cells loaded in the editor.
Does that happen at edit time, that generation?
Basically, does it happen based on what you have loaded
in the editor at the time?
JEAN-FRANCOIS: Yes, so if you render it
inside the editor, it just takes everything that is loaded.
So if you just load a couple of cells, yeah.
CHANCE: But yeah, load all your cells before you
generate your minimaps, or you'll
record some video with some holes in it
that you'll have to go rerecord.
As we found out.
Cool.
JEAN-FRANCOIS: OK, data layers.
This is something that we added also with World Partition.
So it's on par with the existing layer
system, which was an editor-only system, right?
So the existing layer system was there
to categorize Actors, toggle visibility in the editor.
So the new system is on par with that,
but it adds filtering of loaded Actors in the editor,
and also filtering of loaded Actors at runtime.
So for example, that's how we did the Dark World transition.
So we have a normal data for the [AUDIO OUT]
which is called Campfire Replace.
I don't know why it's not called Light World, but--
CHANCE: You know, names.
JEAN-FRANCOIS: And then we have
everything that's part of the Dark World assigned
to that data layer.
So when you go into the editor by default,
this data layer is not loaded.
But if you want to work in this data layer,
you can just unload this one, load this one.
And it's only going to load Actors part of that data layer
for the cells that you have currently loaded, right?
It's not going to load the whole world.
So it's affecting the current loadset.
CHANCE: Yeah.
And one thing I wanted to clarify
there for anybody that's gone through this,
you might see that there's a little bit of a difference
between having just these two data
layers swapped in the editor versus
when you swap them in the game when you run that.
What we did on the actual change is we actually
altered some global material parameter collections as well,
to change some of the things in the [AUDIO OUT] --really
using a couple of different systems
to get the full effect across to you.
This is the one where we have all the categorized assets
that we had built specifically for that, on top
of the base that is the Campfire geometry base, that does all
the streaming in and streaming out,
working well with World Partition.
Just wanted to mention it.
JEAN-FRANCOIS: Yes.
So data layers can be also used for several other type
of stuff.
Let's say you have a mission where you
need to collect all the stars.
So you can just put all the stars
into a special data layer for that mission, and at runtime
you can just enable that data layer and the engine
will start streaming, still around the streaming sources
but it's going to start streaming all of these Actors.
CHANCE: Yeah, that's really cool.
I hadn't considered that whenever
we were looking at this.
So you could put gameplay objects--
this can be any Actor that you can place in a scene, right?
It doesn't have to be geometry, specifically.
It's anything that needs to render in the space,
or have some data that's on it.
That's great.
JEAN-FRANCOIS: So most people think about data layers
to switch the world, like night and day, or things like that.
But it can be useful for missions and things like that.
Yeah.
Or just a broken bridge or something like that.
CHANCE: Right, yeah.
If you have a persistent game and the player
has proceeded to handle these missions.
And now every time they load up, you
need the world to be set a very specific way, you can do that.
I think from a workflow perspective
too, being able to toggle between the two
and seeing what the bridge looked like before or after,
you can look at that real quick and make sure
that this feels like a good state change for someone
to come back into, which is super nice.
JEAN-FRANCOIS: Yeah.
And you see the bridge in its two states inside the world.
It's not a separate build that you have to work in
and you don't have a context of what you're working on.
CHANCE: I wonder too-- now that I'm thinking,
I wonder if you could use some of the physics destruction
things to simulate something down and bake that
in from the original, where the bridge was.
And then just save that--
mark that for its own data layer,
and then just be done with the exchange between those two.
That's pretty neat.
JEAN-FRANCOIS: Yeah And data layers support HLOD.
So you can have specific HLODs for the Dark World,
or for a broken bridge.
If we take that example, if the bridge is broken
we probably won't see it broken at the very far distance.
So you can set up specific HLOD layer here for the data layer.
CHANCE: That's great.
The system's really, really nice and intertwined.
JEAN-FRANCOIS: Yes.
So there is a downside with that.
Data layers will also generate sublevels.
So you have to keep yourself from being
crazy when using data layers.
And that's why we added here the little green and red circles.
The red circle means that it's an editor-only data layer,
so it doesn't affect runtime.
It doesn't create sublevels.
It's meant to be used in the editor.
We have to make sure that we keep the number of runtime data
layers as low as possible, or at least
make some tests to see the impact on the streaming.
CHANCE: And on that note, we actually
combined all our data layers while we
were building the project.
I think we started with six or seven
while we were learning how they all worked.
But a couple of the reasons we did
that were for some quick performance testing
to-- a good example is we have foliage
in the Campfire environment, the Light World environment.
And we weren't sure exactly how much of a performance
hit that was going to have for us.
So what we did was we used the Blueprints,
which I think is next on your list here, to toggle those off
while we were running it and doing performance capture.
So we just would have it toggle those every few seconds,
and then we could look at the profiling data
and say, oh, our foliage is costing us this much.
How can we minimize that, whether it
be in optimizing the geometry, or how many there are
on the scene at any given time.
So they're powerful too, just as a tool for you
to work with your data.
And then we end up collapsing them down,
I think based on your recommendation,
before we ended up shipping, specifically for that reason.
JEAN-FRANCOIS: Yes.
But it's fun to see how you've used
that to do things that weren't planned to be done with that.
So yeah.
And just to mention that data use
can also be enabled via Blueprints and Sequencer.
We're adding a Sequencer track--
CHANCE: Oh, awesome.
JEAN-FRANCOIS: [AUDIO OUT] data layers.
CHANCE: Yeah, I knew about the Blueprints,
but I haven't touched Sequencer enough to know there.
But that sounds great.
JEAN-FRANCOIS: Yeah.
Sequencer support is not there in early access.
It's in the works right now.
Just a quick mention of about Blueprints.
So the Level Script still exists,
but every Actor reference will be always loaded,
because the Level Script is part of the persistent level.
So if it has direct references to Actors,
they need to be always loaded.
So it's just it's the same thing for Blueprint classes.
So if you have an Actor with a Blueprint class,
and you have references to other Actors,
they will be bundled together and moved to the higher level,
as we saw before.
So we have to take special care about that.
We need to favor Blueprint classes over a Level Script
for a script that contains Actor reference because of that.
CHANCE: Right.
VICTOR: Sounds like another reason
not to use the Level Blueprint.
JEAN-FRANCOIS: Exactly, yeah.
CHANCE: There are valuable reasons
to use Level Blueprint on example.
But yeah, in general, good practice
to do your big, quick prototyping, hooking stuff
together there, and then move things out
in modular self-contained managers and things
understand the state of the game a little bit better.
Early on, I think we had-- for this specifically,
we had a lot of the level switching code in the Level
Blueprint, or the data switching code in the Level Blueprint.
And we end up moving that, I believe, to game mode,
just because it was a class that we could access from pretty
much anywhere we needed to.
We knew that it didn't have a whole lot-- it didn't need
to know a whole lot about the world,
it could just call the functions that we needed on the world,
and that seemed to work out really well.
JEAN-FRANCOIS: That's why--
I was searching for the Blueprint that
activate and deactivate the Dark World
yesterday for the presentation, and I wasn't able to find it.
So that explains why.
CHANCE: Yeah, I think it's in game mode.
And we-- actually, it's funny.
You say that you can do these things in Sequencer.
The way I set that up, I believe,
was that I have Sequencer calling
into an object that actually accesses the game
mode to make the transition.
Because we need to have that separation between objects
in the world and things that are actually
affecting the entire world.
So there's a couple of callbacks there to make that work.
But I think it's in game mode.
Oh and then I will say, too, if you do dirty the map
with a World Partition map, chances
are you changed something in the Level Blueprint
or in the always loaded Actors.
So if you are working in a World Partition map,
and you see that needs to be changed,
you may have changed a persistent Actor, an always
loaded Actor in the persistent world, that thinks that, hey, I
need to take the UMAP too.
Or you changed something in script there,
or something else in that script got changed
and that's where it got dirtied.
So if you're working in this space and you think,
I'm using World Partition, I didn't
think I would need to check in the UMAP.
You might take a look at what you did change, and see
if it's actually referenced in there, because that will ask
it to be saved and checked in.
JEAN-FRANCOIS: Yeah.
And there is a lot of code paths that
still dirty the level instead of dirtying the exact object that
is modified.
So I think the rule of thumb is to submit the UMAP, right now.
If it gets diritied, it's better to submit it.
Because you can't know what you've modified inside it.
CHANCE: Right.
Yeah.
And I think that talking to a couple of the folks
on the gameplay team and core, they're like,
yeah, there's a lot of assumptions that
have been made over the 20 years of working in UMAPs,
that we probably have to rethink now
going forward as we move to this system for UE5 and other maps.
We can probably get a little bit more surgical
with hey, these are the areas we care about inside that big data
blob, versus over here, these things
are pretty safe to just go ahead and ignore.
JEAN-FRANCOIS: Yeah.
But normally with one file per Actor,
there is a lot less scenarios where
you need to submit to the UMAP file, right?
It's only if you change the world setting.
The world setting is not using one file per Actor.
And then I think that's about it.
Normally you can go days and days without changing the UMAP.
CHANCE: Even the data layers
option is not a UMAP, right?
JEAN-FRANCOIS: It's an Actor.
Just for each the one file per Actors, yes.
CHANCE: That's great.
JEAN-FRANCOIS: And adding data layers,
moving data layers, it's all just checking out
the data layer Actor.
We could have done one Actor per data layer
to really minimize the impact, but we decided just not
go to wide at first.
CHANCE: And it might be important to know
on that, too, the Actor itself is the thing that
saved in external Actors.
What data layers that's associated with it,
it's just more metadata on that Actor, right?
It's not a duplicate version of it or something?
JEAN-FRANCOIS: No.
It's just using the internal name of the data layer to work.
So if you delete the data layer, you
don't need to save all the Actors that
are part of that data layer.
They would just discover that this data layer is
gone when you load these Actors, and that doesn't ever
dirty the Actor.
CHANCE: That's great.
JEAN-FRANCOIS: Then we've converted several systems
to work with World Partition.
Landscape was the first one.
So landscape support that is done
by automatically splitting the landscape
proxies on to the grid.
And then you cannot paint when you try to paint
on the boundary that shares a boundary with an unloaded cell,
because it has repercussions on the normal maps of the other
cell and things like that.
So the paint tool will become red,
and it tells the user you need to load
that specific part before.
CHANCE: And that's just an edit time, right?
JEAN-FRANCOIS: Exactly.
CHANCE: Yeah.
So you're not saying that we would have foliage up
to the lines and then move to the next one
and foliage up to the lines.
You just need to load the edges as you're moving past the space
that you're currently working in.
JEAN-FRANCOIS: Exactly.
And we've thought about having automatic loading.
So it's the same thing for foliage, you speak about it.
So foliage you just paint Actors in the map,
and when you arrive at the point where
you're trying to paint on the cell that is not loaded,
it's just going to stop scattering foliage instances.
And the foliage tool has been adapted,
so it creates one foliage Actor per editor cell.
So as long as you paint inside one editor cell,
you're not going to create contention with another one.
So if you're painting a cell and I'm painting a cell,
I cannot start painting on your cell because you will have that
Actor checked out.
CHANCE: Got it.
So the landscape cell is one Actor itself.
As is the foliage and everything, and the painting--
everything that goes on it is considered-- that slice of cake
is protected as you're decorating it.
JEAN-FRANCOIS: Exactly.
So it's one Actor containing one instanced static mesh
component, and all the foliage instances just go in there.
So before, it was a one foliage Actor per level.
CHANCE: Right.
Yeah.
JEAN-FRANCOIS: We had to do something.
Then [AUDIO OUT] multiplayer has been adapted.
So we have data layer support so the server can activate
the activated data layers.
One thing is that the server will build the entire world.
There's no solution for that yet.
One solution would be to have streaming on the server,
based on all the players' position,
but that introduces a problem with persistence.
So let's say you destroy a house in Fortnite, for example,
and then you just move away.
The server unloads that part, and then you come back,
it loads back.
So we need to have some kind of persistence.
And normally persistence like that
is handled with the server loading everything.
CHANCE: Right.
JEAN-FRANCOIS: So for 5.0, the server
will load the whole world.
And we also adapted NavMesh.
Generating NavMesh needed to have the whole world loaded,
so it's not possible with World Partition,
because you can have a very, very large world.
So the NavMesh generation has been
adapted to load partially the world,
and go through every editor cells,
and generate part of the NavMesh,
and do stitching to the final NavMesh at the end.
CHANCE: I see.
And that works with the hierarchy, as well too, right?
Does that match how those are broken up,
or is it more at the high level?
JEAN-FRANCOIS: No, no.
Because these are loading editor cells.
CHANCE: Oh, editor cells.
I see, I see.
Got it, got it, got it, got it.
JEAN-FRANCOIS: I think that would be a common problem
to address, the difference between editor
cells and streaming cells.
It's something that we have to wrap our heads around.
Yeah.
CHANCE: They're serving a little bit of different needs.
And so yeah, it makes total sense.
JEAN-FRANCOIS DUBE: And something
that is not done in static lighting.
It's planned for 5.0.
We have a plan for that, but it's not done yet.
CHANCE: Ah, OK.
Super cool.
JEAN-FRANCOIS: And one last slide
about enabling and converting to World Partition.
So to enable World Partition, you
need to go into the Project Settings
and enable the World Partition checkbox here.
It's not going to do anything at that point.
What it's going to do is that if you create a new level
from the File menu, if you go File, New Level,
and you choose a template, it's going to automatically create
a partition world for that.
So it's going to enable one file per Actor, set up
the grid with default values and things like that.
So you can even create a new world from a template,
place some Actors.
Don't save, just press PIE, and you can tweak the grid setting.
Press PIE and everything works without saving anything.
And that's because unsaved Actors are not
streaming from disk in PIE, they are
duplicated to keep the changes that you did.
And opening a non-partitioned world when this setting is set,
it's going to ask for a conversion.
So it's going to ask every time, Do
you want to convert that level.
Conversion is done through commandlet.
So essentially the commandlet would just
gather all Actors from our sublevels,
migrate them [AUDIO OUT] persistent level,
and enable one file per Actor on all of these Actors.
And it's going to open for delete all the sublevels that
were there before.
It's creating a complete change list of the conversion process.
Yeah
So we make everything we can to make the conversion process as
easy as possible.
For instance, Actors coming from Always Loaded sublevels
would be automatically set as Always Loaded
for grid placement.
Existing layers are converted to editor-only data layers.
And the conversion process can happen in place,
or it can create like a sidecar file so you can do comparisons.
Because we don't expect big--
licenses that have big games, we don't
expect them to run the conversion process,
and 100% convert it and everything works fine, right?
We expect them to at least run a couple of times
and make tweaks to the config file,
and even probably write some code
to handle specific case for their project.
So having a sidecar file to be able to load
the original world, and then load the converted world
and do some comparison is essential in this case.
CHANCE: Yeah, it seems helpful.
Yeah, I assume if you're making changes
from a map or a stack of maps that's
got some Blueprint sublevel streaming code,
you're going to want to make sure that works with this.
I'm assuming that you don't need to stream those things anymore.
So if you're going to be moving those things into data layers,
you just would want to change out your Blueprint functions
from stream this level, and instead
say, oh, make these data layers active for these location,
or the whole thing.
JEAN-FRANCOIS: Exactly so.
You have two options in there, so you
can change your source data and then run the commandlet.
Or you can modify the commandlet code.
It's done in such a way that you can
create your own class of conversion,
and override the function.
So you can write specific code to convert
your own specific cases.
CHANCE: Oh, that's nice.
JEAN-FRANCOIS: So internally we--
at first, we tried to convert Fornite,
just as an internal process.
So we have a specific content that
derives from Engine 1, which handles all the specifics
of how the data is set up.
CHANCE: Right.
Every game, especially bigger games that have bigger spaces,
are going to have probably very different needs.
Because everyone's trying to do something just marginally
different from the next at best, and wildly different at worst,
right?
JEAN-FRANCOIS: Yeah.
So we really expect them to write
code and overload the World Partition convert command.
CHANCE: It's nice though for those
that aren't super complex.
I'm sure a lot of folks that are dialing in
have got smaller games, or games that
don't have maps that have really convoluted level streaming
codes set up in there.
Or they just have a bunch of UE4 games
they want to try to test on the new systems,
they want to move their projects up.
It seems that there's a pretty good path for them to do that.
I think when we did our map, it was just a couple
of days of trial and error.
And we already had a lot of stuff in the space, right?
We were trying a few things before we moved over
to World Partition.
So cool.
JEAN-FRANCOIS: And the best scenario
is for teams that are using World Composition with all
their levels [AUDIO OUT] distance-based stream.
Because that's essentially what we
are doing, but at an Actor level.
So converting these levels is will
be easier for teams that are using World Composition.
CHANCE: Right.
Because their code is basically doing very similar things,
as opposed to some patchwork trickery.
JEAN-FRANCOIS: Exactly.
But it doesn't mean that they don't
have streaming levels of volumes,
or Blueprints that triggers loading.
CHANCE: Sure.
JEAN-FRANCOIS: So yeah, that's it for the presentation.
CHANCE: That's great.
JEAN-FRANCOIS: I will switch to the Unreal editor.
So that's how it looks like when you start the game--
not start the game, but load the map in the editor.
There was nothing loaded, right?
Only backdrops and things that were specifically
marked as Always Loaded.
CHANCE: This is all considered persistent level
for those that are thinking in the non-World Partition terms.
This is basically everything that lives at that UMAP level
as it is, at that highest most level of the cell.
OK.
JEAN-FRANCOIS: That's a good thing
to mention, because in a cook build,
that we just move all these Actors directly
into the persistent level.
CHANCE: OK.
Yeah.
JEAN-FRANCOIS: So I don't need to load anything
from the minimap.
I can just hit PIE.
Because there's a complete disconnection
between what's loaded inside the editor,
and what's loaded in PIE, right?
Because it's using the grid settings
to generate the settings.
So as you can see I can load the map and start droning,
and I didn't even load anything.
CHANCE: Right, yeah.
The editor still has nothing in it.
JEAN-FRANCOIS: Exactly.
So we have some debug views.
If we enable this one, toggle draw runtime
hash 2D, which shows the actual loading of the grid.
If I move, you can see that we have a streaming source that
is still on the player right now, to keep things loaded.
So I can just go back instantly.
So if I go back.
CHANCE: Just the X button, I think.
JEAN-FRANCOIS: Yeah, so everything stays loaded.
So I'm just going to show playing with the grid--
CHANCE: And the two you see here, one of these
is the camera that you saw, just while she was sitting there.
And the other one was her, right?
So you can see that there's still two, OK.
JEAN-FRANCOIS: Yes.
Yeah.
And she's always loaded.
CHANCE: Yeah.
Floating around.
JEAN-FRANCOIS: So I can go here into the runtime hash grid
settings, and I can just say instead of having 32 cells,
switch them to 64 just as a test.
Pur 32 meters for the loading range, and just sit PIE again.
And this is something that wasn't possible with UE4.
You had to completely move your Actors through--
a complete different set of Actors.
So you can see right now that the cells are bigger,
and the loading range is very small, right?
CHANCE: Yeah.
JEAN-FRANCOIS: Just-- Oops, sorry.
CHANCE: It'll also probably really show it off,
what's going on.
JEAN-FRANCOIS: So that again,
I just stopped by PIE by error.
CHANCE: You hit Escape?
JEAN-FRANCOIS: Yes.
CHANCE: That's the first thing I do,
is rebind that to Shift Escape or something,
because I push it all the time.
I'm like, why'd I do this?
JEAN-FRANCOIS: So in this case,
the loading radius is 32 meters instead of 64.
So it means that after 32 meters,
it's the visual representation of the instanced HLOD layer.
So there's no physics after 32 meters, there is no gameplay elements
JEAN-FRANCOIS: --things like that.
So I can disable HLOD, just for us to see.
CHANCE: Yeah, I don't know if we
had mentioned the HLOD disable.
There's a bunch of really great commandlets
that'll allow you to actually show what's going on.
This is great.
This is a really great debug tool
that we were using to figure out what was going on,
numerous times in building the project.
JEAN-FRANCOIS: Yes.
And we plan to add different views with coloring.
So we want to have a coloring view that
shows all the different HLOD layers, for instance, so you
will see the bending of each layer with different colors.
Have different colors for data layers.
Have different colors, also, for the grid promotion.
You can do with your object has been promoted to a very--
CHANCE: Oh, a different version.
Yeah, yeah, yeah, very cool.
JEAN-FRANCOIS: So that that's
how it looks like without HLOD.
So you can see that this one big object that just appeared
has been probably moved into a higher level cell.
CHANCE: Right.
Which would explain, too, some of the holes
you'll see in this-- we were talking about this right
before this-- the holes you'll see in this graph
doesn't mean that there's nothing in that space.
That just means that the Actors that are filling that space
are either origined or bounded right outside of that,
or they're in one of the hierarchy layers.
So you'll see them load up whenever appropriate.
JEAN-FRANCOIS: Exactly.
Yeah.
OK, so I'm just going to go inside of this World Partition
view and I'm going to load some cells.
So just select some cells and click load.
And then going to do something.
CHANCE: We have a ton of stuff in those four cells.
It's so dense right there.
JEAN-FRANCOIS: It's the most dense parts.
OK.
So we have a debug view in the grid
that helps you seeing the runtime grid cells.
So if you activate Preview Grids here, into the Grid Settings,
you have the actual grid at runtime--
CHANCE: That's so nice.
JEAN-FRANCOIS DUBE: --an overlay.
So it can help you debug stuff.
Let's say I select this Actor.
So by the size of this Actor, you
can tell that it's going to end up
in a single cell, because its grid placement is
set to location.
And it doesn't cover a huge part of the map, right?
But if you see something like this one,
probably that this one is going to be promoted
to one layer on top, because it's
going to end up in that level here that
is highlighted by my mouse.
Right?
CHANCE: Yeah.
JEAN-FRANCOIS: And if you really wanted to use bounds,
as I said before, you can just switch its grid placement here
to use bounds.
CHANCE: And then it'll just basically-- any cell
that that sneaks into, it will promote itself
all the way up to make sure it's in the appropriate one.
So any time--
Great.
That is super helpful.
I didn't actually use this much for this,
because I think that you were in here poking around and making
some of these changes with us as well.
But that's a great tool, especially if you're not--
figuring out why your geometry is not--
or anything is not where it needs to be,
being able to flip that and take a look at things
very specifically is probably a huge, huge boon for efficiency.
JEAN-FRANCOIS: Yeah, it's just the beginning
of debugging tools.
Because we have a ton of debugging tools
that we want to write.
We want have a heat map similar to this view here,
but a heat map with, let's say, how the memory taken by cells,
or we could even have some [AUDIO OUT] cell
or things like that.
And other coloring debug views, as I said before.
So that would be great improvements
to this basic debugging view.
So if you change your--
let's say that I want to test with 120 meters,
you can see directly the change in the map.
So you can tweak your value here, and see directly
the effect, and figure out what is going on with these objects
and how it would be distributed in the grid and things
like that.
Another thing, I just want to--
I'm going to pop up this one here so I have a better view.
So that's the minimap that is rendered
with the HLOD generation.
If you select an Actor in there, it's
going to show the bounding volume of that Actor
inside the editor cells.
CHANCE: Oh, yeah.
JEAN-FRANCOIS: It's great for you select an Actor,
you click Focus Selection, and then you can say,
OK, it's there, it's in these cells.
CHANCE: Yeah.
Those on the stream, the compression
might be squashing that a little bit,
but there's a nice sharp yellow bounds
square that's being drawn on the minimap there.
So you can see that just sneaking just outside
of those two into two others.
JEAN-FRANCOIS: Yeah.
And then one thing that you will notice
that was not there before is that the world outliner can
show now unloaded Actors
CHANCE: Oh, nice.
JEAN-FRANCOIS: So if you need
to work with that specific Actor,
you can just click on it.
You can click on Focus Actor Bounds,
and it's going to move directly where is it,
where it is in the map, right?
So in that case, you would expect it to be loaded,
but it's not.
It's there in the map, it's part of one of the loaded editor
cells, but it's not there.
So it's probably in the data layer.
So you can right click on it and say Load Unloaded Actor.
So it's going to load it.
So I just have to find it somewhere.
Oh, what is it called?
I'll just take another example.
Take High 50-- OK, so it was called High 62.
So if I take a look at the Actor and go into its data layers--
OK.
So it's part of the data layer Campfire Replace.
It's not a good example.
It must be there somewhere.
But I was just meaning that sometimes you
can just click focus on that Actor and it's not there--
It's still going to focus on the good Actor,
but it doesn't mean that it's loaded or not.
Yeah.
Because of-- so you can inspect all the data layers per Actor
here, going through there.
But can also just go into the data layer.
CHANCE: And Actors can be associated
with more than one data layer?
JEAN-FRANCOIS: Yes.
CHANCE: So if you were going
to switch from one to the other, but you
need some things to stay persistent,
you don't need a third data layer
that's that persistent layer.
You can just keep it in both and toggle between those two,
and that Actor stays where it's supposed to be.
JEAN-FRANCOIS: Exact.
CHANCE: That's nice, OK.
JEAN-FRANCOIS: Yeah.
So it's going to generate a specific sublevel for the Actor
that is inside two data layers.
Because if we need to load that independently,
when you activate one or the other,
we need to move all these Actors that
are parts of several data layers into their own sublevels.
But it's all done under the hood when you working with PIE or--
CHANCE: I don't have to think about it as a level
designer or something.
I can just say this is this version of the map that I'm
trying-- or this version of this space that I care about,
and this is this version of the space I care about.
This Actor might be the same in both.
I don't need to worry about what's
happening with sublevels or streaming or anything
like that.
JEAN-FRANCOIS: Yeah.
CHANCE: Great.
JEAN-FRANCOIS: So that's the data layer view.
If I go here and I want to work on the Dark World part,
I can just first unload this one.
So it's really going to unload that part of the world,
and that's why it's asking me if I want to save.
Because I changed an Actor, so if I unload that part
it's going to unload that Actor.
And it's asking me if I want to save that Actor or not.
Because I'm going to lose my changes--
CHANCE: It's basically like closing the level, right?
Or that level, that sublevel.
Got it.
JEAN-FRANCOIS: Yeah.
It's the same behavior.
So I just go, don't save.
That's going to unload--
CHANCE: And again, this is so nice.
Because if I actually touch something I'm like,
I don't know if I can--
I don't know if I should save this or not.
I'll at least know, oh I didn't touch
that [? buit, ?] revert that.
Galen will be mad at me if I don't.
JEAN-FRANCOIS: And then I can activate the Dark World,
which is going to load Actors that are parts of the cells
that I had already loaded.
And they're loaded inside.
We can also just double the visibility,
if you just want to switch--
if you happen to load both, because you can load both.
Yeah, so I'm just loading it.
Again, the most dense part of the world.
CHANCE: Yes.
Yeah, this is something we did quite a bit
when trying to understand what it would feel switching
between things, making sure that things are spatially aligned.
Some of the machines we have here with a ton more memory
and whatnot, we were able to load everything
all at once, all of it.
Both worlds, even before we done any optimization,
and just used those toggles there,
just to make sure everything was aligned right.
And then we would unload the thing
when we don't need it anymore.
JEAN-FRANCOIS: Yeah.
So we can activate them, just switch their visibility
without having to go through the burden of loading
and unloading.
CHANCE: And that's just the same behavior
as activating or deactivating layers in the old maps,
correct?
That's just turning visibility on those Actors off.
JEAN-FRANCOIS: Exactly, yeah.
CHANCE: That's cool.
JEAN-FRANCOIS: Yeah, so there
are several settings in the data layers.
So all these data layers settings
are persistent per user, so when you close the editor it saves.
So if you close the editor with the Dark World not loaded,
it's not going to be loaded the next time you load the level.
But if you work on the Dark World setting,
so you visually disable this one and load this one,
the next time you load the editor it's
going to be at the same state as you were before.
CHANCE: Right.
And--
JEAN-FRANCOIS: Go ahead.
CHANCE: I was just going to say
it's super nice for the way we had things split up.
Because we broke the map up for set
dressers to have their areas.
And so they're not having to turn stuff
off and go to the right spot to turn stuff back on.
And then also data layers as well, not just
the partitions but data layers as well,
we had a completely separate team
working on different parts of those as well.
So everybody when they load the editor,
had a completely different map experience
that's catered specifically to what they were working on.
JEAN-FRANCOIS DUBE: Yes, exactly.
And there is another thing.
So the World Partition cells also are saved per user.
So when you load the map that you just
load the last of the cells that you--
it's just to make sure that when you put up the editor,
it's the last state that you were in before.
CHANCE: Yeah.
The last thing you want is to load the map and someone
has loaded a whole bunch of new stuff
in there that you're not expecting to have to open,
and it taking a lifetime.
JEAN-FRANCOIS: Exactly, exactly.
Yeah.
But there is always the case where
someone will load the entire world, and it's going to crash.
And then you cannot load the editor anymore,
because it's always trying to load this.
So it happened during Ancient World development.
So we just decided to at least save--
that's thing when you properly close the editor.
So if you crash, it's not going to be saved.
CHANCE: Great.
Yeah, so it's only been successful shutdowns,
not I think abnormal shutdowns is what they're called in code.
Aptly named.
JEAN-FRANCOIS: Then just a quick overview
of the HLOD setups.
So if you go in the World Settings
under the World Partition setup, you
have the HLOD layer, which is there.
So in Ancient World, there's only one HLOD layer
and it's always loaded.
But just for the sake of showing it.
So you can disable Always Loaded here.
And you can tweak the loading range here.
So you can say I want HLOD layer to be 256 by 256 meters cell
size, and that's the loading range.
And then you choose between instancing and different types
of mesh merging and mesh simplifications.
And then if you want to have another layer-- let's
say that we want to have another layer, which is a merged
version of the world, we could just
go here, create a new layer, save it here.
And then just say, OK, I want to be [AUDIO OUT]
simplified version.
This is going to use this one, because this one is its child.
So this one is set as its parent.
And it's going to use the child layer to generate a simplified
mesh with a cell size of, let's say,
one kilometer wide and the loading range of--
or always loaded, if that's what we want.
And then we just save that, and it's done.
We just wait for the next HLOD generation.
It's going to be there.
CHANCE: That's great.
Yeah, lots of little knobs in here
to play with when you're testing and trying to make sure things
are loading appropriately, both with your native geo that's
in here, and the actual HLOD versions, cell size,
everything.
And again that'll be very--
that'll be determined almost exactly by what your game is
and what content you might need.
Say if this had a bunch of buildings and streets,
there's a lot that we wouldn't need to load necessarily,
unless you could get above those, right?
And so we would probably have different HLOD settings,
different things we could get away with loading, cell size
and whatnot.
JEAN-FRANCOIS: You would have a data layer,
let's say, for rooftops and things
that you would just enable when you go into a chopper
or something like that.
CHANCE: Right, right, right.
Yeah.
JEAN-FRANCOIS: And then I think that's it.
CHANCE: That's great.
JEAN-FRANCOIS: Yeah.
Just something to mention, one plan
that we have is to show HLOD directly into the editor also.
So instead of showing empty space for unloaded areas,
we would display HLODs directly inside the editor.
So one step further would be to completely remove the need
to load the cells there, and just use cameras remaining
directly inside the editor.
So that's--
CHANCE: Oh, that would be nice.
JEAN-FRANCOIS: That's a far-fetched goal
that's on our track.
And this is the dream that we want to achieve,
is to be able to just navigate in the editor,
seeing HLOD and having automatic streaming.
And remove the minimap.
CHANCE: Yeah, no.
That's fantastic.
Well, it's super cool.
VICTOR: Yeah.
CHANCE: Thanks for sharing everything there.
I mean, I've been working with the tools for a little bit
and I've learned a handful of things
that I didn't find out working with you on this, or just
by nature of poking around.
So really appreciate it.
Lots of really good information in there.
Thanks JF.
JEAN-FRANCOIS: Thanks.
VICTOR: Ready for some questions?
JEAN-FRANCOIS: Yes.
CHANCE: I think we have numerous.
VICTOR: Sure do.
Kick it off, I think it will be-- since today's topics were
fairly concise on just world-building,
we'll just dive right in and shoot them
off one at a time here, for the stuff
that you haven't already addressed.
First question comes from Sergio Free,
who's wondering will data layers be
available for non-World Partition levels?
JEAN-FRANCOIS: The answer is no.
It's really developed on top of World Partition.
So it's leveraging the fact that it generates sublevels directly
at cook time.
So it's really a feature of World Partition.
CHANCE: Yeah.
I think if you can't move to World Partition for whatever
reason, you would probably still just use the sublevel model.
JEAN-FRANCOIS DUBE: Yes, exactly.
And at some point every level on Unreal will be partitioned.
VICTOR: Next question comes from UE5 Project Storm,
who is wondering what are the default world size limitations
for World Partition?
In UE4, it was 20 by 20 kilometers.
JEAN-FRANCOIS: Yes.
So it's the same limitations.
We have some development in flight
to be able to enable larger worlds.
But right now it's the same limitation as before.
But there are something ongoing to be
able to support hundreds and hundreds of kilometers
away from the origin.
Yes.
VICTOR: There has been several questions in regards
to a different landscape solution.
Several people are wondering if there's
any work in regards to landscape to be able to make it work
better with World Partition, real time virtual textures,
Nanite, et cetera.
Do we have anything to share there?
JEAN-FRANCOIS: Yes.
So World Partition has direct support for landscape,
as I mentioned before.
So landscape proxies are directly created on the grid,
so you can partially load the landscape inside the editor
and work from there.
But I cannot answer for Nanite.
There is no Nanite support for landscape.
But does the future [AUDIO OUT] that
will have support [AUDIO OUT] I don't know.
CHANCE: I've got one here that says HLODs and landscapes,
from Carlos Pures.
He says how is it possible to see far tiles with high HLODs
in an open world with World Partition.
I think you answered.
That you'll have maybe some of your [? buits ?] and big stuff
that you could never get close to always loaded.
And then your HLOD will be at some layer that will populate
all that space out right.
JEAN-FRANCOIS: Yeah, exactly.
So normally you would set up your HLOD layers hierarchy,
have a final layer that is always, right?
So it's a layer that is always loaded.
It's the most simplified one, so it should take less memory.
Unless you have a game with fog or something
like that you can hide very far away objects.
But I don't know if the question was specifically
about landscape, but we don't have landscape support
for HLODs currently.
But this is planned.
This is not in the early access.
VICTOR: That was--
a couple were asking that.
So thank you for addressing that.
On the same note in regards to being able to see objects
in the far distance, someone was wondering here
if you have a game such as a sniper game
and you want to look really far, does that
involve similar techniques that you
were talking about, teleporting where you want
to manually load those areas?
Or what does that look like?
JEAN-FRANCOIS: Yeah, so that's
a common problem, sniping to a part of the world that
is not fully loaded.
It means that you need to load, right?
So if you know in advance that you're
going to start to snipe there, like for a scripted sequence
or something like that, you can have a streaming source placed
there and make sure that everything is streamed
before you zoom in.
But if the player can zoom in at any time at any far distance,
that's an unaddressed problem.
Yeah.
You have to figure out ways to hide the fact that you're
zooming into HLODs.
CHANCE: Yeah.
JEAN-FRANCOIS: It's a common problem
between games that has snipers.
CHANCE: Potentially creative content solutions
there, too.
Some combination, I think, of being
able to pre-fetch some of the information, maybe
some smart work with HLODs and how you build them.
And then, yeah, content.
So tricky.
JEAN-FRANCOIS: But even if you
zoom in a part that is not loaded,
so not supposed to have replicated players there.
So normally you're not supposed to see gameplay elements there,
also.
So it really depends on the game.
Maybe a game with a sniper that can
snipe at the distance of one kilometer
will have its main loading range set to one kilometer.
CHANCE: One kilometer.
Yeah.
It comes down to where do you spend your budget?
What's most important for your game?
VICTOR: Another question is
from Charles Cox, who is wondering will Unreal Engine's
water body system work with World Partitioning?
JEAN-FRANCOIS: Yes.
So the new water system that we're currently developing
is currently going under work to support World Partition.
It's not there in the early access,
but it's planned to be there in the initial 5.0.
CHANCE: Cool.
VICTOR: Chance, did you have one?
CHANCE: No.
I'm digging-- there's a very dense document of questions.
VICTOR: I've been trying to make some space, since you
asked me for that, or you've been doing it earlier.
So in general, we've seen a lot of questions in regards
to World Partition, and I guess UE5 in general
when it comes to large worlds and multiplayer.
Moss306 here specifically was wondering will World Partition
work with listen server's and clients,
or just dedicated servers like World Composition?
JEAN-FRANCOIS: Yes, so it works with listen servers.
The thing is that the server needs to load everything.
VICTOR: Everything, OK.
JEAN-FRANCOIS: The most common case
will be running servers on dedicated machines that can
afford to load the whole world.
It really depends on the game and how
the servers, and on which machine the server runs.
But in future releases, we plan to have server streaming,
and have a persistent system on the server that
would be able to at least get objects back to their states
before the cells were unloaded.
VICTOR: So that would allow for single shard,
but with individual cells loaded depending on where players are?
JEAN-FRANCOIS DUBE: Exactly, yes.
VICTOR: OK.
That's super exciting.
CHANCE: I've got one here.
Because I think I've asked you this, JF, but in the past.
What do the debug colors mean when
you're looking at the cells, whether it be runtime--
there's greens, there's reds, there's purples, there's blues,
there's light blues.
JEAN-FRANCOIS: So I don't know all of them,
but I know that green is loaded, red
is unloaded but waiting for garbage collection
to ascend and unload all this stuff.
Purple means that the level is currently being unloaded,
but it's not on--
because it's an iterative process over several frames.
So purple it means it's in the process
of being unloaded and red it's unloaded
but waiting for garbage collection.
Yeah.
CHANCE: Yeah.
It's all happening asynchronously.
So there's varying states between just on and off.
And I think, too--
Oh, go ahead.
JEAN-FRANCOIS: No, I just said yes
to what you were saying.
CHANCE: Oh, great.
And I think, too, there's a really good something--
I can't remember who won the open world team mentioned this
to me, but it helped me so much understanding what's
going on behind the scenes.
Stat Levels is a great command that just tells you everything
that's trying to load.
Just stat space levels, the same way
you would do stat units, stat fps, stat GPU, or anything
like that.
It'll list out all the individual cells
with their data layer hash and everything.
And it's the same kind of thing.
Green means loaded, light blue means loaded not visible
or something like that.
And so you can watch--
JEAN-FRANCOIS: It's even written
at the right of the level name, if it's loading, unloading.
It's written in there.
CHANCE: Yeah, it's written in there.
Yeah.
So if you do a stat levels while you're moving around and doing
stuff, not just in the hash view,
you can see the state of the layers
below you and what they're doing-- or the cells below you,
and what you're doing, and what data layer
itself is actually doing.
So one thing we did for Valley of the Ancient early on was we
were testing pre-fetching the entire Dark World
to see if we could fit all that into memory so the transition
could be a lot shorter.
We actually ended up shipping with that disabled just
because the first time you load the editor,
it was going through the turn of trying to get everything
loaded into memory.
So you hit Play in editor and it's like a slide show
for the first few seconds.
So we didn't really want to do that.
There's a way you can do that, I think,
that's in the game mode script.
We do a pre-fetcher, maybe, in the Level Blueprint.
But that's a really great way to know,
oh, everything is ready to go.
Especially if you're using Blueprints
to query the state of things.
You can match what you see in stat levels with what
your Blueprints are telling you is actually loaded,
to make sure everything is set up appropriately.
We used that heavily.
Yeah, anyway, sorry.
Just on the debug topic, I figured I'd mention it.
JEAN-FRANCOIS: And just to get back to the stat levels
that you just mentioned, it's a good way
to see how much levels are generated.
So you can go in PIE, use stat levels
and you will see maybe 100 levels in flight
and currently loading.
And then you change your grid settings, double
the size of the cells, and then you
can see the direct impact on the number
of levels that are loaded.
And it's like four times less, just by doubling
the number of cells.
So you can see the impact of changing the grid
settings directly.
CHANCE: Very, very helpful tool.
Very helpful tool.
All right, back to--
VICTOR: We have two more questions.
I think you just discussed a little bit,
but these two questions comes from Rodolfo Pasadi.
The first one was what tools does
UE5 have to monitor amount of data being streamed
per data layer and grid?
JEAN-FRANCOIS: Apart from stat levels,
we don't have tools right now to monitor these.
But as I said before, we want to have
heat map [AUDIO OUT] will show the amount of data per cell.
So it's going to be a heat map--
or the runtime cells, not the editor cells, obviously.
All of these tools are currently in the thought process.
So there is nothing done yet.
So yeah, that's in flight.
VICTOR: And then the next question
from Rodolfo is will there be support for data layers
within data layers, or groups?
JEAN-FRANCOIS: Yes, this is something
that we've talked about.
So I think a hierarchy of data layers,
so if you activate a top level data layer,
it's going to activate all the sub-data layers.
That's something that we've talked about.
Because the need has come up for some internal project.
So yes.
We are still going through the thought process
of how it would look like, and how it would be to the user
to understand how things are organized.
But yes.
CHANCE: Let's see, I've got a good one here.
We touched on this earlier.
But from Tyler, having the ability to change grid size
is great, but is there a sweet spot
where changing out numbers outside of the defaults
are likely to be less performant.
And I think the answer is depends on your game,
depends on your platform, depends on numerous things that
are important to you.
But I think the defaults are pretty
good just to poke around, as a good starting point.
Is that right, JF?
JEAN-FRANCOIS: So the defaults
should be fine for most testings.
But if you have a game that is very dense,
or a game that has very dense areas and then
some areas that are very sparse, you will have to tweak
and will probably have to make two grid [AUDIO OUT]
really different.
Each game is different.
One thing to mention is that the loading range is dynamic.
So in game you can change the loading range dynamically.
So let's say that you have some places in the map
that you want to have a bigger loading range,
and then you enter a city.
You can just lower the loading range
to get some memory back, because you're streaming more dense--
CHANCE: Right.
I didn't know that.
So that's great.
So if you have a city that goes out into an expanse,
like our Moab desert, you could have
it small for when you don't see the things
in the super far distance.
Because everything here is really dense,
you have a ton of stuff you're trying to load in,
there's so much in memory at the same time,
and it's all close to you.
So you don't really care about anything outside of that,
and you get really, really, really detailed in those spots.
But maybe you enter a volume on one side
and you're looking a specific direction, Blueprint logic that
says, OK, when you're here, we can make the loading
radius a lot bigger.
You're going to be walking out this way,
you drive a car out that-- unload everything behind you
and everything in front of you is loading in,
because you can see it all.
That's great.
VICTOR: Had another question from Loresh here,
who's wondering what happens with these one Actor per cell
setups if you need to change the editor's cell size later on?
JEAN-FRANCOIS: OK.
So editor cell size is really a helper.
Because when you select cells in the editor to load,
it's actually just doing an intersection
between the bounding box of the cells and the Actors.
So you can change that value as much as you want.
The only thing is that you probably
have to just reboot the editor.
There is nothing that is tied to editor runtime cell--
editor [AUDIO OUT] so you can change-- it's
not exposed, because there has been no real need
to change that.
But we could expose it, and change it,
and just restart the editor.
Everything's [AUDIO OUT]
CHANCE: Want to touch on one here,
I think we kind of mentioned earlier,
but I don't know if the question was asked this way.
So I have Simon Finney asks, how will projects transition
from World Composition to World Partition.
I mean, you talked about the transition itself
being a little bit smoother because of the way
that World Composition does streaming past a certain point.
Will the commandlet work with that too,
to move from a World Composition map setup to a World Partition
map setup?
JEAN-FRANCOIS: Yes.
So the conversion commandlet will take--
when you have a world using World Composition,
you have different layers with different streaming distances.
So what we try to do in the conversion commandlet
is to keep these distances and we create one grid [AUDIO OUT]
streaming distance that you had in your World Composition.
That that's an option.
But if we want like to respect exactly the current setup,
we do that.
And since most of the World Composition games
are set up using Tide level setups, it's easier for us
just to convert the World Composition level to World
Partition because of that.
But as I said before, if you have custom logic to stream
some sublevels or [AUDIO OUT] level streaming volumes,
you will have to address these yourself post-conversion
or during the conversion process.
VICTOR: A little bit of chatter and questions
in regards to not only horizontal World Partitioning,
but potentially vertical.
And there's a question from Roy Ossum,
who is wondering will World Partition support
3D partitions?
Can we use it for a space game?
JEAN-FRANCOIS: The answer is yes.
It's not provided in the official UE5--
the initial official UE5 release.
This will contain only one type of grid
which will be a 2D grid.
But the system is done that you can extend and write
your own grid.
So the plan is that we will provide a fully 3D solution
in the future.
So you can have a space game, for instance.
And we also want to provide grid type
to support more traditional [AUDIO OUT] based games.
So the answer is yes.
But if you need at the moment of the UE5 release,
you will need to write your own for that.
CHANCE: OK.
VICTOR: Chance, let's grab some of the questions--
I saw you started there-- from the forums,
and then we also have some from previous streams.
CHANCE: Right.
VICTOR: We tackled dedicated--
CHANCE: It's funny, the 3D one, I think,
knocked out seven or eight of the ones that--
VICTOR: Yeah, yeah it did.
[INTERPOSING VOICES]
JEAN-FRANCOIS: So there was a question
on the initial announcement, about NavMesh.
So I think the question was does NavMesh would be streamed?
So for now, NavMesh is not streamed.
I know that it's in the works from the team that
handles NavMesh, but currently the NavMesh is always loaded.
So it's generated partially using the partial loading
of the world, but it's just stitching different parts
and making one huge NavMesh for the whole world.
And normally that's the server that it's going to [AUDIO OUT]
and NavMesh doesn't make a difference.
But if you have a single player game and you want to stream
NavMesh , I don't think it's going to be there for 5.0.
But it's planned for a 5.x release.
VICTOR: It's a work in progress.
JEAN-FRANCOIS: Yes.
VICTOR: Right.
I've got one here, because this is one that I asked you,
I think, back in February.
Is it possible to get a Blueprint callback for the data
layer has finished loading?
For what we're doing in Valley of the Ancient,
you'll see, is we tell the system-- we tell a data layer
system, or the World Partition system
to load specific data layers.
And then we do a quick query based
on where our player is to look for those to be finished.
And then we have that set up on a timer.
I think I put it to something like a quarter of a second.
So that way every-- that's four times a second,
it's not wholly ticking.
But when it's done, it clears that timer.
Is there a plan to move that into--
so it's kind of like a callback, like a Blueprint event
that we can bind to?
JEAN-FRANCOIS: So this is a question that
has been asked several times.
Yes.
Yes, it's possible.
So right now you have to resort to doing polling,
as you just described.
But yes.
It's something that we plan to do.
We don't know how it's going to be--
if you would tie that to a specific Actor or just
broadcast an event.
It's not clear.
But it's something that we have on our to-do list, for sure.
CHANCE: Yeah, you'd have to have some persistent object
that you could bind to.
One of those delegates, right?
JEAN-FRANCOIS: Yes.
Unless you want to broadcast something to the level script.
CHANCE: Right, right, right.
Which you could probably do it in code right now, if you were
to dig down and write something that way,
and then broadcast that up.
JEAN-FRANCOIS: Yeah.
VICTOR: Next question comes
from Sebastian Lutz, who's wondering
is it possible to mix World Partition
with a regular streaming 4D interior,
probably for an interior building.
JEAN-FRANCOIS: Yes.
If you want to write some code for that,
it's still possible to stream sublevels.
In fact, I'm pretty sure that if you place sublevel streaming
volumes, it's going to work.
The only thing is that the level window
is disabled in World Partition, so you won't be able to add
sublevels directly to the--
but with some custom code, it's still there.
So if you have parts of your game
that you need to continue using that scheme,
you could probably work around.
CHANCE: And you wouldn't get
any of the benefits of the patching
and the loading of specific stuff,
if you just loaded your other level.
Unless it was converted, and then it's just converted,
you're not streaming it in.
JEAN-FRANCOIS: Exactly.
Yeah.
CHANCE: OK.
VICTOR: Still going through and crossing out
some of the 3D and vertical.
JEAN-FRANCOIS: I think that's the--
is it the most requested thing on the chat, or?
VICTOR: There were definitely
quite a few questions in regards to that.
But I got another one from Loresh here.
Can lightning be baked into data layers
similarly to how they can be baked into sublevels in UE4?
When it works.
JEAN-FRANCOIS: Yes.
Yes.
So when static lighting will be working,
for sure we'll have to support data layers [AUDIO OUT]
VICTOR: I think we lost you, JF.
CHANCE: You've gone muted on us.
JEAN-FRANCOIS: Am I back?
VICTOR: Yes, you are.
I did not expect that to work, all right.
JEAN-FRANCOIS: Great.
VICTOR: Fantastic.
JEAN-FRANCOIS: So yes, we would
have to support data layers for static lighting, the same way
we support data layers for HLODs.
Yes.
So if you have a dark and light version of the world
[AUDIO OUT] you will need two different versions
of the static lighting.
Yes.
VICTOR: Loresh had another question on, I think,
the same forum post.
How should-- and I like this one--
how should UE4 levels be built today to best prepare them
for a World Partition upgrade?
JEAN-FRANCOIS: Yeah so one of the main thing
is to make sure that you stream level based on distance.
So if you're using World Composition,
that's the best scenario.
And if you're using--
some games have custom code to implement
distance-based streaming directly in the game.
But if you're using volumes, streaming volumes,
make sure that they are evenly placed in the world.
Because if you rely on the fact that this part will
be loaded just from that radius, and that part
will be loaded from that radius, it's
not going to properly port to World Partition.
Yeah.
The main thing is to go away from custom code that is not
just distance-based screaming.
And don't rely on enabling and disabling levels.
Let's say that you have some part of the world that
trigger loading of a sublevel, just to do a scripted sequence
or something like that.
This will need to ported to be using data layers.
That will need to--
some custom attention during the conversion process.
CHANCE: I've got one for me in here, too.
It's a silly aside, but does Chance like blueberries?
And sometimes.
I guess blueberry muffins, maybe in a smoothie.
VICTOR: I had blueberries for breakfast.
CHANCE: Oh, that's good.
Vic likes blueberries.
VICTOR: I love blueberries.
CHANCE: I like most berries.
Most parents are pretty good.
Some of them, looking at you, blackberry.
Not a fan, you're a little outside of my taste.
VICTOR: I'm allergic to blackberries.
CHANCE: Oh yeah, don't eat those.
VICTOR: No.
I try not to.
CHANCE: They stain your clothes too.
That's my big thing.
They taste pretty good, but they stain my clothes.
I get messy.
VICTOR: Moving on.
JEAN-FRANCOIS: No, I would just saying that I
cannot eat blueberries, because the kids always eat them.
CHANCE: Yes.
VICTOR: Don't have that problem in my apartment here.
CHANCE: It's off topic, but a blueberry is--
the juice purple, the inside is green, but the skin is blue.
They're an enigma.
I don't understand.
Nothing makes any sense.
VICTOR: Aren't bananas also technically a berry,
if you're looking at it scientifically?
CHANCE: Yeah.
Would they be a yellow berry then?
All right, folks.
VICTOR: We digress?
Yes, we digress.
CHANCE: That never happens.
I think you've done a pretty good job so far, JF.
We're--
JEAN-FRANCOIS: We still have the forums.
Yeah.
VICTOR: Yeah.
For everyone who might have joined late,
missed some questions, or if you're
looking for the future livestreams,
check out the Events section in our forums.
That's where we announce all of them.
And that's where the best part to participate
in the conversation post-stream takes place.
So if you have more questions for JF,
or if you want us to clarify something, go ahead
and we'll link that in chat right now.
And you can go ahead and ask your questions there,
and we'll keep an eye on that thread.
CHANCE: Yeah.
I was going to say anybody that's
working on things in UE5, first and foremost,
we've seen all kinds of stellar stuff come out of the community
already, posted online on the forums, and whatnot.
Show us what you're working on with World Partition and some
of these new-- and data layers, one file per actor,
everything we've got in there.
If you're working on some crazy large sprawling map,
we'd love to hear about your experience there.
Some of the things you're running into,
things you thought you couldn't do that you can, or vise versa.
We're always looking to hear from you.
So yeah, just let us know.
We're excited, we're excited to get this in your hands.
JF, you've been working on this for quite some time now.
It's probably super cool to see a bunch of people
finally poking around with it.
JEAN-FRANCOIS: Yes, yes.
There's a lot of YouTube videos already, like how-tos.
How to set up World Partition and things like that.
And it's really fun to listen to these,
and see what the community will do with that.
CHANCE: Yeah, for sure.
VICTOR: Final question from Qwah here,
from the first stream.
Does World Partition still use world origin shifting?
JEAN-FRANCOIS: The answer is no.
There is no support for that.
And that's because we have another development in flight
which is to support very large worlds.
So world shifting is probably going away
with that development.
So more news to come, I guess.
VICTOR: Yeah.
Had another one good here from Mayhem Mirror.
Is World Partitioning supporting procedural levels at runtime.
And they're clarifying, for example,
streaming different sublevels per tile each time you play.
JEAN-FRANCOIS DUBE: No that's not
something-- that's something that was possible
before because you could have set up your game using
like legal tiles.
And then you just set up your streaming
to choose randomly a sublevel that fits with the one
that you want to stitch [AUDIO OUT]
and that's not something that is possible
right now, because we're just taking the whole world
and putting that into sublevels.
But I could see some extension that
could be done to support that.
But out of the box, World Partition don't support that.
CHANCE: Seems like you could probably
be very deliberate about how you set up your cells, and do
a lot of your procedural generation of content
inside Blueprints.
And it might be a little heavy-handed
to go for callbacks every time a specific cell
is loaded to generate things, but you
could pre-seed a lot of that and then put them out there.
And build larger procedural worlds
using that way, as opposed to using levels to stream them in.
JEAN-FRANCOIS DUBE: Yes, exactly.
But I guess that writing a new grid type for that would
be the best solution, I guess.
So the grid type controls everything,
how things get packed into levels,
and how things get loaded.
I think it's a mix of what you just said and a new grid type.
CHANCE: Cool, cool.
VICTOR: Well, I think that might be it then.
And I know that Chance would be very happy
if that was it, because he has a very important meeting
to go to.
CHANCE: It's all good.
This has been a great pleasure chatting with you all today.
JEAN-FRANCOIS: Same, same.
CHANCE: Super excited about this feature.
Yeah, I'm really curious to see how it changes workflows
for a lot of us that have been doing things
the standard way, which is patchwork, big quilt style,
putting stuff out in the space, rethinking it, chopping it up,
like you said.
We don't fit a memory on this console,
so we've got to change that a little bit, or we don't--
I can't see this thing from there,
so I got to make this one piece special for some reason,
and make sure that it's always there at the end of my map.
But kill it by the time I get there.
Some crazy stuff.
JEAN-FRANCOIS DUBE: I didn't talk
about having per platform grid cell size and things like that.
But that's something that we have also.
CHANCE: Oh, fantastic.
Yeah, that'll be a huge help for games
that want to deploy across numerous types
or classifications of platforms.
JEAN-FRANCOIS: Yes.
VICTOR: And I guess it's also worth
mentioning that this is early access,
and the last thing the documentation team wants to do
is to write documentation on things that
will most certainly change.
And so for 5.0, full release, and in the future
expect more documentation, samples, learning projects.
Everything that we have for UE4 right now
will be made available for UE5 as well.
It's just early days and some things are still a little bit
in flight, being worked on to make sure that they're
as good as possibly can be.
So stay tuned for that.
I did see some questions about that as well.
And you can just always expect that.
New feature that we know is impactful in the industry,
we'll probably go ahead and try to make sure
that it's easy for you to learn how to use it.
All right, well, I'm going to do my little outro spiel
and then I think we'll get going.
Appreciate everyone hanging out with us today.
JF, big special thanks to you.
I'm going to do that once again as well.
CHANCE: Yes, thank you for the presentation.
Super informative, even to me that's used the system.
So thank you.
VICTOR: And I was going--
go ahead, JF.
JEAN-FRANCOIS: I just said you're welcome.
VICTOR: I was going to say even though--
if you're experimenting with the new world building
features and you don't have anything in particular that's
super visually stunning or original,
go ahead and still share your experience.
We are very much inclined to know
what that is like, even though it might not
be the most stunning Lumen, Nanite, billions and billions
of polys going on.
We're still curious to see what your experience is.
So go ahead and post that, and tag us
on the forums or Twitter.
If you've been watching from the start,
thank you for hanging out.
If you haven't, thank you for hanging out.
I should probably add that to my little thing here.
Thanks to everyone.
We do go ahead and transcribe the livestream every week.
And so if you were curious about a particular words
we were using, or you weren't able to understand
what we were saying.
About within seven days of the time that we go offline
we do have a manual transcript that our wonderful captioneer
puts together for us.
It gets added to the YouTube VOD,
so go ahead and head over there.
You can also download that PDF and actually
go ahead and see all the timestamps when we said things.
And so if the timestamps that we add to YouTube are not enough,
you can go ahead and do a Control-F and search
for some key terms there in that document
to find when we were talking about it.
And that is true for all of our livestreams.
If you are new to Unreal Engine and you'd like to get started,
you can access it from UnrealEngine.com.
If you already have Epic Games launcher installed,
you have a tab right there for Unreal Engine.
You can ahead and download both UE4 and UE5.
Easy as said-- easy as I said it.
That's not an English expression.
Moving on.
Our meet-up groups are still throwing virtual meetings
around the world.
No physical in-person meet-ups are
happening during the pandemic.
But you can go to communities.unrealengine.com
to find those groups.
Go ahead and join them.
If you are curious about forming one of the meet-up groups,
there's a button in the top right corner
to become a leader.
You can go out and fill out that form and get in touch with us,
and we will get back to you.
As we mentioned previously all of our-- everything
that's going on in the community is exciting.
If you do want to go ahead and make sure
that you let us know what you're working on,
the forums are a good place.
We got UnrealSlackers.org is our unofficial Discord
community, as well as Facebook, Reddit, Twitter.
We might go ahead and pick one of your projects
as one of our community spotlights
that we do every week on the Livestream.
If you stream on Twitch, make sure you
use the Unreal Engine tag, as well as the game development
tag.
Those are two good ones to make sure
that you can find others that are working on content that you
might be interested in.
And make sure you follow us on social media.
Hit the notification bell on YouTube.
And prepare for next week when we're
going to have Jeremiah Grant, Aaron Cox,
as well as Kieran Ritchie on to talk about motion warping
and full-body IK.
And maybe we'll go ahead and solve
the mystery of what happened to the missing slope warping demo
that Jeremiah Grant promised during the Control Rig
livestream a couple months ago.
CHANCE: I'm just learning about this.
Yes.
VICTOR: That's next week, make sure you tune in for that.
I've been following along with some of their prep,
and they're getting ready to show off and break everything
down that was happening in the Valley of the Ancient,
and probably a lot more.
I'm going to go ahead and prep for a long stream
because last time we were hanging out
for quite some time.
With that said, once again, thank
you JF for coming on, and Chance for helping
me host the series here.
It's been a pleasure.
Anything else you'd like to leave the audience with today?
CHANCE: JF?
JEAN-FRANCOIS: Well, I guess use the system and share
what you do with it.
And post on the forums so we can iterate
on making the system better.
CHANCE: Yeah.
I'm just glad to be here.
Good to see everybody again.
It's been, what, a week now?
VICTOR: Yeah.
And you'll be back next week.
Or hopefully, I should say.
We're planning for you to be back next week.
That said, thank you both again.
And thank you all out there.
I hope you're staying safe.
Until next week, stay safe.
Fire one
JEAN-FRANCOIS: Bye.
[OUTRO MUSIC]