Announcement

Collapse
No announcement yet.

Runtime Mesh Component - Rendering high performance runtime generated meshes!

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

  • [RELEASED] Runtime Mesh Component - Rendering high performance runtime generated meshes!

    Runtime Mesh Component

    Version 2.0 Released!

    The RuntimeMeshComponent, or RMC for short, is a component designed specifically to support rendering and collision on meshes generated at runtime. This could be anything from voxel engines like Minecraft, to custom model viewers, or just supporting loading user models for things like modding. It has numerous different features to support most of the normal rendering needs of a game, as well as ability to support both static collision for things such as terrain, as well as dynamic collision for things that need to be able to move and bounce around!

    Now, the RMC is very similar in purpose to the ProceduralMeshComponent or CustomMeshComponent currently found in UE4, but it far surpasses both in features, and efficiency! It on average uses half the memory of the ProceduralMeshComponent, while also being more efficient to render, and far faster to update mesh data. This is shown by the ability to update a 600k+ vertex mesh in real time! The RMC is also nearly 100% compatible with the ProceduralMeshComponent, while adding many features above what the PMC offers.


    Current list of features in the RMC
    • Slicer Support!! You can now use the procedural mesh slicer.
    • Collision cooking speed improvements.** (new)
    • High precision normals support (new)
    • Tessellation support (new)
    • Navigation mesh support (new)
    • Fully configurable vertex structure (new)
    • Ability to save individual sections or the entire RMC to disk (new)
    • RMC <-> StaticMeshComponent conversions. SMC -> RMC at runtime or in editor. RMC -> SMC in editor. (new)
    • Normal/Tangent calculation. (new) (will be getting speed improvements soon)
    • Multiple UV channel support (up to 8 channels)
    • Fast path updates for meshes that need to update as fast as frame-by-frame
    • Static render path for meshes that don't update frequently, this provides a slightly faster rendering performance.
    • Collision only mesh sections.
    • 50%+ memory reduction over the ProceduralMeshComponent and CustomMeshComponent
    • Visibility and shadowing are configurable per section.
    • Separate vertex positions for cases of only needing to update the position.
    • Collision has lower overhead compared to ProceduralMeshComponent


    ** The RMC has picked up the collision cooking improvements done in UE4.14. This means that by default you'll see far faster collision updates, but at the cost of a little lower performance collision. You do however have the option to prioritize quality, which will slow down updates, but make actual collision detection a little faster

    As a part of V2, there has also been some preliminary work done on threaded cooking. This can help to unblock the game thread from collision with large meshes. This is still a very new part, and not heavily tested or complete. To use this you'll have to use a source build of the engine. More information to come.


    Some requested features that I'm looking into: (These aren't guaranteed to be added)
    • LOD (Potentially with dithering support)
    • Dithered transitions for mesh updates.
    • Mesh sharing, to allow multiple RMCs to have the same copy of the mesh to reduce memory overhead. This is much like how the StaticMeshComponent works.
    • Instancing support.
    • Multiple vertex buffer (In Addition to the current separate position vertex buffer)
    • Mesh replication


    Supported Engine Versions:
    v1.2 supports engine versions 4.10+
    v2.0 supports engine versions 4.12+

    The Runtime Mesh Component should support all UE4 platforms.
    Collision MAY NOT be available on some platforms (HTML5, Mobile)

    Tested Platforms:
    Windows, HTML5
    (Also tested with HTC Vive, and Oculus Rift)


    Downloads:
    Version 2.0 (Without Slicer): https://github.com/Koderz/UE4Runtime...eases/tag/v2.0
    Version 2.0 (With Slicer): https://github.com/Koderz/UnrealEngi...rmcslicer_v2.0 (You will need to be signed into github and be linked to your UE4 account to access this repo)
    Github: https://github.com/Koderz/UE4RuntimeMeshComponent

    If you found the RuntimeMeshComponent to be useful to your project, and would like to contribute to its development, please consider a monetary donation! As a student, working on this in his free time, I would greatly appreciate any contribution! To make a donation, simply click the button below! Thank you for your support!

    Click image for larger version

Name:	btn_donate_LG.gif
Views:	2
Size:	1.7 KB
ID:	1201129




    Examples:
    https://github.com/Koderz/UE4Runtime...ponentExamples

    Documentation:
    https://github.com/Koderz/UE4RuntimeMeshComponent/wiki

    Issues/Help:
    https://github.com/Koderz/UE4Runtime...mponent/issues


    640k vertex animated mesh! (Not great quality gif)


    Convex collision support for movable objects!


    Same familiar API as PMC from Blueprints!


    New Simpler to use API from C++! (Still supports the PMC style API as well!)
    Last edited by Koderz; 11-28-2016, 08:20 PM. Reason: v2.0 released!
    Runtime Mesh Component - Speed/Memory/Feature improved version of the ProceduralMeshComponent and CustomMeshComponent - Version 2.0 Out Now!

  • #2
    Great component here! I've been testing it for some time now and it addresses pretty much all the issues I've been having with the standard PMC.

    I will soon update my mesh examples over to using this and already using it exclusively in my work.
    Sr. Programmer @ CCP Games, Working on VR game "Sparc" (prev. EVE: Valkyrie) | @SiggiGG
    Check out my procedural mesh examples

    Comment


    • #3
      This looks a really interesting and useful tool, nice work!
      Hevedy - Image Tools: https://hevedy.itch.io/imagetools

      Comment


      • #4
        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

        Comment


        • #5
          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.

          https://github.com/Koderz/UE4Runtime...project-in-CPP
          Runtime Mesh Component - Speed/Memory/Feature improved version of the ProceduralMeshComponent and CustomMeshComponent - Version 2.0 Out Now!

          Comment


          • #6
            Ah ok, Ill keep an eye on this thread for the pre-built versions as I am not really a coder thanks Koderz

            Comment


            • #7
              Nice ! This will be of great help ! Thanks.

              Comment


              • #8
                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!
                Last edited by RennJan; 06-11-2016, 05:13 PM.

                @agamedevguy twitter
                Renn Farnell Website

                Comment


                • #9
                  Originally posted by RennJan View Post
                  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.
                  Runtime Mesh Component - Speed/Memory/Feature improved version of the ProceduralMeshComponent and CustomMeshComponent - Version 2.0 Out Now!

                  Comment


                  • #10
                    Originally posted by Koderz View Post
                    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.

                    @agamedevguy twitter
                    Renn Farnell Website

                    Comment


                    • #11
                      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).
                      Last edited by Inf1nite; 06-13-2016, 03:54 PM. Reason: Findings

                      Comment


                      • #12
                        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?

                        Comment


                        • #13
                          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
                          Last edited by Philippe St-Amand; 06-14-2016, 04:06 PM.

                          Comment


                          • #14
                            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!
                            Lead Programmer - UE4 Animation/Physics/Audio Team - Epic Games
                            Twitter: @EpicJamesG

                            Comment


                            • #15
                              Originally posted by JamesG View Post
                              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.
                              Runtime Mesh Component - Speed/Memory/Feature improved version of the ProceduralMeshComponent and CustomMeshComponent - Version 2.0 Out Now!

                              Comment

                              Working...
                              X