Hello, I’ve looked around but not found much as an answer to this question so here it goes:
Is, and if so to what degree is, umbra in UE4 as it ships?
A related question, what kind of culling are we getting in UE4 at the moment? Frustum Culling? Is there any occlusion culling?
Basically I want to know if I need to drop a lot of coin on Umbra tech to speed up rendering. (are the details of umbra integration (ie price) public?)
Thanks
Sorry in advance, but it doesn’t directly answer your question but as far as performance UE4 is getting better “out of the box”. Exciting rendering changes have been made to the github source for 4.3. I’ve been following it almost daily.
Some that i saw:
Take this with a grain of salt, as it may change, (get better or worse) by the time 4.3 is released.
But from compiling from github source from ~6/16
Here are a couple pictures. All i did was create a new blue print template and compared FPS (Play in editor, and play in stand alone game). I wouldn’t expect this huge of a jump across the board, but improvements are improvements, and i can tell that epic is really dedicated to performance and stability while also bringing top tier rendering technology.
Even in the very basic scene you see a bunch of improvements in quality and performance.
http://i.imgur.com/mqQmcbC.png (The fps in this one seems higher than the average, the average was about 120-130)
UE4 has a pretty good occlusion system built in, with a mixture of (optional) precomputed and dynamic occlusion using frustum culling (against an Octree I think), cull distance volumes (placed by the level designer to hint at stuff that definitely shouldn’t be visible) and carefully managed hardware occlusion queries (UE keeps track of stuff that is probably visible or probably not visible across frames and makes some intelligent guesses when the occlusion queries may or may not need to be issued again).
On my PC, in the shooter game InitViews (culling) is 1.5-2.1ms and in UDK’s Deck16 averaging 1.5ms, with my wild-*** guess of about 5-10% overdraw.
Umbra claims ~0.01ms cull times (though this number seems bit low when software rasterization is used), stability across frames rather than the current ~0.5-1.0ms fluctuation depending on viewpoint, and software occlusion queries (against a software render of a volexized scene if I read correctly) which should result in same-frame results rather than the current ~1 frame delay of UE’s solution which can result in a little popping here and there, and a little lower GPU cost. I expect overdraw is probably a little less as well, maybe 5%?
So nice, yes.
So the consensus seems to be that Umbra would be a nice bonus, maybe something to integrate if you were close to shipping a title and had the bux to spare, but that Unreal Tech is doing alright on their own.
@Krushin: That’s some impressive gains in the renderer if those numbers really translate, kudos to the Unreal crew, though I doubt that they have much to do with culling in such a simple scene…
@XenoBrain: My only experience with Umbra is with Unity, but that indeed seems to be a software voxelization of the scene for dynamic occlusion culling in my (very) limited understanding. You have to bake it, but it speeds things up for sure.
Anyway, I was just curious, maybe a Umbra or Unreal muckity-muck will drop some knowledge on the thread. Thanks for the replies.
@Samsterdam: Yeah, ain’t that the truth. Thanks for the reply. One of the reasons I asked is that I was under the impression that Umbra was part of UDK/UE3 and as a way to get the price down for UE4 Epic stripped it out (ala speedtree integration, etc). If that is not the case then that’s great, but I haven’t heard from anyone or read anything from any definitive source as to what is really going on in UE4’s culling system vs UE3/UDK.
Here’s the thing: it’s such a pretty engine that I’m sure many of us would like to blow up our computers with tens of millions of polygons per frame of sparkly awesomeness, but trying to get something playable that really looks dense with long draw distances (I’m particularly concerned with outdoor scenes) is a tall order even on my massive rig, and I’m wondering if that might be because the culling was nerfed so that we could have UE4 at $20/mo…
I don’t know enough about it to sort it out, so I asked. I am looking to prototype a tech demo, but without knowing how much performance boost something like Umbra would deliver makes it hard to decide where to draw budgets for polygons and whatnot… The whole ‘make it and if it runs like **** then buy umbra and maybe that’ll help’ thing seems like a resource intensive way to figure out your project isn’t feasible with UE4. I’ve no intention of licensing it right away, I’m just trying to suss out the benefits vs the current system.
Thanks for the correction on Umbra not being in UE3, that’s good to know. I figured some things had to have been stripped out of the engine for Epic to offer it so inexpensively, and middleware (like blink video) would have been the first to go…
Agreed on culling only being a piece of the puzzle, absolutely. It’s just the piece I’m curious about today 
Umbra is really good, and it isn’t baked like someone said above; that’s in a previous iteration.
For simple scenes and very vast outdoor scenes, you’re not going to get better performance with Umbra. It only shines when lots of objects occlude one another. The reason they can render at such a low frametimes is because they dynamically scale their load depending on how much is in view, and they probably do this hierarchically so they can stop when they reach the maximum time, from front to back.
We had a working prototype (using the same technique Oxel uses for occluder generation, cheers Nick Darnell!) which worked well and was nearing the same speed, and it was interesting to read how the Umbra guys did it. They’re really talented.
Both UE3 and UE4 do not include Umbra out of the box. I think Umbra will develop a plugin for UE4 at some point to make it easy for everyone to evaluate what the gains are for their game. In the meantime we are constantly working on making the built in occlusion methods better. The main method in UE4 is GPU HZB occlusion, which is latent (popping) but has pretty low cost per instance. This method has not managed to surpass the standard hardware occlusion queries in all cases yet so it’s disabled for some platforms. It’s controlled with the ‘r.HZBOcclusion’ console command.
There are also precomputed visibility and cull distance volumes, but those are mostly for special cases (mobile) where draw call counts have to be really low.
Personally I expect the upcoming UE4 parallel rendering to make a much bigger impact on the rendering thread performance and number of objects that can be drawn than any improvements to occlusion culling. Occlusion culling only works when there are good occluders, not when you are looking out over a huge vista. There you need LOD, lower overhead per draw call, and parallel rendering.
Thanks for the great info! Can’t wait.
I know this is an older thread, and I was curious if there have been any large changes in the past 2 years that may make Umbra a more or less appealing option?
I know this thread is quite old, but I’m wondering what you were referring to there. Did UE4 ever get that parallel rendering? I’m seeing “Vulkan Support for parallel rendering” on the roadmap, so I’m guessing it’s working, but only with DX12 currently? 
Yes the UE4 renderer has been parallelized through great effort on the part of people like Gil Gribb and Marcus Wassmer and many parts of it scale up to any number of cores. Parallel rendering is only enabled for cooked builds though - you won’t see any gain in PIE or the editor or uncooked game.
On all platforms, the major mesh passes (PrePass, BasePass, etc) build commandlists in parallel.
On platforms that support it (consoles + d3d12) the commandlists are executed in parallel as well.
