Announcement

Collapse
No announcement yet.

Runtime Mesh Component

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Ok. A few weeks back I said that I hoped to have v2 out a few weeks ago if all went to plan. Obviously it didn't unfortunately so here's where it stands.

    First up the marketplace doesn't support 4.13 yet, I just sent a message to Epic to ask them to update it as it should be updated soon. V1.2 the current marketplace version is what will be updated until v2 is done, which I'm working on completing asap but honestly can't give a definitive date, just hopefully within a week.

    Next, what is currently done and on github for v2.
    • RuntimeMesh <-> StaticMesh conversions. This should work in both directions in editor with all engine versions 4.10+, and it also supports RMC -> SMC at runtime on engine 4.13+
    • The new vertex struct is done and up, with that much better serialization support will be soon.
    • Mesh builder, this is used internally to support the utilities and you can use it as well. It still needs some work, and would welcome input as to what would work best.



    What's coming to github very soon (hopefully today/tomorrow)
    • Normal/Tangent calculation
    • Tessellation
    • A couple of bug fixes


    The big remaining part is collision for v2.
    The expectation here, assuming everything works as intended is the RMC will gain 3 modes of operation when it comes to collision. The first is the normal cook on commit which will halt the game thread and will be inserted on the following frame. This is the way the PMC and the RMC currently operate. The second is an internal thread pool. When you commit an update to a section it will queue a build on a shared threadpool and will update collision whenever the cook finishes. This might be on the next frame, it might not, but it won't halt the game thread to cook. The third is an option you have to supply the RMC with cooked collision data, and a utility you can call from your own threads to cook a mesh. This means you have complete control of what thread cooks it, and when it gets inserted. You can even save the cooked result and load it back later.

    V2 of the RMC will still support engine versions 4.10+ and certain features like the extended collision support and SMC -> RMC runtime conversion will only enable themselves and function when they're used with a supported engine version. In the case of SMC->RMC runtime conversion that is engine version 4.13 and the collision is TBD as that will require engine changes to hopefully work through the PR process.

    If you have questions/comments, feel free to message me on the Unreal Slackers new Discord.

    Github: https://github.com/Koderz/UE4RuntimeMeshComponent
    Last edited by Koderz; 09-08-2016, 03:14 PM.

    Leave a comment:


  • replied
    First off, sorry everyone about the delayed response and the way overdue v2. I keep getting slammed with work (the house is torn apart right now due to water damage) and classwork at the same time for large course projects... I will follow this post with another on the current standing of the RMC and the plan.

    Originally posted by Chariots
    Tested this after I got home, apparently this only happens if you forget to register the component (derp). So it's not a bug, and the correct way to "fix" it is to properly register the component.
    Ok, that makes sense, but wondering why wilber is still having issues.

    Originally posted by wilberolive View Post
    I'm pretty sure there is still some sort of bug going on here. Take a look at the following screen shots. The first one shows a blueprint actor with a PMC, the second one shows a blueprint actor with an RMC. The final screen shot shows the result when both of these are placed in the level. As you can see the nav mesh is not being effected by the RMC. I'm not sure how the RMC could be registered any different that what is being done with the PMC.
    I will try to look into this here soon, trying to finish up collision work for v2, but keep getting slammed with life events and classwork.


    Originally posted by Thumper View Post
    This component is amazing! Thank you. So I've figured out how to update the positions and vertex data separately but how do I update the collision? Is collision only to be updated using the convex collision stuff? I'm new to this all so pardon the perhaps obvious questions. If I'm updating the procedural mesh around the player on the fly, how do I update the collision too? I see the convex collision stuff that seems to be for procedural meshes that are moving, but what about static meshes that you're generating on the fly? Do I need to prescribe them collision shapes as I build the local geometry?
    If you enabled collision when you called CreateMeshSection it retains that setting and updates any time it sees the positions update, or well it should at least. the convex collision is really only useful if you want moving objects.

    Originally posted by rYuxq View Post
    Sooo, here is another fan of this plugin.

    Am I right in presuming that the plugin is not coming to UE 4.13 anytime soon since Epic Games needs to merge one of the features into their engine source?
    Is there any ETA when this might happen? Or is this still clouded in the dark?

    Would it be possible to release a 1.9 version of the plugin, where you exclude that feature, so that we might run it with 4.13 as well?
    The plugin is coming to 4.13 (in fact you can use it now if you manually install it to either the engine or your project). Due to aformentioned reasons I hadn't actually noticed that 4.13 was out and such hadn't asked Epic to update it to 4.13 until today so it might take them a bit to work that through. Currently v1.2 which is what's on the marketplace should be what's updated to 4.13 for the marketplace until v2 is done.

    I'll explain the other in the next post.
    Last edited by Koderz; 09-08-2016, 03:02 PM.

    Leave a comment:


  • replied
    Sooo, here is another fan of this plugin.

    Am I right in presuming that the plugin is not coming to UE 4.13 anytime soon since Epic Games needs to merge one of the features into their engine source?
    Is there any ETA when this might happen? Or is this still clouded in the dark?

    Would it be possible to release a 1.9 version of the plugin, where you exclude that feature, so that we might run it with 4.13 as well?

    Leave a comment:


  • replied
    This component is amazing! Thank you. So I've figured out how to update the positions and vertex data separately but how do I update the collision? Is collision only to be updated using the convex collision stuff? I'm new to this all so pardon the perhaps obvious questions. If I'm updating the procedural mesh around the player on the fly, how do I update the collision too? I see the convex collision stuff that seems to be for procedural meshes that are moving, but what about static meshes that you're generating on the fly? Do I need to prescribe them collision shapes as I build the local geometry?

    Leave a comment:


  • replied
    Originally posted by Chariots
    Tested this after I got home, apparently this only happens if you forget to register the component (derp). So it's not a bug, and the correct way to "fix" it is to properly register the component.
    I'm pretty sure there is still some sort of bug going on here. Take a look at the following screen shots. The first one shows a blueprint actor with a PMC, the second one shows a blueprint actor with an RMC. The final screen shot shows the result when both of these are placed in the level. As you can see the nav mesh is not being effected by the RMC. I'm not sure how the RMC could be registered any different that what is being done with the PMC.

    Click image for larger version

