That’s right, hence why the “works in the editor” part. 
https://.com/watch?v=5qMpMAglKsE
Results of my tinkering with the component so far. Now trying to find the sweet spot in terms of block size, number of LODs etc to smooth out the hitching…any tips on making that UpdateSection call less painful appreciated 
We found that 32x32 points tiles (1m distance between points) gave us good compromise. One thing to consider – if you don’t need collision, make sure to untick ‘Create Collision’ from ‘Create Mesh Section’ node. You could test heightmap (much faster) based on your spaceship location, instead of colliding and having to create collision for each tile.
LOD Transition – you’ll either have to find a way to seam the tiles better, or create ‘skirts’ – another commonly used approach to hide. Third way would be to have overlap where both LOD0 and LOD1 are rendered in the same space. Regardless of what you’ve done with LOD0 collision, LOD1,2, etc certainly don’t need it.
When creating ProcMesh, roughly half of the time is spent in creating mesh itself, and half in preparing it for collision.
If performance is issue, consider moving everything to C++
[=xulture;510878]
We found that 32x32 points tiles (1m distance between points) gave us good compromise. One thing to consider – if you don’t need collision, make sure to untick ‘Create Collision’ from ‘Create Mesh Section’ node. You could test heightmap (much faster) based on your spaceship location, instead of colliding and having to create collision for each tile.
[/]
Yep 32 seems about right from my testing. I do only have collision enabled on LOD0.
[=xulture;510878]
LOD Transition – you’ll either have to find a way to seam the tiles better, or create ‘skirts’ – another commonly used approach to hide. Third way would be to have overlap where both LOD0 and LOD1 are rendered in the same space. Regardless of what you’ve done with LOD0 collision, LOD1,2, etc certainly don’t need it.
[/]
Skirts are on my todo list Also poking at 4.11 to see if I can the dithered LOD transition effect.
[=xulture;510878]
When creating ProcMesh, roughly half of the time is spent in creating mesh itself, and half in preparing it for collision.
[/]
Yep, I’m going to modify the component so I can spread the mesh creation and collision over two frames, see how that goes.
[=xulture;510878]
If performance is issue, consider moving everything to C++
[/]
Already is, though as I say, the speed of my calculating the vert/tri/uv/normal/color/tangent data isn’t a problem, it’s keeping the time of the update call down.
tangent fix for wonky normal along tri edge
not sure if anyone is still using this,https://wiki.unrealengine.com/Procedural_Mesh_Generation
i am using a modified version, its just easier(dont need multiple materials) for what i am doing.
but.
there is a problem with the tangent calculator,
but i have a fix…
where you build the SceneProxy
replace:
const FVector TangentX = Edge01.SafeNormal();
const FVector TangentZ = (Edge02 ^ Edge01).SafeNormal();
const FVector TangentY = (TangentX ^ TangentZ).SafeNormal();
with:
//tangents werent working quite right here, so...
float DeltaU1 = Tri.Vertex1.U - Tri.Vertex0.U;
float DeltaV1 = Tri.Vertex1.V - Tri.Vertex0.V;
float DeltaU2 = Tri.Vertex2.U - Tri.Vertex0.U;
float DeltaV2 = Tri.Vertex2.V - Tri.Vertex0.V;
float f = 1.0f / (DeltaV1 * DeltaU2 - DeltaU1 * DeltaV2);
FVector Tangent;
FVector BTangent;//not used
Tangent = (Edge01 * DeltaU2 - Edge02 * DeltaU1)*f;
BTangent = (Edge02 * DeltaV1 - Edge01 * DeltaV2)*f;//not used
const FVector Normal = FVector::CrossProduct((Tri.Vertex1.Position - Tri.Vertex0.Position),(Tri.Vertex2.Position - Tri.Vertex0.Position));
FVector NTangentX = Tangent;
FVector NTangentZ = (Tangent ^ Normal);
FVector NTangentY = (NTangentX ^ NTangentZ);
NTangentX.Normalize();
NTangentY.Normalize();
NTangentZ.Normalize();
const FVector TangentX = NTangentX;
const FVector TangentZ = NTangentY;
const FVector TangentY = NTangentZ;
and you will go from this:
to this:
hope this helps someone.
Hi guys.
Just a heads up to anyone updating any code to 4.11 after it working on 4.9, the function signature for GetViewRelevance in the PromitiveProxy has now had const added to it. The compiler wasn’t helpful in telling me just moaned about the function being ‘hidden’. Anyway got mine working now as I’m generating new mesh every frame. What is this ‘fast path’ mesh I saw mentioned a few threads ago?
[=;506059]
I’ve built a procedural-to-static converter that works in the editor, presumably it could be made to work for skeletal meshes as well if weighting was added. I’ll look into it when I get some more time.
[/]
Any you could share this, or outline your approach?
Pretty straightforward - create an FRawmesh and provide it to the static mesh. You can even set the usual import options. I’ll post some code when I head into work later on today.
Sadly I can’t share a lot of code as it belongs to my employer, but I can point you in the right direction! If there’s enough interest I could see about releasing it as a C++ on the marketplace as I’d like to see how they work. I’ve also been a bit brief and left out things that you probably already know about, like the Outer being a package, etc.
Start with an FRawMesh:
FRawMesh InRawMesh = FRawMesh();
Then start setting members. This isn’t exactly like a procedural mesh but you can shift the data around from a procedural mesh to make it fit.
The first thing you want to populate is “VertexPositions”. So do that. If you want to be super awesome, during this stage you could de-duplicate your vertices. At the same time build your WedgeIndices by just keeping a TArray of each resulting index that you add to VertexPositions.
Next you populate your wedges. A “wedge” is a corner of a polygon and consists of a vertex position, tangents X-Z (Z = normal, X = tangent, Y = bi-normal), UV coordinates for however many UV channels you have (define at least one!), a vertex colour, etc. Populate all of the wedge members. All of these arrays should be the same length as WedgeIndices (as it is used to reference them) but will exceed the length of VertexPositions.
Finally you have material indices and smoothing groups. You can just fill these with zero if you need to.
You can call “FRawMesh::IsValid()” and “FRawMesh::IsValidOrFixable()” to know in advance if the mesh will work.
If you were making a cube your mesh stats should look a bit like this:
VertexPositions: 8
WedgeIndices: 36
WedgeTangentX, Y and Z: 36
WedgeTexCoords[0]: 36
That’s because each square face has two triangle polys, so six wedges or which two pairs share a vertex.
UE doesn’t really index normals, UVs, etc, only vertex positions.
If all that passes you’re ready to send everything on to your Static Mesh:
auto StaticMesh = NewObject<UStaticMesh>(InOuter, InName, RF_Public | RF_Standalone);
FStaticMeshSourceModel* SrcModel = new(StaticMesh->SourceModels) FStaticMeshSourceModel();
SrcModel->RawMeshBulkData->SaveRawMesh(InRawMesh);
Under SrcModel->BuildSettings you can set up things like lightmap generation, collisions, compute normals, etc. I’d almost always recommend computing normals and just setting the tangents to whatever as a placeholder. UE does a nice job of fixing these up.
Then finish it off:
StaticMesh->Build();
StaticMesh->MarkPackageDirty();
I’ve had to leave out way too much stuff that’s either messy to demonstrate or I’m not able to share but I think most people would find a useful as getting into the guts of UE’s editor isn’t always easy, so I’ll definitely look into that.
I also haven’t looked at skeletal meshes yet either but I assume they’re an entirely new kettle of fish, but it may just be another layer of inheritance on top of a static mesh.
I have updated Unreal.js to support UStaticMesh editing.
https://.com/ncsoft/Unreal.js/wiki/StaticMeshEdit
[=;531290]
Sadly I can’t share a lot of code as it belongs to my employer, but I can point you in the right direction! If there’s enough interest I could see about releasing it as a C++ on the marketplace as I’d like to see how they work.
[/]
Thank you, this is great! And yes I’m pretty sure there is enough interest here to take this one step further. I’m working on a myself to provide examples of procedural generation, and working with plugins is quite easy to do.
Quite a few people are interested in custom mesh generation and having a good way to add export functionality would be very useful to many of us.
I’m a bit annoyed at ProceduralMeshComponent’s insistence to serialize the mesh sections to disk when you save an editor map, and would prefer it not save anything (and just re-gen on loading) and offer an alternative way of manually saving the mesh.
I’ve managed to get around this in my own code by having my actor class mark the component as Transient/DuplicateTransient.
UPROPERTY(Transient, DuplicateTransient)
UProceduralMeshComponent* ProcMesh;
And then in the constructor:
ProcMesh->SetFlags(EObjectFlags::RF_Transient);
However this prevents me from inheriting the component directly and forces me to use actors to wrap it (so I can serialize all the properties but not the mesh data).
Who knows, maybe I’ll have to move away from using that component altogether.
Using the transient flag sounds like the right way to solve it to be honest, that’s what it does behind the scenes when you tell a component not to serialize itself I think. I’ve made pretty good use of it as well. Procedural Meshes feel a bit weird though - you can’t surround them with a package can you?
I would love if the component had the mesh section marked as transient yeah, then I could inherit that component and add my own stuff. Or if the mesh sections were set as protected, then I could at least override the flag.
Dunno about using a package for this, havent really considered it… a blueprint version of the class does everything I need really.
I just posted a bunch of procedural examples (as a with source) for free here: Procedural Mesh Examples - free! - Community & Industry Discussion - Epic Developer Community Forums!
found some pretty glaring problems with how PMC handles collision updates and navmesh updates
Hi , guys,
firstly thanks for the PMC, i love it - but have hit a wall in my deformable terrain. I outline my problem all here with images.
thanks for taking a look, as you can see - the update mesh does not update collisions beyond section 0 correctly. additionally, create mesh section appears to nullify every section AFTER the one built.
aka, if i update section 5 using a create mesh section node (because update mesh is not updating section collisions correctly) sections 0 - 4 will remain undeleted, but everything >5 will be deleted.
I am currently on 4.11.2, its a great tool and i am aware its experimental, and would be very thankful for some input or feedback - or if somewhere in my blueprint I have misunderstood the workings of the module. but im pretty sure I have it right after many tests.
Thanks mate
[=bswinbanks;538239]
found some pretty glaring problems with how PMC handles collision updates and navmesh updates
[/]
Hi ,
Check out 's excellent Runtime Mesh Component, I’ve swapped over to using that exclusively:
Runtime Mesh Component - Marketplace - Epic Developer Community Forums!
[=]
Hi ,
Check out 's excellent Runtime Mesh Component, I’ve swapped over to using that exclusively:
Runtime Mesh Component - Marketplace - Epic Developer Community Forums!
[/]
Hey ,
As youll see I already posten on that thread (2 under yours 
) came and sniffed me out after a post on answerHub! 
thanks though
I will be grabbing it as soon as there is a release that works with the package versions, as I am not a coder and have not compiled my own engine 
until then I have focussed on AI as to not lose any traction on my project
I was wondering if anyone has figured out how to pull off height map displacement on these meshes. I’ve been tinkering with a terrain generator but tessellation always gives me weird flickering results.
No tessellation:
Tesselation:
Hi ,
I’m using a UPrimitiveComponent “extended/using” a FScneViewProxy() to draw meshes
There is some way of getting mouseclick () events or get hit proxies on primitives draw with FDynamicMeshBuilder ?
On docsdocs.unrealengine.com/latest/INT/API/Runtime/Engine/FDynamicMeshBuilder/GetMesh/2/index.html we have a parameter with HHitProxy* that can we pass when use GetMesh(…)
GetMesh
(
const FMatrix & LocalToWorld,
const FMaterialRenderProxy * MaterialRenderProxy,
uint8 DepthPriorityGroup,
bool bDisableBackfaceCulling,
bool bReceivesDecals,
bool bUseSelectionOutline,
int32 ViewIndex,
FMeshElementCollector & Collector,
HHitProxy * HitProxy
)
But how can I get That HitProxy* on other parts of code not only on CustomMeshComponent using a FSceneProxy(), for example how can I get the Hitproxy value on Actor that have the component ?
Thanks