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.
I think it is probably best to keep your own component, I’d hate for you to be bottlenecked by us on making fixes or adding features. I’m afraid I haven’t had a chance yet to carefully review your RMC code to see how easy it would be to merge with/replace the existing PMC code. I had a quick look though, and it doesn’t seem that different.
I have not worked with tessellation enough to know what it needs, but I remember seeing adjacency information in the static mesh which I’m guessing is what’s missing. I’d have to look into it, theoretically the RMC can be made to do anything any of the other components like static mesh, instanced static etc can do but I’m not sure what’s involved in this one. If that’s what it needs, then you’d probably want to generate that information yourself and supply it, because calculating that wouldn’t be a particularly fast operation for any non trivial mesh for the same reason normal/tangent calculation is slow since it also has to find adjacency for smoothing. I’ll try to look into when I have some time, but I can’t guarantee that I’ll add that, will depend how involved it is.
Well the only thing there that would really take any time would be the serialization convert on load, and that might not even take too long. The SMC <-> PMC conversions I had already planned to do, the only thing I’d really extend would be supporting the different normal types and the extra UV channels. Everything else in the PMC should be fully compatible with the RMC. I’m not saying I’d prioritize it right now, but if I had some time and could solve that one issue then getting your slicer and the other to work won’t take long at all. Also, fundamentally it’s very similar to the PMC, just heavily templated to support a few things, and rearranged to cut down on some overhead. Honestly I’m fine attempting it in the next week or so, as it would benefit many more people to merge at least the core where the performance/memory gains and a couple of the new features are. Then way later on bring in the other features if that’s something Epic wants. Honestly I’ll leave that up to you/Epic as really it shouldn’t be a ton of work for me and it would benefit others, but since it is a complete rewrite, it’s not a simple thing for Epic to review, so I doubt you want to do this to frequently!
Edit: James, not sure why this slipped my mind… More than likely to do the collision work I need will take modifications to the engine, so if that’s the case I could PR the RMC at that point which would be a massive boost to the PMC as well as a good example of the collision changes.
Thanks a lot for taking a look at that! It would be 100% fine if I had to pass in adjacency information, especially because there’s a function to generate those, BuildStaticAdjacencyIndexBuffer, as stated in this thread: Generate Procedural Mesh - C++ - Epic Developer Community Forums
Ok, I’d have to take a look at that function but I have a feeling it’s going to be rather slow, but I could be wrong. If all it it needs is indexed adjacency then you could probably manually create that faster out of whatever generation you’re using. I’ll look into it soon hopefully, but right now I’m getting started on collision as it’s the last remaining huge performance problem, and then LOD which I need for my own project. I definitely see the use in it, so I’ll see what I can do.
Interesting, I got PN Triangles working fine on my terrain mesh with PMC, they just didnt render correctly in wireframe, but clearly worked with displacement. about to goto sleep but tomorrow ill find where im at on my terrain BP and post it to your question frencesco (left it while RMC is worked on to focus on AI (you rock ))
I would be interested in seeing that as well so I’ll watch that question. I’m not positive that’s what the adjacency is for, but it makes the most sense, so I’ll dig more into it at some point soon hopefully.
Wow, great thing you’re making!
Just remembering old Carmageddon with ability to smashing cars by every vertices.
Do you have any metrics how slower RMC is than SMC? Rendering, transformation?
Hope Epics will support your work and you and your work will not go to shadow.
@ - Make a PR whenever you think you have reached a good point. Things like PMC->SMC really shouldn’t be too hard for me to fix, even if you haven’t done them yet. It probably will take a while to review, as your changes sound pretty major, but it sounds like some good wins too. I’ll probably need some input from the Rendering Team as well.
I already had it on my list for 4.13 to look at cooking performance and tesselation for PMC, so I’m very interested to know what you find out there! Maybe we do one PR soon with the basics, and then a further one which are those changes later on.
I’m just finishing up a couple things related to my personal project over the weekend and I have finals this week, but then I’ll try to tackle the up-convert on load, and a couple other minor things I want to add pretty quick then I guess we can start there! I kind of want to improve the serialization in general as currently it will only handle sections made via the old PMC style API. At this point it’s been used by quite a few people and appears solid (I did find a memory leak since V1 that I have since fixed). Currently it’s a feature complete version of the PMC (except those utilities and things in the BP function library)… It’s definitely major changes, I didn’t go into this trying to keep much from the PMC. I just tried to mimic it’s interface and functions, but structurally it’s similar, but a bit more complex. I’ll let you know when I’m ready, probably be 2-3 weeks would be my guess.
I remember the settings you where talking about in the pmc question I asked on the AH where you mentioned exposing the cooker config options, what else where you thinking about? I’d be more than willing to try to do whatever changes I need to do within whatever idea you/Epic has and submit them back if it helps to get it done quicker as I know that’s just one of a list of things you/Epic are trying to do. I’ll probably dig into collision for real Monday, so I’ll have a better idea after that but…
From my preliminary look a couple weeks back I figured to attempt to make the cooker callable from alternate threads and just let the PMC/RMC store a copy of the result and let the current path that happens when you invalidate the mesh use an extended version of the IInterface_CollisionDataProvider and return the cooked data instead of the raw mesh. That lets me offload the cooker entirely to a different thread, but it doesn’t take advantage of some of what Ales Borovicka was saying about being able to bypass the serialization that’s currently done. It would however let the RMC/PMC have almost direct control over the cooker and its configuration and let it pull it out of the GT. The serialization might still add some unnecessary time/work, but that at least gets the primary work moved and looked to be relatively simple way to do it compared to some of the alternatives. That’s all based off what I remember from a few weeks back, and I haven’t dug into it super deeply yet to see exactly how all parts fit together. That also didn’t assume that it would ever be used by more than just me, but if I’m going to do it and it’s reasonable to give that back since I’m sure others can use it then I’m more than willing to go a different route.
One change that needs to be made to cooking is to remove the cleaning step. That can change the vertex count, which breaks the ‘fast update’ path for collision (UpdateMeshSection), and should also speed things up a bit. Threading the cooking is an option, but I think its worth getting it as fast as possible single-threaded first, as making it async will add a lot of complexity!
I definitely agree that speeding it up on single thread needs to happen first and is what I plan to dig into later today. One thing I’ll mention with the fast update path you brought up is there’s a way to keep the cleaning an get that from what I know. IIRC the cooker can output a face remapping table so that as long as you don’t update the triangles you could quickly forward map the vertices into the ones PhysX needs and continue to use that path as even doing that should be far faster than involving the full cooker, but also give the best collision performance. With that said I think the best solution would be to allow you to configure your way into and out of that part so if you want super fast updates and are fine with degrading collision speed a little then disable cleaning, but if you want quick updates and fastest collision then cook on create get and store the remap table then on update remap the vertices and use the same path that you’re wanting to use in update.
**Edit: **James, I looked into tessellation yesterday and it appears nothing really has to change about the RMC/PMC to support PN. The problem is the helper someone mentioned in the engine to calculate it appears to be in a developer/editor module that I’m not sure can be linked at runtime. Internally it appears to just call the nvidia tessellation library helpers so I could re-implement it depending directly on that library but wanted to see if we could link that at runtime instead of recreating it?
Runtime Mesh Component keeps shooting my (test-)project: when I dublicate a blueprint containing RTM and then doubleclick to open the blueprint, the engine crashes with this report:
"Assertion failed: Vertices.Num() > 0 && ‘Vertices length must not be 0.’ [File:C:…\Documents\Unreal Projects\ULNExample\Plugins\RuntimeMeshComponent_v1.0\Source\
@Stoon82 I’m not quite sure I understand what you’re attempting to do. That assert is when you pass an empty vertices array to CreateMeshSection since it can’t handle that safely. I need to switch those over to log errors in editor though instead of just assert crashing the engine…
Let me know more what you’re trying to do, or if you can recreate it in a little test project and share that, and I’ll try to figure out why it did that.
It’s probably exactly that… I’m doing all the work in the blueprint’s construction script as of now: create the vertex-array, index-array, add runtime mesh component, create mesh section.
But I have the array creation behind a boolian-branch (if initialize_mesh_data == true, add vertecies to array)… so when I duplicate the BP, the array is still empty and the RMC crashes the engine and the BP is taken from the content browser. It’s not too hard to get back, but actually, I can’t edit it, since every time I open it, the engine crashes again. recreating that shouldn’t be too hard, if still neccessary.
But after all, I didn’t want to be all that negative: I love the procedural mesh component, and from all I could try and see, the runtime mesh component works a treet (besides the mentioned effect) and adds even more speed and flexibility.
If someone knows how to make and octree-database on server side to stream data to the client, the step to have something like midgen’s CashGen Plugin and add editable landscape like here (TerraVox smooth voxel terrain for Unreal Engine 4 - YouTube) with overhangs and cliffs.
Another question though:
I had trouble creating an array of ‘color structur’ from a BP and it doesn’t allow for feeding in an array of linear colors; the same goes for procedural mesh component. I could be totally of the track here, but I tried quite some time to find a workaround and never got it to work. Any advice anyone?
