This looks a really interesting and useful tool, nice work! 
Hey, Thanks for the heads up - it looks like it might be exactly what im looking for! problem though, I copied the release into the plugins folder - and it says there are missing components?
4.12.1
Thanks
For now you’ll have to have source in the project as you’ll need the engine to build it (Soon I’ll add prebuilt versions) but it can be a dummy class just enough to force the engine to build it. If you want to use it from C++, you’ll have to include “RuntimeMeshComponent” and if you want to use the extended API you’ll also have to include “ShaderCore”, “RenderCore”, “RHI” as well.
Ah ok, Ill keep an eye on this thread for the pre-built versions as I am not really a coder 
thanks Koderz
Nice ! This will be of great help ! Thanks.
Hellooo!
This sounds awesome, I was trying to make a run-time spline for growing tree roots in the last game jam and found that the collision wasn’t updating.
Would this be the solution?
my workflow so far was adding spline points and then Lerp them into position with some math to change the sizes of the tip and base etc. Looked really cool, but the collision was static from its first position,
any tips or advice would be ace of spades!
peace!
I’m not quite sure how you’re going about this. I also haven’t used any of the spline related things in UE4 yet so I’d need more information to be able to answer that. Also if it’s easier I’m in the Unreal Slackers chat most all day, every day.
Thanks Koderz. I’m sure i’ll figure it out.
Hi! I’m currently creating a Voxel terrain edit mode for unreal as a school assignment and I would like to add the source for this component as a module to my plugin. Is that possible?
Ofcourse I’ll give you the deserved credits, your work looks really promising!
Edit: I’ve done some testing and when changing the length of the vertices buffer it seems like the update is slower than when using the procedural mesh component. And if the amount of mesh sections increases, the time to update one section gets longer even though the mesh sections are the same size as before. Shouldn’t the time to update a section stay the same as you add more sections?
(I’m using the mesh sections as chunks for my terrain and they’re always 10 by 10 in size but they do take longer to update the more chunks there are).
This is wonderful! Thanks so much for sharing this.
Do you have any advice on how to handle updating the vertex normals when deforming the mesh every frame? Should I be modifying the “dual buffer” approach to include positions and normals in the separate buffer, or am I missing some simpler approach?
Awesome project. How complicated would it be to make this support mesh skinning (skeletal meshes)?
Example: I want to generate a procedural cylinder-like mesh, add procedural bones and skinning to it, add coliders, and then add ragdoll to it so that the cylinder falls like a rope. The only part of that I don’t know how to do right now is the bones/skinning part
Very cool! Might you be interested in making a pull request for this, so we can see if any of your changes can be taken directly into ProceduralMeshComponent? A lot of the things you mention I have wanted to do for a while, but just haven’t found the time!
I’m not opposed to it, but the one problem with trying to effectively integrate it into the existing PMC is it’s not 100% compatible, and can’t easily be made to be fully compatible. I will say however I’m not sure how much this really matters. Basically the serialization, which the PMC relies on UPROPERTY to do, isn’t how the RMC serializes itself when you want it to. So any existing data in a serialized PMC would not be loaded into the RMC if you replaced the PMC with it’s systems. Beyond that the API from blueprints is basically the same, just extended to support dual UV and also setting some hints for the rendering. From c++ it’s kind of the same story, it’s got the same API again extended, but then has a whole new one for more control.
The big reason I kind of like the MP/Github is that it can retroactively support older engine versions and can push updates faster. For example if I PR’d it right now and you accepted it tomorrow. it would still be at minimum a couple months till 4.13, possibly even 4.14 before anyone could use it from a release build (I get that those of us on source builds of the engine would get it sooner). I had thought about doing the MP/Github route until I had most of the features in/stabilized then PR it. If you have a better idea I’m open to suggestions, I’d just like to be able to both push more things to it relatively quickly as well as support those who can’t upgrade engines for various reasons.
Probably tomorrow I’m going to do several more additions to it, and I’m about to start down the path of rebuilding the template vertex to support another section style I want (extended dual buffer to allow selecting which components are in which) as well as possibly supporting high precision normals and things like that.
The big thing that I’m about to focus on because it’s a massive problem for my project and several other people I know is collision. Cooking in the GT is impractical in many games, and all but impossible in VR. I get hit with 8ms + per frame cooking and when you only have 11.1m total for 90fps it gives you no time to do anything else. I know you replied to me a while back about talking with NVIDIA about that, and mentioned trying to expose some of the parameters to the cooker. I’m thinking about attempting some of that myself here soon as it’s about to become a roadblock.
Merging back to the Engine would be awesome!
There could still be the need for a more rapidly evolving side project to test new features. but for mainstream usage official in-engine component is best.
Edit: all your above reason to wait before merging are valid. Basically, I think you should wait until you do not much more development (not when you have no more ideas!) that is, when it stabilize
I’d also love to see these changes in the engine, I don’t see any reason to use the standard RMC anymore.
But like other people here I’m also concerned by the release schedule of new features, at least while the component is still maturing.
Thanks for the quick reply!
What you say certainly makes sense, I wouldn’t want to impede your ability iterate quickly and get improvements out to the community. But it seems like a lot of the work you have done would improve ProceduralMeshComponent for everyone, even if it lags behind your ‘cutting edge’ module.
I think the serialization problem you mention is solvable with some backwards compat code (keep the old structs around for old content, but convert on load).
I’m interested to hear how the changes to improve cook times go.
Do let us know when you get to a point that you think it is worth sending us some changes to merge into PMC.
James
Hmmm… I was thinking of migrating Eden from PMC to RMC but will make things complicated if I want to try and sell Eden down the track?
There is also another thing to take into consideration before doing a Pull Request: it takes a lot of times (for everyone involved) to prepare/clean/document, then to follow/update…
So you have to take your time, even if just to avoid doing another PR a month after that with some more features.
Cheers, and thanks again Koderz!
I’m willing to attempt a convert on load, will probably need to dig more into the serialization to see how it all works before I can. If I’m able to solve that, the only other things that I haven’t done in this one is your SMC → PMC and the PMC → SMC as well as the slicer you did. Thinking about this, if all of those where to be converted to work with this, and the serialization problem fixed… There shouldn’t be a problem with a name change back to PMC for potentially merging with the engine and keeping the current name version separate as a plugin. They would probably have to keep 2 separate names though or things like installing from the MP/Github would get interesting when the project plugin name clashes with the engine plugin name. Unless either something changed or I did something wrong, last time it didn’t end so great.
Before going down that path though, do you see anything in there that you couldn’t accept? The RMC was a ground up rewrite, just matching/extending the current PMCs interface.
It’s free to use so you’re fine using it, the big question here is whether/when/how to merge it with the current PMC in the engine. No matter what happens you’ll be able to use it though.