ProceduralMeshComponent limitations!

I’v asked about it already but it no one answered.
Can please someone of Epic’s team can reply?
The thing is when using too many sections ( For different materials ) the performances are getting very poor.
Why is it like that? Why in a normal UStaticMeshComponent ( which inherits from the same UMeshComponent class ) can have as many materials as you want and still keeping the good performances.
I’m working on an ingame modeling program and as it seems right now I will have to limit the mesh to one material in order to make it useable and this is becoming pretty much useless this way.
Please respond epic, this is really important to me.

I can’t answer to performance difference , but my guess is in the way meshes are instantiated vs created.

Anyway , for the ProceduralMeshComponent .You’re not suppose to have many sections.
I’ve also made this mistake when first using it. I tend to run the function many times and used an interator to increase the section index.
This is wrong. The correct way is to generate all the information and run it only once.

The method i’m using generate many piece of separate mesh on ONE section. What I did was… for every iteration I keep dumping all the vertices into a giant array of vector. This is suppose to be the vertex buffer.
Then I put all the topology information into a giant array of integer.

It’s only at the end of the entire function that finally generate the mesh one time through the section.

I’m also using one section for all the geometry and it works great at the moment.
But what about more materials?
I want to give the user the ability to assign different textures to different walls and I can’t achieve that with only one section.