Name:	pmc.png
Views:	1
Size:	111.1 KB
ID:	1114427

    Click image for larger version

Name:	rmc.png
Views:	1
Size:	120.8 KB
ID:	1114428

    Click image for larger version

Name:	result.png
Views:	1
Size:	340.9 KB
ID:	1114429

    Leave a comment:


  • replied
    Originally posted by wilberolive View Post
    [MENTION=141752]Koderz[/MENTION]: I believe I've found another bug. It seems like the runtime mesh isn't updating the nav mesh like a procedural mesh does. I created an actor with a runtime mesh using the same blueprint shown in the picture from my earlier post and then created a second actor using a procedural mesh, again using the same blueprint. I then added a nav mesh bounds volume to the level and set it to dynamically update. When you drop the actor on the level with the procedural mesh, every works correctly. The nav mesh updates and takes the procedural mesh into account. However when you drop the actor with the runtime mesh on the level, the nav mesh does not update at all. Even when you force it to update it doesn't take the runtime mesh into account.
    Well that's strange... I don't see anything special in the PMC to support that, and the collision in the RMC is almost identical to the PMC's until I get the upgrades done. I've not had much experience with the navmesh so I'll try to take a look at it here soon in my bug fixing pass.

    Originally posted by Chariots
    As a workaround on the nav issue: You need to reset the navigation flags on the rmc.

    Code:
    RMC->SetCanEverAffectNavigation(false);
    RMC->SetCanEverAffectNavigation(true);
    This should enable navmesh generation. I do this on the first tick (and never again), I recall that it wouldn't work on BeginPlay, can't test it right now unfortunately. In editor you can also force generation of it by modifying any property of the actor it's in, or by moving it slightly.
    If you change the mesh later do you have to do this again?



    Originally posted by Thumper View Post
    I'm curious how one would use the packed vertex arrays method described on the documentation site. I see your example with the 640K waves which looks great, but I'm wondering how that was done in terms of the containers that were used. I have similar sized container and a simple way of having sections to it, but I don't understand how I could pack all the vertices into a container and only update the only the sections in questions vertices. Any chance I could see the wave examples code?
    While there's not much to these examples (and I haven't made absolutely sure they work with the latest version quite yet. I will do that in the next few days though) it does contain everything I used in those images.
    https://github.com/Koderz/UE4Runtime...ponentExamples
    The wave specifically is here...
    https://github.com/Koderz/UE4Runtime...tedTerrain.cpp
    The Generate() function sets up the mesh including the full vertex information, as well as index buffer, then in the Tick function it recalculates and updates the positions and updates them alone. There's a similar way to update the rest of the vertex information using BeginMeshSectionUpdate() and EndMeshSectionUpdate() and you can also still use UpdateMeshSection like the PMC but it was adapted to work with the packed vertex.

    Leave a comment:


  • replied
    I'm curious how one would use the packed vertex arrays method described on the documentation site. I see your example with the 640K waves which looks great, but I'm wondering how that was done in terms of the containers that were used. I have similar sized container and a simple way of having sections to it, but I don't understand how I could pack all the vertices into a container and only update the only the sections in questions vertices. Any chance I could see the wave examples code?

    Leave a comment:


  • replied
    [MENTION=141752]Koderz[/MENTION]: I believe I've found another bug. It seems like the runtime mesh isn't updating the nav mesh like a procedural mesh does. I created an actor with a runtime mesh using the same blueprint shown in the picture from my earlier post and then created a second actor using a procedural mesh, again using the same blueprint. I then added a nav mesh bounds volume to the level and set it to dynamically update. When you drop the actor on the level with the procedural mesh, every works correctly. The nav mesh updates and takes the procedural mesh into account. However when you drop the actor with the runtime mesh on the level, the nav mesh does not update at all. Even when you force it to update it doesn't take the runtime mesh into account.

    Leave a comment:


  • replied
    Originally posted by wilberolive View Post
    OK, so I worked it out. For anyone else that comes along wondering how to do this, I eventually worked out that SetMaterial() actually defines the material for each mesh section. Therefore, if you want a runtime mesh with two materials, then you create the first mesh section and set its material in ElementIndex 0. Then create the second mesh section and set its material in ElementIndex 1.

    [MENTION=141752]Koderz[/MENTION]: I believe I've found some sort of bug to do with shadowing. If you create a runtime mesh in the construction script of an actor blueprint, then it casts shadows fine. However, if you create the runtime mesh in BeginPlay (or anywhere else for that matter), then it no longer casts any shadows. It will receive shows ok, but just not cast them any more. Below is my very basic blueprint showing what I'm doing. I've tested this same blueprint with a procedural mesh component instead and shadows work fine in both cases. It is just with the runtime mesh component that it won't cast shadows if the mesh section is not created in the construction script.
    Sorry about not getting back to you. Been swamped in class work, and just now really getting back into work on the RMC.

    First, you are correct on how the materials/sections interact so yes just align the section id with the material id when you want multiple mesh sections with different materials.

    Second, I will check into that bug, I was able to reproduce it so will look through that here soon.

    Leave a comment:


  • replied
    OK, so I worked it out. For anyone else that comes along wondering how to do this, I eventually worked out that SetMaterial() actually defines the material for each mesh section. Therefore, if you want a runtime mesh with two materials, then you create the first mesh section and set its material in ElementIndex 0. Then create the second mesh section and set its material in ElementIndex 1.

    [MENTION=141752]Koderz[/MENTION]: I believe I've found some sort of bug to do with shadowing. If you create a runtime mesh in the construction script of an actor blueprint, then it casts shadows fine. However, if you create the runtime mesh in BeginPlay (or anywhere else for that matter), then it no longer casts any shadows. It will receive shows ok, but just not cast them any more. Below is my very basic blueprint showing what I'm doing. I've tested this same blueprint with a procedural mesh component instead and shadows work fine in both cases. It is just with the runtime mesh component that it won't cast shadows if the mesh section is not created in the construction script.

    Click image for larger version

