Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

    #76
    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.
    Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

    Comment


      #77
      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

      Comment


        #78
        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?

        Comment


          #79
          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?

          Comment


            #80
            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.
            Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

            Comment


              #81
              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.
              Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

              Comment


                #82
                Originally posted by Koderz View Post
                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
                i just think there's a queue for updates and new marketplace content. plus i also think the launcher needs to handle a lot of content and servers need updating to accept that.

                Comment


                  #83
                  For all of you wanting to update to 4.13 using the marketplace installed version. It is coming, but Epic is having a slight technical issue that will take a little time to work through. If you want to go ahead and move to 4.13 you can download the marketplace (or even a newer version) from github at the link below and install it either to your engine plugins folder or your project plugins folder. Instructions for this can be found on the github wiki.

                  https://github.com/Koderz/UE4RuntimeMeshComponent
                  Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                  Comment


                    #84
                    Originally posted by Koderz View Post
                    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.
                    Hey, just checking in to see if v2 is any closer yet? Just curious as I've paused my work with RMC for the moment while I wait. I'm really interested in exploring the SMC -> RMC and Normal/Tangent calculations as these two features alone can save huge amounts of time in building meshes for RMC. I'm also hoping that v2 will solve the shadowing and nav mesh issues I raised earlier. Sorry, not trying to be pushy, just really excited for where this can go and eager to get my hands on it.

                    Comment


                      #85
                      I recently migrated my project to VR on the CV1. I'm noticing a huge delay when I use BeginMeshSectionPositionUpdate vs SetMeshSectionVisible. In the first, I fetch a triangle from a raycast and then grab the local neighbors which are precalculated creating a list of 13 triangles, which I multiply their Z value to move them down and out of the way. This method causes me to cross over the 90 FPS requirement. So instead I use the same method of fetching neighbors only this time I grab the lower subdivision levels and put the grouped lower subdivision levels on their own section on the RMT. So when my raycast hits and fetches the neighbors (sections neighbors) I turn that section off. This cause no delay and is the same number of triangle loops where instead of neighbors per face I'm grabbing per subdivision neighbors and turning the groups of triangles of. Technically its' more triangles because each section is many polygons whereas the original method was only 13 triangles.

                      Comment


                        #86
                        When you update faces in place does it really matter how large the container is (within reason)? For instance I have a container that has 737,280 triangle faces in it. Now I want to move 13 polygons to a new location. My polygons have collision on them. When I move those polygons I see my frame rate dip down (below 90 FPS because I'm in VR). However if I do the same thing on the next subdivision level lower (184,320 triangles), my framerate is fine. It's still only modifying 13 triangles, and the matter in which those triangles are discovered is identical. There's a visible stutter in the CV1 when I use the higher subdivision container. Any ideas how I can improve this?

                        Comment


                          #87
                          Originally posted by Thumper View Post
                          When I move those polygons I see my frame rate dip down (below 90 FPS because I'm in VR).
                          Now I could be off base with this as I'm no expert on the subject. However, I believe that the entire list of vertices needs to be pushed to VRAM regardless of how many you actually change. So it makes sense that a list of ~700k vertices will take more time to send across than a ~200k list. At least my own testing verified this for me, so that's the assumption I'm rolling with for now until corrected.

                          So what I did to get around the problem was to break my world up into multiple RMC's. I used a quad-tree approach to break the world up into even square chunks. Vertices are then assigned to a chunk based on their initial world location. So instead of one RMC with ~700k vertices, you end up with say 16 RMC's with ~40k vertices each. Then when you update a triangle, you are only updating that one chunk. I can now update multiple chunks every frame with no noticeable hit on frame time.

                          Bare in mind that this approach results in 16 draw calls as opposed to 1 draw call. That was an acceptable trade-off for me as I update the chunks frequently. You would need to decide what is acceptable to you based on how often you update.

                          Oh and one more thing... don't try any of this in BP. Stick to C++ for this kind of stuff. Not just for the performance of it, but because BP would get out of control with the math and what not going on.
                          Last edited by wilberolive; 09-18-2016, 09:56 PM.

                          Comment


                            #88
                            First off. Sorry for the delay everyone, I am still working on v2 very slowly, just haven't had much time due to other things going on. I hope to get everything but collision fully finalized this week, not sure about collision as it requires me having more time to work in one consecutive shot then I've had recently.

                            [MENTION=28104]wilberolive[/MENTION] I'll let you know when the normal/tangent work is done and pushed to github! (It's the next thing being pushed once I find one last bug) The smc->rmc conversions are done on github.
                            [MENTION=19211]Thumper[/MENTION]...

                            Wilber is on the right track, so I'll break down the major areas that affect what it sounds like you're trying to do...

                            First up the difference between BeginMeshSectionUpdate/EndMeshSectionUpdate and UpdateMeshSection is that the first allows you to access and edit the RMC's stored version which removes one potentially costly copy operation and also allows you to skip storing it yourself as well.
                            The problem is for both of these paths the next part is identical. When you commit an update either view EndMeshSectionUpdate or implicitly in UpdateMeshSection it copies the entire section and passes is to the render thread, which then locks a GPU buffer and copies that data to the GPU. This means that there's 2 types of impact you'll get from this. first is the obvious time to copy those 2 times, and the second is the time required to lock the GPU buffer. So many tiny buffers updating frequently can be slow dominated by lock time, and giant buffers are slow due to copy time.

                            The other thing that's probably the far bigger factor is collision, and I'd be interested to see what the performance difference is for you with collision off. Unfortunately the PMC and RMC (Currently) have a rather brute force setup for collision. For PhysX (The underlying physics engine) to work with things like static meshes it must first 'cook' them which does a list of things to improve detection performance. The problem is this is slow (like 20+ms slow in some cases) and will very quickly destroy your fps. This is the big thing I'm working on for v2, and hope to have a testable version here pretty quick.
                            The quick breakdown on the collision issue with the PMC/RMC is when you update any 1 section, it will cause that entire PMC/RMC to batch all the sections back together into one giant mesh and send it to the PhysX cooker on the game thread thereby halting your execuation while it cooks.

                            What you can do for now is like wilber said, divide up the mesh, and if you're using collision separate them between multiple RMC's to reduce the collision impact. This will increase draw calls, but it should reduce update times substantially.
                            Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                            Comment


                              #89
                              Originally posted by Koderz View Post
                              I'll let you know when the normal/tangent work is done and pushed to github! (It's the next thing being pushed once I find one last bug) The smc->rmc conversions are done on github.
                              Thanks for the update. Super excited about the work you are doing. I've only been using the v1.2 plugin at the moment as I'm not really familiar with the process of compiling and installing a plugin from GitHub.

                              Comment


                                #90
                                Hi

                                I tried to compile this plugin for PS4 and Linux and it seems like your code has some issues with clang. We implemented some workarounds but you might want to look into it
                                www.dawidniemiec.com

                                Comment

                                Working...
                                X