Procedural Mesh Component Rendering Performance Concerns

Koderz · April 29, 2016, 6:43am

As a quick background on what I’m doing… I’m working on a dual contouring based voxel engine which currently runs with up to ~1500 chunks. Each chunk uses a heavily customized version of the ProceduralMeshComponent, or PMC, to render and provide collision. Also each chunk, and it’s associated PMC, has on average 2 mesh sections. This is also roughly the same chunk setup John Alcatraz is using in his project.

What we’re seeing is anywhere from ~0.2ms to ~1.2ms used each frame in the function GetDynamicMeshElements. Upon investigating further, it appears that 80+% of the time is used on this line

BatchElement.PrimitiveUniformBuffer = CreatePrimitiveUniformBufferImmediate(GetLocalToWorld(), GetBounds(), GetLocalBounds(), true, UseEditorDepthTest());

I’m not super familiar with how the internals of UE4 work but creating this every frame for each mesh section doesn’t seem like the best way to do this. After looking into several other components including the StaticMesh, Landscape, and also the BrickGame plugin it appears that 2 different things should change here.

That line should be changed to use a stored version of the uniform buffer and then the function OnTransformChanged should be implemented to updated it when necessary.
DrawStaticElements should be implemented to keep from having to re-register every section of every chunk with the rendering system each frame. The ProceduralMeshComponent only implements dynamic relevance currently.

Am I correct in this thought process? Is there anything else that can be done to further improve this? What is the actual difference between DrawStaticElements and GetDynamicMeshElements, and the associated StaticRelevance and DynamicRelevance?

I have done both of the above changes and it appears to function correctly and I don’t get the excessive time updating uniform buffers every frame. I have based my changes to the GetDynamicMeshElements, DrawStaticElements, and OnTransformChanged functions on BrickGame found here starting at line 241:

github.com

AndrewScheidecker/BrickGame/blob/master/Plugins/BrickGrid/Source/BrickGrid/Private/BrickRenderComponent.cpp

// Copyright 2014, Andrew Scheidecker. All Rights Reserved. 

#include "BrickGridPluginPrivatePCH.h"
#include "BrickRenderComponent.h"
#include "BrickGridComponent.h"
#include "BrickAmbientOcclusion.inl"

// Maps brick corner indices to 3D coordinates.
static FInt3 GetCornerVertexOffset(uint8 BrickVertexIndex)
{
	return (FInt3::Scalar(BrickVertexIndex) >> FInt3(2,1,0)) & FInt3::Scalar(1);
}
// Maps face index and face vertex index to brick corner indices.
static const uint8 FaceVertices[6][4] =
{
	{ 2, 3, 1, 0 },		// -X
	{ 4, 5, 7, 6 },		// +X
	{ 0, 1, 5, 4 },		// -Y
	{ 6, 7, 3, 2 },		// +Y
	{ 4, 6, 2, 0 },	// -Z

This file has been truncated. show original

The next part of this question is also based on BrickGames rendering component. I see where the vertex factory implemented the functions GetStaticBatchElementVisibility and GetStaticBatchElementShadowVisibility (Around line 148 in the above link) . Is this meant to be able to effectively show/hide individual meshes within the component instead of just the component as a whole? If that is right, is this called every frame, and if so does it preempt the usual culling based on the return value?

Thanks in advance for any help!

Dig_Squid · May 11, 2016, 10:53am

There are lots of different use cases for drawing geometry, and PMC is currently set up to be entirely dynamic and not optimized for the static case, which sounds like what you are looking for. Your changes to improve static geometry performance do sound interesting, it may be something we want to add options for supporting in the future. In general though when you have more specific rendering needs, it is often best to create your own component/proxy types rather than using the ‘general purpose’ ProceduralMeshComponent!