>>Amanda: Hey folks, we hope
you've had a splendid week. In case you haven't heard, it is the five-year anniversary
of our Marketplace. To celebrate, get up to 50% off over 4,000 products
before September 3rd. Thank you to all of our
wonderful Marketplace creators, old and new.
Speaking of the Marketplace, it's your last chance to grab
August's feature-free content including animation sets,
magical combat systems, landscapes, footstep sounds,
and a versatile VFX system are still available
through the 31st. Don't miss out. Panache Digital Games
recently released the highly ambitious
open-world title Ancestors:
The Humankind Odyssey, which charts the evolution
of human history across 8 million years. We caught up with
the Montreal based team to see how they're
reaching for AAA quality as an indie developer,
balancing making a game that is both historically
accurate and fun, as well as how they designed
a gameplay experience with no predetermined
narrative. In the interview, they also
provide tips to developers who are thinking of
starting their own studio. In an attempt to refine
their craft, Supermassive Games set out to create
the Dark Pictures Anthology as a collection
of horror games that tackle different
genre archetypes. Building on their experience
with Until Dawn, the studio incorporated
both couch and online co-op modes
for Man of Medan. Learn how they overcame
difficult challenges to design the game's
online co-op, which is designed to sync
between two players free to explore divergent paths. Plus read about
how Man of Medan has been designed
with replayability in mind making the game the studio's
biggest branching game yet. Now onto our weekly
Karma earners. Many thanks to ClockworkOcean,
Shadowriver, MacGowss,
Max Payne_, mightyenigma, PAVI_PAVI,
T_Sumisaki, HarryHighDef. IndieGameCove, and MCX292. Thank you so much
for helping out on AnswerHub. First up on this week's
community spotlight is Lea Kronenberger's
winning entry for "The Legend of King Arthur"
ArtStation challenge. Here we have Merlin's Cave.
It's a gorgeous scene and you can get
a full scene breakdown on their challenge blog. Built entirely using Blueprints
by two developers, "We Ride" aims to find
the sweet spot between early
and modern MMORPGs. We Ride is one of the first
MMOs to be developed and funded as part of
a three-year research project, allowing the team to explore
unique features and mechanics. Last up we'd like to highlight
an Asset Cleaner tool created using the Editor
Utility Widgets. This tool scans all the Assets
in your project and lists the unused ones. This is super helpful to help
reduce project and binary size after all your iterations,
check it out on our forums. Thanks for joining us
for this week's news and community spotlight. >>Victor: Hey everyone
and welcome to the Unreal Engine
livestream. I'm your host Victor Brodin
and with me today to talk about Unreal Insights, our new performance
and profiling tool, I have invited Stefan Boberg,
our Engineering Director for Foundation calling in
from Stockholm, Sweden, and Ionut Matasaru, our Senior Engine
Programmer from Romania. Right? >>Ionut: Yeah.
>>Victor: That is correct. To start off with this, since I
don't know much about the tool, we're going to have
Stefan walk us through a little bit of his slide deck
that he is prepared for us to give us a little bit
of an introduction to what Unreal Insights
has to offer. >>Stefan: Alright.
Should we get started? >>Victor: Let's see,
I'm not sure we have audio. >>Stefan: Can you hear me? Can you hear me OK? >>Victor: I can't, sorry, I don't have any
audio in my ear. Just trying to make sure that I can hear
everyone I'm talking to. >>Stefan: Do you have audio now? >>Victor: It'll
be just a moment. There we go.
I can hear you now Stefan. >>Stefan: You can hear me?
>>Victor: Yes. >>Stefan: Excellent. I'm the Engineering Director
for the Core and the Foundation teams
and I'm based in Stockholm. I'm going to start this show by just giving a quick overview
of the work we've done. Kind of why we did it and just some super high-level
information about how it works. And then Ionut will do
the more interesting stuff, which is to show off how it
actually works in practice. Just a quick background story.
I'm relatively new to Unreal. I started at Epic
at the beginning of last year and it's a huge code base and so
when you start investigating how to solve different problems,
you get a lot of questions. In our case, one of our main
focuses right now is to optimize
loading performance. Digging into that, how that
worked, how the cooker works, which is another area
that our team owns, and more precisely,
where are we spending time during loading and well, how does everything
work in Unreal. Some of these questions
are slightly difficult to answer because it's very non-visual
stuff that's happening. It is very internal
to the Engine. We have some tools already
that provide some answers and there are external tools
that can also help understand what is happening in the Engine. But we felt like there was
an opportunity for us to improve how this works and to help us expose just more
information mostly for ourselves to help us do our work,
but it's also a great opportunity
to share these tools, make them really good and share
them back to the community to help everyone understand better what's happening,
hence insights. We want to give you insights. Super high-level goals
is just like I said earlier, we want to reveal more
of the internals to the users. It's not just intended to be
for performance and profiling, it's really designed to expose all kinds of information
to the user, but the initial focus
is performance. Our intended audience, especially now
is quite technical users. Primarily the programmers,
I would say, though others,
very technical users could probably
find them helpful. A really huge goal for us is to provide really
high-quality interactive tooling to give you really
responsive, good feedback;
respond quickly. Actually, our target,
just like with games we want to have
a super high frame rate. Our target with the tool
is to give you 60 FPS if you have
a good enough computer; give you a 60 FPS
interactive experience and also enable scaling
really large data sets. This is something
we've experienced in the past. It is when we look at something
that's taking minutes, tools might be okay, but then when you start looking
at tens of minutes or hours even when you look
at a long running process, then they can start to struggle. This is another thing that
we really want to accomplish. The other thing is that
we don't want to just do something hard coded
that only solves one problem. A big part of this
is also just making sure we have foundations for the rest
of the Engine team to extend this tool to provide more information to allow you to understand
what's happening. Another thing which is probably
more interesting to larger game studios
and larger AAA titles is to label
offline analysis, which is really common, to do reporting and
tracking performance over time, things like that. In 4.23, we have
the first release, it's a beta. It's a result of basically
three months’ work of Ionut's and then a bit more time
for some of the others but we only had time to add
CPU timing information and we have log output,
you'll see this later, and then an experimental Asset
loading panel, which we have used internally
to drive our optimization work. We currently support in 4.23
we support Windows, Linux and consoles
for tracing. The tools that
you are looking at, they are programs
you're investigating can run on these
targets right now, and the tool itself
is currently only really tested
extensively on Windows but the goal of course
is to support all targets for both of these. All
desktop targets for the tool, all our supported runtime
targets for tracing. You can also run the tools
with any Unreal program. It's not just for a game. Some tools are heavily focusing
on how concepts of frames and other things that mean
that they don't tend to work very well for other things,
for example, the Editor. Another thing which is different
compared to other tools that we have in the Engine
is that with Insights, you can actually look
at the startup of the game, for example,
to see what's taking time there. You can also analyze
the cooker and the server for example
to investigate performance. We are internally
doing just that. It's super high level. I want to explain just
roughly how it works so you'll have an idea
when you see the tool later. You'll have your game
or your program running. This Jared's events so code is just instrumented
to Jared the batch of events that we send over the network
to a recording application, which is currently
embedded in the tool, and this records
the information to files so you can look at them later but you can also look
at them live. You can use this tool
that you'll see to investigate and look at the information
in these traces. You can also run batch tools
to generate reports, et cetera. It's super easy
if you have a bit of code that you want to add. Your own code for example,
that you want to investigate. It's quite easy
just add a scope macro, which is obviously covered
in the documentation. We also cover
existing instrumentation. The classic stats annotations that we have
in the Engine also work. You can always add bookmarks
for making it easier to find things on the timeline
and Ionut will show that later. Actually, right now that's it. Hopefully it gives you
a quick overview of what we're looking at
and how that works. >>Victor:: Yeah, it's exciting. Let's see Ionut if you're able
to take over the screen share. >>Ionut: Yup.
Okay, let's do that. It's okay? The screen is showing?
It should be a black screen. Before launching
Unreal Insights, I want to tell that
in 4.23 Unreal Insights will come prebuilt.
It's a standalone application. You'll find it
in a binary folder and just easy as double-clicking
on running UnrealInsights.exe. If you have a Unreal Insights
and you want to compile it from source or as a project
in Unreal Insights, you'll find it in programs just compile it from
Visual Studio and run it. >>Victor: One moment there, I think we had a small screen
share chat hiccup. Let's see here.
That call dropped. This will take just a moment
and we will be able to get Ionut's screen
back up on our screen so that we can all see what you
are actually doing over there. Should just take a moment. Yes, we've connected
and I think we are almost back. Let me make sure I get this over
to the right window and we are good.
Alright. >>Ionut: Okay. I will start from
Unreal Insights. When you open,
you'll see the start page. The start page we have the list
of trace sessions that Unreal Insights
knows about. Each trace session corresponds
to Unreal recorded trace file that is located
in local session directory. I can browse the folders
to see the files, that will be easy if you want
to manage yourself the files cleanup or do all traces or
share it with someone else. To open analysis
for a certain trace file, just as easy
as selecting and opening the session,
I will not do this right now, or double clicking
on the trace session. You can also load an AVA file
if it is located in AVA folder. Before showing
the actual analysis, I will show how you'll create
one of the trace sessions. For that I will
start the Editor. It will take
a few seconds to start. You will see that a new
trace session has appeared and it is live so it is
producing events right now. Start it and loading
InfiltratorDemo project. A new session is created
in just a few seconds. We now have the Editor open. What I want to ensure
is I would want to play InfiltratorDemo
in my standalone application. What I want to do
is to be able to capture performance
timing events. For that I will need
to specify one command line. I'll show you immediately.
I'll go to settings, and CPU profiler trace
is a command line that I will need to specify. Enabling that will allow
tracing to trace all timing information. I will also specify
load time in trace. This is for Asset
loading events. I will show more about later but what is important
is that now if you want timing information,
you need to specify that. In the future, we want to get rid of the need
of specifying in command line and to be able
to control those events, to turn on and off these kinds
of events live directly from UI. I have that specified
and I'm starting InfiltratorDemos
a stand-alone game. You will see in the actual
session for InfiltratorDemo is the [inaudible]
one. The other ones
are still producing events and Unreal Insights is recording
those sessions as well. I'm starting the Demo; Demo will
play in the background. What I'll do, I will actually
open analysis in real time, so that will produce events.
I will go more into details of what you are seeing here
immediately after. Just to know that here
it's duration of frames. So, you'll see
frame durations. What I will do,
I will try to pull the game loop just by moving the window
a little bit. That will create a frame-- because my main loop is paused, it will create
a longer frame. And you see that spike here.
I'll do that again. I'll pause, when I release it,
you'll see again a spike here. I'll close it now. You see the two pause
that I made and at the end
some exit events. I could close also
the other ones and you see that now
the sessions are closed and I'll continue analysis for
the session that I just created. First as an overview,
we have a timing view that will show timers
per thread for each thread. We have on the right
a list of all the timers and we've aggregated statistics. We have on top the frames
with duration for both the game
and rendering frames and on the bottom,
we have a log view. I will show more details
first about the log view. Alright.
Basic functionality, log view is similar
with the one from Editor. Up here, you'll be able
to filter by text. You can filter by categories.
For example, I could hide all categories
and enable only one of them, like that. Or you can filter by threshold. That is a bit different
than filtering in the Editor because that is
an actual threshold. If you specify,
I want only from warning it will disable verbosities
lower in priority than that and to enable all the ones
above that priority. That will show
warning and after, I don't have any,
so that is good. Then I don't know if you
noticed when I click, when I selected one message
the view has tried to center on that time of
the respective log message. In this case this bookmark.
Because I see that bookmark and Stefan also mentioned
the trace bookmark macro. These bookmarks are not
actual category filter. Low categories are generated
by their respective trace macro. Those are used in timing view
to have an orientation over the bigger picture
of the session. So, if you see
those vertical lines, those corresponds all to-- each one corresponds
to a bookmark. When I selected one,
I had this one. I'm assuming, again,
if I go to the next one you see, if I just continue selection, you see that the marker
will move to the time of the
respective message. Another thing that I can do
is to make a selection. If I'm selecting one message and then keeping shift pressed
and selecting another message, the entire time between first
and second click will be selected. I'll be selecting
from time here, from time here, and that would be correlated
to selection here, Coming back on bookmarks,
again, you'll see, just zooming out
to see a lot of bookmarks. If that will be too noisy,
you can collapse the bookmarks by clicking on
the bookmarks header or by double-clicking
any bookmark track. You can also enable, instead
of showing all your bookmarks, to show the markers
for all the logs. That is currently available
as a shortcut. B will control the bookmarks
and M will control all the logs. Now you can see all the logs that are available
in the session will be also used as markers. That will be more useful
when you zoom in and you want more context
information for timing events. Coming back to bookmarks. I will just minimize
the log view. Now more about the timing view. First, each track
that you'll see here that show an icicle graphs
represents a CPU thread. The timing view
is not limited to CPU threads, but in this view currently
all tracks are CPU threads, You'll see the hierarchy
of the timing event. As an obligation, just navigate
to panning it around you just click of a mouse
and dragging the window. You'll see that
it is very responsive. To zoom in and zoom out, I'm just using scroll wheel
on the mouse. You can have an overview
of maybe you can have a one-hour session,
you can see that. And then you can zoom in
and go to things that are probably nanoseconds
in time or even smaller. In order to easily navigate
between a lot of information because sometimes you could
have hundreds of threads. In this case are probably
are not too many, but you could have
much more than that. We have a way to turn
off visibility for tracks. First you can enable-disable
all tracks at once and then you can enable
only groups of tracks based on thread groups,
on CPU thread groups. I can for example, enable only the render
threads and game thread. Another thing
that if you notice, when timing events
are going out of the view, the scope will try to collapse so we'll use the space
as best as possible. For example,
here we have a lot of space. When I'm moving that around, you'll see that
those will come together. You'll always have information
in context and close to one to another. If you don't want tracks
to be hidden when they don't have an event, you can disable that,
so that we'll see that there are additional
threads in my filter, but at this zoom level,
you don't have any timing events and those should
increase in size once the events are up here.
I'm just hiding that. When you hover the mouse over
a timing event, just like that, you see basic information
like inclusive time, which is the duration
of the timing event and the exclusive time. So, it's time minus duration
of the children events. You can also select
the timing event. When you select it,
it will start to flash. Once you select it,
you can use a keyboard to navigate between
adjacent timing events. I'm pressing left,
right, up, down arrow keys. When I press right,
I just go to the next event. And you see those. Then there are
a few smaller events here. If I press up,
it will go to a parent event. If I press down, it will go
to the largest child event to navigate between events. Because some events are larger,
some are smaller. In order to keep focus on that
you can press F key and that will frame
the view to zoom around the respective event.
So that is a long one. It will center
and computate a zoom based on the size of the event. If I'm going to a smaller one
and press F, now that smaller one is here.
Another thing that you can do, once you have a
timing event selected, you can press enter and that
will select the time range corresponding to the respective
timing event or you can just double click
a timing event and it will do the same. A little bit about frames track. As I said earlier, the frames
track shows duration of frames. Those are not on a timeline
but on an index line so there are adjacent frames
one near the other. You'll see like a bar graph. Each bar is a frame you see
both render and game frames in an overlapping mode
and when you hover mouse over them
you can identify which is which. In this case the smaller one
is render frame and the bigger one
is game frame. You notice that
some of the frames are highlighted with red. Those are highlighted
based on duration. The ones that are bigger than
43 milliseconds or corresponding to less than 40 frames
per seconds will be highlighted with red and between 40 and
60 frames per second should be highlighted
with orange greenish color. So that will be easy to spot
spikes or frames with large duration. This is useful to navigate
if you need to identify one spike
and go there. You can just click on that event and the time,
click on that frame, and the time of the
frame will be selected and the timing view will center
on the respective time range. It's easy to navigate around,
like clicking like that. This is the actual frame
that I'm clicking. This is a larger pause
that I made, nine seconds, and this should be
the second pause that I made. There is also
the white brackets. If you see here, the white
brackets shows approximately how many frames you see
in the timing view because I have different
horizontal scales. Basically, all the frames
from here are visible in all of this timing.
When I'm scrolling right, you see that the
brackets are moving. Okay, I showed that making
a selection can be done by clicking on the frames here.
You can select from the log; you can select
by selecting the timing event and pressing enter
or double-clicking timing event. You can also make
a custom selection just by clicking and dragging
on the time rulers. If I'm just doing that, we can make custom time
range selections. If you are doing the same
on the main view, it will make
a panning of the view. The selecting is just clicking
on an empty space. Every time a selection,
a time selection is made, you'll see
that aggregated statistics are updated automatically
to include statistics only for timing events
in the respective selection, Aggregated statistics that
you'll see for each time or events,
in the default view, you'll see total inclusive time
and total exclusive time, which is obvious some of all
the instances in selection. What is important is that
if you have a selection that only partially intersects
longer timing event, like in this case, this one,
only the time range that is intersecting with the
selection will be considered. In this case, this timing event
has 14 seconds, but in the four seconds
that I'm selecting is only having 2.3 seconds. That would be useful when you
make selection for big events or if you just make ad
hoc time range selection. What about the timers list? First you have that list
of all the timers. You can sort by any of
the aggregated statistics. By default, I'm sorting
by inclusive time, but I could just
sort by count; by how many instances
are in the selection. Another useful thing to know
is that statistics are also computed only for
timing events that are filtered but I couldn't filter
in the view. If you have the tracks hidden,
it will not be considered. For example, if I'm just keeping
only one track visible. Those stats will include
only what is visible now. Will not include the information
from other tracks or other CPU threads. This is in order to be able
to focus on the threads that you want to investigate.
If you want it to be included it's just as simple as you
can keep everything visible. In this case, statistics will
include timing information of all the timing events. Another thing to know is that we don't
have only inclusive and exclusive
we have more statistics. Both will be visible here. We have minimum, maximum,
average, and median values for each inclusive
and exclusive times. For example, I could reset the
view to include the more stats. Again, you can sort by
any of those columns. You can sort alphabetically;
you can search by by world. Now I will want to show you
something more about the navigation.
I could hide the views; I will just keep timing
information visible. So again, now I have
all the tracks visible, I could just enable-- Okay, everything is visible.
I have lots and lots of tracks. Again, it could be
much more than that. One way to have a better
overview over those is to press C key
which will go in a Compact mode and then we can
see things like that. You'll start to see patterns
on execution of threads. You see that at some point,
a lot of threads are, you can zoom in
and see what's happening there, you can press C again
and go in a more detailed view. You can do that
at any point in time. So, expand, collapse the view. We tried to make navigation because we try to provide
access to a lot of data. It could be millions and
millions of small timing events. Our goal was to be able to
navigate between high overview to something that is very small
nanoseconds, very, very fast and very effective
to be able to go there or where you want to go. What I'll show you a little
bit about Asset loading. Asset loading, as Stefan said,
was made more as an experiment
or something to help us. It will show that
in addition to threads, you could also have
other kinds of information; other kind of tracks. In this case game thread
is a CPU thread. It's the same CPU thread
like the one here, but loading main thread here. It's a special track
with special events related to Asset Loading. You'll see that when
I hover the mouse over that I have completely
different information. I have much more information
related to Asset loading. If you make a selection, you can have some aggregated
statistics related to, as the loading info. Again, that is just
an experiment. We'll probably need to expose
more in the future, but we'll show that
we can correlate different kinds of information. We don't want to be only
CPU timing events, if we have
any kind of information that have a timestamp, we will be able
in the future to correlate and to visualize
in the same view. I think that's
the most important things that I wanted
to show you for the tool. And I think I can show
also a glimpse of what we are working right now and things will come
in future versions. >>Victor: That sounds good. There's quite a bit there
to dig into. >>Stefan: One big thing there
that is hopefully obvious is that one of the
goals is to try and collect a lot of
different information and allow you
to look at it together. You could see a small
glimpse of that there where you can see the loading
information at the same time as some of the CPU information
and the log. To be able to correlate
different classes of information together,
to be able to analyze problems. For example, when you
have hitches, you can see, oh, it's loading a sub level and at the same time
a bunch of other things happened and this is why I'm dropping
frames in my game, for example. Yeah, and that's what
we'll be looking at here as far as just an additional
examples of that whole idea. Yeah, Ionut do you want
to show the stats? >>Ionut: Yeah, this version is
what we are working on right now,
so that will not be in 4.23. You'll see that there are
small UI improvements but what I want to show is that
we have first stats counters. Stats counters are hooking
to existing stats counters functionality
from Unreal and are tracking variation
over time of all those counters. I could make a selection
just to compute. I will sort by count
just to identify the one with-- And I will show that
when you press G key, it will show a
special track that is docked on top, but it is
correlated to the timing view. By default,
it shows frame information. It will show game
and rendering frames. I could hide those
because it’s not those I want to show
and what I will show that every variation of stats
counters could be graphed and could be correlated to
with timing view so I will double click
on that as buffer memory and you'll see we get
the graph for that. I will show that.
You'll see a graph that seems pretty simple,
looks like a flat line or something that
doesn't have a variation. I choose that just to showcase
some of the features that I would just show not to-- The timer itself
is not important. But when I start to zoom in, this graph will
automatically zoom vertically in order
to fit minimum and maximum value that is visible in the view.
So, when I'm zooming in here, you'll see that things
will start to zoom in. So now I'm starting
to see more patterns here. You see that I'm zooming,
it's still flat, but I'm zooming more,
you'll see more patterns. Now I'm going to a frame level
and you'll see a pattern that is correlated
to its actual frames. Again, there are things
that seem pretty flat, but when you zoom in,
you'll see the pattern for them. That you can do with any timer
that is available. I want to show
an interesting variation. I will enable again
the rendering frames and we have two spikes and I could look on
what's happening in that spike. I see a frame
that took 73 milliseconds. I see in the timing event that something related
to garbage collection. So yeah, probably
that was the reason. I see that these variations
have a same pattern before and after
and pretty the same view. I'm looking again
on the second spike and now I'm seeing
something interesting. I'm seeing a pattern before
and seeing the pattern after. But I am seeing
that during the spike, this vertex buffer
memory has increased. So that one I could
give the conclusion that it has something to do
with how the spike itself caused the increase in memory. That is important because
it's not a spike in that memory. That memory remains at that
level after this frame spike. Again,
that could be important or not. I am just trying to showcase
things that you can investigate and things that could appear
different patterns that could appear when you look
on different stats counters. Another interesting stat
that I want to show is in lights and you see that has
a certain pattern. If you zoom in even more, you can see more details
of what's happening there. You can correlate if
you have more information, more timing events with what
is happening with this counter. Why is it having
these osculations. But more interesting
is when I start to zoom out and you start to see
patterns like that. So, it's not only, again,
if you just see an overview, it looks pretty flat. But when you see it
as this level, you already see the pattern. And it seems that it is
something regularly with roughly a
two second period. And again, it's something
that you can find could be useful
to know about those. But it will depend on what kind
of stats you're looking on. But it's interesting
to look on that. And again, you can do that
with any kind of timers. And that's all that
I want to show. >>Victor: That's great. >>Stefan: I guess there is
some hints as well in the tabs, which I don't think
you can click on, but to sort of highlight
some of the other stuff that we're adding, which is additional views
like for networking, to be able to look at server
and client information about what they're receiving, to be able to investigate
the network. Yeah, well what's going
on the network stack and see what's being replicated
and how big that becomes. And there are some hints
about GPU, I think. When you look at some
of the timing tracks, there's a GPU tab. That's something that is
actually not in the release because there were some issues
and we are on a tight schedule, so that is actually
disabled in 4.23. But the goal is to include
that as well on this timeline. >>Victor: Will Unreal
Insights replace our current network profiling tool
that also ships with the Engine. >>Stefan: The goal, I guess
when you look at this, if you're familiar
with the tools that exist, before this you'll see
that some of this information already existed
in a slightly different, well, set of tools. Our goal is not to
just add to those, to add yet another one, the goal is to kind of converge
and put all the information that makes sense
into this framework instead. That's something
that we're working on partially with the networking team
for example. And yes, is the answer
that the goal is to just have that here and ultimately
deprecate the old one. >>Victor: That's great.
>>Stefan: Same thing for the profiler. We want to just make sure
we add all the functionality that already exists. For example, on the CPU timing,
if we look at their existing profiler before this,
it had butterfly view. You could see hierarchical
information in a different way. That's something we need to add, but once we have
all the features, then we can deprecate
the old tooling. >>Victor: And that makes it
a little easier for people who are just
sort of starting out learning how to profile
the games or projects since I assume
that the tool itself and UI will be very similar and so you don't have to jump
between different interfaces. >>Stefan: Yeah. And the goal
is to make it easier also for people to collect if they have someone
testing the game and they run into an issue
that they can just switch on tracing and record a trace. And that will include all the
different types of information. It's just one file. Some of those things can be
a little bit more awkward today when you have different ways
of collecting information. It can be
in many different files. With this you can
collect it even over the network is the goal. If you have a play test,
for example, I've been on teams in the past
where we've done similar things and just collected
these traces over network. A play test with 60
or a hundred people, we're just tracing things
to a central server that programmers could look at
after a play test for example. >>Ionut: I just wanted to show, just want to show
those checkboxes, they are disabled right now,
but those are the one that I told earlier
about trying to remove the need of command line
options so in the future, you'll be able to just enable
timing directly from here. You just start the application
without any additional options. Trace is Enabled by default.
And when you want to enable tracing of the CPU
timing information, you would just check that and
the incoming stream will receive also timing information. >>Stefan: That is a
general theme, I guess. The preview or sorry, the beta,
that is in 4.23 is something were aware that some of the workflows
around collecting information, et cetera, they're not as slick
as we'd like them to be, but that's something
we're improving. >>Victor: That's great. We've
received a couple of questions. Are you good to answer
some of them? Alright. I think it would
help to clarify a little bit that Unreal Insights
is a stand-alone tool that you run either alongside or completely stand-alone
from the Editor. And one of the questions-- >>Ionut: It is always
stand-alone application for now, so you can just run it
as a stand-alone application. >>Victor: So one of the questions
were if it was possible to access one or more of the real time
track statistics info, via console command or even
better via Blueprint command. As far as I know, I don't think
there's any communication between the editor and the tool.
Is that correct? >>Ionut: No. At this point, no. But we will support for analysis
of the timing event also CLI interface so we can write
command line analyzers that will just process the event
in some way and generate
the reports based on that is what Stefan mentioned
in the presentation. >>Stefan: Yeah. I think the question
is actually more like if you're working in the Editor and you want to
trigger something or basically investigate
something in the editor, can you do that? And can you even script it or
control it through Blueprints? I mean the answer
is right now, no. But we're interested
in different problems that people want to solve. The whole question of exactly
how we integrate this in different ways
into the Editor and everything else is
still kind of open for debate. We are not entirely sure
what the end state is, but some teams are interested in exposing more information
in the Editor as well. That's something that's possible
since this is all in Slate, it is possible to embed, we're just not sure
if that makes sense yet. >>Victor: A little
bit of research to do. Yeah. And for those of you
who aren't aware of Slate, It's the underlying system
that the editor also runs on. >>Stefan: That's right. That's actually what enables us
to build this tool very quickly. The graphical tool
was built in three months and a lot of the response in
other things is thanks to Slate, I would say. >>Victor: That's great. Are there some top 10 things or
best practices within the tracks and timing events to look for? >>Stefan: I guess that's more
of a question around like the actual sort of looking, investigating and looking
for issues in your code perhaps, or if I interpret that. >>Victor: Perhaps, I think
you're right, what are some of the top
10 things that you might want
to look out for maybe? >>Stefan: Yeah. Some of the things
that are maybe obvious, like garbage collection,
et cetera, spikes, just things
that visually look irregular because if you want
a smooth frame rate, then yes. I mean looking for things that
stand out or take a long time. Apart from that,
more kind of common problems with, games, that's harder
for us to answer actually because we're not,
we're low level coders. We haven't actually used this
to solve game level problems ourselves. We focused more on low level
type of problems, which tends to be
around garbage collection and loading performance,
like I said earlier. But lots of other game teams
that are starting to use this for all kinds
of different problems. I'm sure we'll be able
to share something more. Some more tips like that later. >>Ionut: Also, for the future
of networking Insights will provide more
information about networking. It's completely different
than performance timing, but we'll see that you'll be
able to correlate information with the timing, because all the analysis
of different kinds of data will be done together. It's not just adding a new
profiler or a new investigation, all those will work together. You'll be able to see the logs,
timing information, network information
as loading information all in the same time
for the same session. >>Victor: Alright. Are we shipping
the Unreal Insights binary with the preview releases
of the Engine? Is it currently available? >>Stefan: I believe so, yes.
Right, Ionut? >>Ionut: Can I get
the question again? >>Stefan: Is the
binary in the release? I think it is, right?
You've answered. >>Ionut: Yes,
this is what I stated. Yes. On the release
it comes prebuilt. It is built-in
as a development application, but you'll see
that UnrealInsights.exe so you can just
double click on it or you can compile it
from sources; compile it from Visual
Studio, and just run it. No additional configuration,
it just works. >>Victor: Development,
or build for development is shipped in with the binary. But then if you want it
for something else, you can compile it from source? >>Ionut: You can compile
for shipping for example. Yeah. >>Victor: That's great.
Let's see. What is the file path
to find a binary? >>Ionut: I will not be able
to share it more, just one second,
so Engine binary is Win 64, and that will be
Unreal Insights. >>Victor: I will go
ahead and share that with everyone one
on the announcement post as well so that it's a little easier
to just copy a link and paste it into explorer than trying to listen
to someone reading it off. >>Stefan: This is another area
where we do want to improve and make things a little bit
more discoverable and accessible. But right now, you have to
find it and run it yourself. >>Victor: It's in Beta and I'm
excited to see some feedback and see how people use it and what they're able
to track down using it. Let's see, do the colored bars
have a color rule or not. Like red for critical, green for
good performance, et cetera? >>Ionut: For the frames track? Yes.
For the timing view, no. The timing view, at this point, each color is assigned
in a way that will try to make distinction
between timing events. It's a [inaudible] random assignation
of colors to timers. >>Stefan: Yeah,
it's more to be able to see the different
events clearly, >>Victor: We had another
question. >>Ionut: And also it try to emphasize
contrast against background because you have a gray
background and timing events will have a lighter way
of computing the colors and also they have
some special backgrounds that will emphasize even more
the contrast of timing events especially to make
very easy distinction between one big timing event compared with a lot of small
timing events of the same type. >>Victor: Nice. Let's see, I think
I have one more question here. Just some clarification. Some people are wondering
if you need to know any code or if you can use it
in Blueprints. And this is once again a totally
stand-alone application that you can sort of learn
even if you're not a programmer or you know Blueprint. You should be able to profile
and track this down. >>Stefan: Something we haven't added
is an ability to use Blueprint to, well annotate your Blueprint
to see; understand performance
of your Blueprint code. What we showed was the way
that currently exists to add these scopes
that you can see. That is only in C++ code. For blueprints we don't have
any functionality yet. >>Ionut: I think it may be
possible to generate stats with the existing
statting system. I'm not sure if that function
is exposed from Blueprint, but I have a vague idea
that it could be possible because once you have
scope timer stats, you'll be able to see that but of course
with the newer version. >>Victor: What are some of
the next steps you mentioned moving it over
to the other desktop platforms. Will we ever see the possibility
to use Unreal Insights to grab logs from external
devices like mobile and-- ? >>Stefan: Yes. >>Ionut: We are already
supporting platforms so we can already capture traces
from Xbox One, PlayStation, Linux
and of course next will be to support
all targeted platforms. >>Stefan: Yeah, we support
Switch and the other consoles, IOS and Android is under way. The goal is to support all of
those both on the network but also on device.
To a file on the device because network
is not always a good option. If you only have
Wi-Fi for example. >>Victor: Yes, usually not. What were some of
the challenges that you came across when you
started development on the tool? >>Stefan: Some of them,
as I mentioned earlier, performance
was really key for us. And that means that some of
the code that we have written to actually generate this information
right at the runtime. Since a lot of the code
that we're using this or the problems that we're using
is for is performance. One of the challenges is to
allow you to measure performance without actually influencing
performance too much. One challenge was to make
this tracing framework that I discussed earlier,
really lean and low overhead. In the preview release, it has
more overhead than we have now. We've made it better,
but yeah, that's one challenge. Just making it scalable so you can trace out
lots of information without really adding
a lot more overhead. And the other side
was of course, just figuring out how to present this processed
information in this way that allows us to look
at the huge big picture at the same time allow you
to drill down to the detail. That means you can't use
the most naive and easy solution to do that. I guess basically performance
was the big challenge. It is relatively easy
to do something that does this, but making it really
scale and efficient was one of the big challenges
for us I would say. I don't know what
Ionut thinks about that. >>Ionut: Yeah. For me was also
the challenge of learning using Slate in the same time
as developing this tool. By surprise,
that was much easier but I was, I thought, it is quite-- basically I was able to write
this tool from scratch, learning the framework,
the UI framework from scratch. >>Stefan: Yeah, and you understood that
super quickly in three months. What you were seeing
was written from, he started in March
and then we are releasing this. Basically,
the code is from early June and that's the timeframe where
he came in not knowing anything to delivering that tool
that we saw. >>Victor: That's very
impressive. >>Stefan: Yeah. But it also
speaks to the framework that we have in the Engine
for building UI and everything. >>Ionut: There, there is also
a lot of experimentation so it is not always well known what is the best way
to present data, how to navigate
or what are the best shortcuts. We are experimenting
and iterating and trying to make it better. >>Victor: That's
the way it goes. Was there something that you
learned during the development that surprised you and Mike might be good to share
with our viewers? >>Ionut: Yes. For UI that you
can do how much more of rich UI that I thought
about initially, so we are able to show that navigation from tens
of millions of events to small events of nanoseconds
at 60 frames per second. We can have things
that are animated. The user interface
could be really fluid and we can achieve that. We were not sure at the
beginning when we started, but yeah,
we're starting to see the path to see what we can
do with the tool. >>Stefan: I think, the other thing
was really, like I said earlier, one of my-- the ambition
with this whole effort, the reason why I wanted to
do it in the first place was that we have problems
to solve in the Engine to do with performance
and a bunch of other things. Like I said,
we had lots of questions and that was actually one of
the results at the end in June when we finally got
the loading view, for example, that we just kind of
give you a glimpse of, when we suddenly had
that information really visible and easy to digest, then that was
a wow moment for me. When I actually understood
a ton of stuff about the Asset loading process
that we needed to know, to know where
we should focus our work. That is really the highlights
to value of having a tool that allows you
to expose information that you can actually action.
That is the key thing for me is just the whole goal
of this tool is to give you information
that you can use some insights for you to use to solve problems and to me,
that whole thing just confirmed that this was the
right thing to do. >>Victor: Is that when
you came up with the name? When you had insight? >>Stefan: No, I
think, I'm not sure, I think we had the on
and off earlier, Ionut came up with it
as a suggestion and yeah, it stuck >>Ionut: Actually, the name is
representative for what it does. It show insights
in how Unreal Engine works. They are things that are coming
from Unreal Engine. All the trace information,
events, we try to expose and to try to visualize
and analyze that information
from the Engine. So, it was something
that we settled pretty early on, on this name. >>Victor: Yeah,
I definitely think it works. >>Stefan: Yeah. I mean the goal is
to add more so, right now
it's kind of the basics, but we, we intend
to do a lot more. >>Victor: That's great. With that,
I am done with the questions and unless you guys have anything else
you'd like to share, >>Stefan: No, thank you.
It's been awesome to get a chance to show off
the work of our team and yeah,
there's more to come, I guess. >>Ionut: Thank you. >>Victor: Yeah, I think everyone
appreciates all the work that-- >>Ionut: See you next time. >>Victor: Although we
are not over just yet, I have a little bit
of an outro spiel that I go through
before we end the livestream. But with that, I appreciate that
you guys both took some time to prepare material for today and all the hard work
you're putting in. If you're watching
this later on YouTube and we're following live or if there was
a part of the stream that that you want to dig
into a little bit deeper but you don't really remember
where that was, in a couple of days,
usually within a week we post our transcript
of the live stream which are being done
for captions together with the timestamps. There will be a link
in the YouTube description. If you're looking
for a specific term, my tip is that you go in there and you can control F
and search for the term and then you can actually find
where we said or mentioned that throughout the stream. You can specifically see
the timestamp and go to that section
of the video and you'll be able to find it
a little bit quicker than trying to scrub through and with the chance
of missing it. As always, if you would like
to let us know how we did today, what you liked
what you didn't like or what you would like
to see in the future, Amanda is going to go ahead and
post a survey link in the chat. Please let us know. Everyone who participates and
provides us with their email, we will be able to put you
in a sweepstakes for a Unreal Engine t-shirt.
If you would like to go ahead and meet other Unreal Engine
developers around the world, you can go ahead and go to
Unrealengine.com/user-groups and you can go ahead and see if there are any Meetups
close to you in your area. If there are none and you know that there are people
in the area who would like to get together
and talk about Unreal, go ahead and send us an email
at community@unrealengine.com and we can go ahead and give you
a little bit of information what it can be like being
a meetup group organizer. We also do our five-minute
count down at the beginning of our streams. That is 30 minutes
of development that we speed up
to five minutes. If you go ahead
and send that to same email, community@unrealengine.com together with a logo
of your project, you might become
one of our countdowns. And as always, let us know
about all the projects that you're working on. The forums are a great place
to do that. But I'd also recommend
Unreal Slackers, which is our unofficial Unreal 4 Discord server
where a lot of developers, I think we just might have
reached over 26,000 users, which is absolutely amazing. And then follow us
on social media. And if you go ahead and stream
Unreal Engine on Twitch, make sure that you use the tag so that we can come in,
see what you're working on. And with that said, once again,
I want to thank Stefan and Ionut for coming on and next week
we will be announcing the winners of the Summer
UE4 Jam. Tune in for that
if you're excited to see us play some of the games that won. Also, we will be announcing
the winners. Until next week,
bye Ionut and bye Stefan. We say goodbye and I'll see you
again next week. Bye everyone.