Name:	runtimemesh.png
Views:	1
Size:	159.8 KB
ID:	1114146

    Leave a comment:


  • replied
    Great. Looking forward to the update. I have since been converting more of my UInstancedStaticMeshComponents to URuntimeMeshComponents and the performance gain is amazing.

    The only hard part is that I have to hand build the meshes by laying out vertices and triangles in code instead of being able to import a static mesh and use it with UInstancedStaticMeshComponent. I've looked into possibly reading the vertex and triangle information from a static mesh and then duplicating it over and over again as needed in the URuntimeMeshComponent. However it appears as though that can only be done by importing specific PhysX libraries which I'd prefer to avoid doing. Its not the end of the world as my meshes are fairly simplistic.

    However there is one problem I've come up against that I haven't been able to find a work around for and I'm afraid URuntimeMeshComponent may not support it. When creating a regular static mesh in 3ds max for example, you can specify a MaterialId for each face of the mesh. This information is then imported into UE4 (in the FBX file). So if your static mesh uses two MaterialId's for example, then when you view that static mesh in the UE4 editor, it has two Material Slots. You can specify a material for each slot and the static mesh will apply those materials to its faces based on the MaterialId. This works great with UInstancedStaticMeshComponent and I've been using it extensively to texture faces of the mesh differently. However URuntimeMeshComponent doesn't appear to support this. The FRuntimeMeshVertexSimple struct doesn't have any option to pass in an array of int32 MaterialId's (i.e. one for each face). Is this a known limitation with URuntimeMeshComponent or just something that hasn't been thought of yet?

    What I find interesting is that URuntimeMeshComponent has the following function, virtual void SetMaterial(int32 ElementIndex, UMaterialInterface* InMaterial). Note that it takes in an int32 ElementIndex, which is the index of the material slot (i.e. MaterialId) to set the material for. So the base class that URuntimeMeshComponent derives from must support this feature??? So would it be possible to pass in an array of int32 MaterialId in the FRuntimeMeshVertexSimple struct and apply it to the base mesh so it knows which material slot to use for which face??? I really hope so!

    Leave a comment:


  • replied
    Originally posted by wilberolive View Post
    [MENTION=141752]Koderz[/MENTION]: I just wanted to say thanks for building this plugin. It has helped me immensely. I was struggling to render a lot of simple meshes and update them quickly using UInstancedStaticMeshComponent, which is horrendously slow to update (in the order of whole seconds). I wasted a couple of days trying to solve the performance issues until I stumbled across this thread and thought I'd give it ago. Within a couple of hours I had the system fully swapped out to use your RuntimeMeshComponent and it now renders and updates 10,000 meshes in real time without even a hiccup on the FPS. I'm sitting on a solid 120 FPS, even with constant updates to the generated mesh. Thank you again so much. I really hope you have the time to continue to refine this amazing plugin.

    The only thing I've had a problem with is SetMeshSectionVisible() doesn't seem to work correctly. It works the first time I call it when creating the mesh, but then after that it doesn't work any more. I hooked it up to a keyboard key so I could toggle the mesh section visible, but it doesn't do anything. The mesh section just stays set to whatever visible setting it was set to when I first created it. Are you supposed to update the whole mesh section between calls to SetMeshSectionVisible() or something like that? I've resulted to just calling SetActorHiddenInGame() on the whole actor since I only have one mesh section anyway.

    I wasn't aware of a problem with SetMeshSectionVisible, will look into that. Turning the actor hidden works, but there's a good/bad part to that depending how often you do it. When the actor is hidden it will remove the mesh from the GPU saving vram, but if you change that visibility too frequently then you'll continually resend the mesh data to vram.

    I still expect to push a pretty good size update within probably 2 weeks, so it's definitely still being worked on! Glad to hear it was useful!

    Leave a comment:


  • replied
    [MENTION=141752]Koderz[/MENTION]: I just wanted to say thanks for building this plugin. It has helped me immensely. I was struggling to render a lot of simple meshes and update them quickly using UInstancedStaticMeshComponent, which is horrendously slow to update (in the order of whole seconds). I wasted a couple of days trying to solve the performance issues until I stumbled across this thread and thought I'd give it ago. Within a couple of hours I had the system fully swapped out to use your RuntimeMeshComponent and it now renders and updates 10,000 meshes in real time without even a hiccup on the FPS. I'm sitting on a solid 120 FPS, even with constant updates to the generated mesh. Thank you again so much. I really hope you have the time to continue to refine this amazing plugin.

    The only thing I've had a problem with is SetMeshSectionVisible() doesn't seem to work correctly. It works the first time I call it when creating the mesh, but then after that it doesn't work any more. I hooked it up to a keyboard key so I could toggle the mesh section visible, but it doesn't do anything. The mesh section just stays set to whatever visible setting it was set to when I first created it. Are you supposed to update the whole mesh section between calls to SetMeshSectionVisible() or something like that? I've resulted to just calling SetActorHiddenInGame() on the whole actor since I only have one mesh section anyway.

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    As [MENTION=5560]Korcan[/MENTION] said, you can replicate the raw meshes but you'll have to do it yourself for now. It's a planned feature for the RMC but it will likely be a while before I touch it as to be honest it falls behind most of the other wanted features since I need several of the others for my own project.

    Since you mentioned voxel directly... Replicating the meshes is a valid option, but depending on the type of voxel you're working with, replicating the voxel data can frequently be smaller and therefor lower bandwidth due to the type of data being easy to compress. Think about it this way, each FRuntimeMeshVertexSimple is 32 bytes.. Naive mesh generation of Minecraft like blocks needs 4 vertices (128 bytes) + 6 indices (4 bytes each so another 24 bytes) for each visible face whereas usually you can represent blocks in 1-2 bytes depending on what you're doing. Smooth voxel is another story and depends heavily on the surface extraction algorithm used.
    Ah, very true. I tried using Unreal's compression and was able to compress a TArray containing 32^3 uint8s down from 32768 bytes to 58. I guess this also debunks my idea that having the server rely on RPC's to the client to change blocks in an array.
    I still need to think about how to "nicely" replicate the data to the clients though - Unreal's replication system is still new to me.

    Recently I tried PolyVox, but am not sure if I like using it with Unreal or not yet... this also adds more replications woes (for me anyways).

    Leave a comment:


  • replied
    Originally posted by S0rn0 View Post
    This is wonderful!

    Can I replicate this from the server to clients? I have built a dodgy system using TCP to send voxel data to clients, but if I could just replicate the mesh and have the server handle all of the heavy lifting...


    As [MENTION=5560]Korcan[/MENTION] said, you can replicate the raw meshes but you'll have to do it yourself for now. It's a planned feature for the RMC but it will likely be a while before I touch it as to be honest it falls behind most of the other wanted features since I need several of the others for my own project.

    Since you mentioned voxel directly... Replicating the meshes is a valid option, but depending on the type of voxel you're working with, replicating the voxel data can frequently be smaller and therefor lower bandwidth due to the type of data being easy to compress. Think about it this way, each FRuntimeMeshVertexSimple is 32 bytes.. Naive mesh generation of Minecraft like blocks needs 4 vertices (128 bytes) + 6 indices (4 bytes each so another 24 bytes) for each visible face whereas usually you can represent blocks in 1-2 bytes depending on what you're doing. Smooth voxel is another story and depends heavily on the surface extraction algorithm used.
    Last edited by Koderz; 07-26-2016, 02:53 PM.

    Leave a comment:

Working...
X