[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]
