Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

    #46
    Originally posted by Koderz View Post
    While I definitely get the desire for doing separate materials, it's likely going to limit you rather quickly. The problem with the RMC, and well any component for this, is that to do separate materials you need separate draws. For the RMC that translates into separate sections for each material. If you have a couple materials, you're probably OK, but if you have tens or hundreds of materials, you're going to get very poor performance for any decent scale voxel. The problem is pretty simple if you have 100 chunks with 1 material you have 100 draw calls, if you have 2 materials you have 200 draw calls, so the count goes up very rapidly and it won't take long at that rate to start limiting yourself by the draw call counts.

    Atlasing is one way to get around it, another way is to use texture arrays. I have an open PR ( https://github.com/EpicGames/UnrealEngine/pull/2340 ) for that to the engine but have no idea if/when it would be merged. So if you want to use a source build of the engine you can find them in my repo ( https://github.com/Koderz/UnrealEngine ) but that would require building from source.

    With either atlas or texture arrays you can use additional textures to supply the other PBR info/normals etc. The only time I split apart the mesh in my system is for things like foliage and water which need a completely different render model.
    You basically said word for word what I was thinking. I will be looking into the texture arrays for sure that could be a nicer approach.
    It looks like they are getting a bit of attention and a merge will be happening sooner than later.

    Thanks for your very detailed answer.

    Comment


      #47
      Originally posted by S0rn0 View Post
      You basically said word for word what I was thinking. I will be looking into the texture arrays for sure that could be a nicer approach.
      It looks like they are getting a bit of attention and a merge will be happening sooner than later.

      Thanks for your very detailed answer.
      They're probably the best approach for block voxel, and yeah I'm glad it looks like they're about to be merged.

      That PR has been a long time coming. That PR was started by Hilmar back in October, and I cleaned it up/bugfixed it and maintained it for the past couple months so I'm happy to see them looking into it now.
      Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

      Comment


        #48
        After downloading the Example project from Git Hub I'm getting the following error. I have latest version of 4.12 and vs installed.

        Click image for larger version

Name:	1.png
Views:	1
Size:	8.9 KB
ID:	1112201
        Advanced 3d Footprints | Videos | Open Source Mine Sweeper

        Comment


          #49
          Hey [MENTION=29116]NanoVoxel[/MENTION]: Did you download the github repo itself (either as zip or through git)? If so the RMC is a submodule that you have to update if you pulled through git, or you have to get it from the main repo and put it in the plugins folder if you just downloaded it as a zip. The other alternative is to get the release zip that should be fully working from the releases page on github.

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

          Comment


            #50
            This is super cool, bookmarked.
            | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

            Comment


              #51
              Originally posted by Koderz View Post
              Hey [MENTION=29116]NanoVoxel[/MENTION]: Did you download the github repo itself (either as zip or through git)? If so the RMC is a submodule that you have to update if you pulled through git, or you have to get it from the main repo and put it in the plugins folder if you just downloaded it as a zip. The other alternative is to get the release zip that should be fully working from the releases page on github.

              https://github.com/Koderz/UE4Runtime...mples/releases
              That worked thank you!!!
              Advanced 3d Footprints | Videos | Open Source Mine Sweeper

              Comment


                #52
                [MENTION=141752]Koderz[/MENTION] Thank you for this! I'll give it a chance to replace PMC ASAP on my project!

                Comment


                  #53
                  Does anybody know if this new upcoming feature would provide functionality similar to this component? If so, what would be the differences/trade-offs?

                  Comment


                    #54
                    Originally posted by Yanko Yankov View Post
                    Does anybody know if this new upcoming feature would provide functionality similar to this component? If so, what would be the differences/trade-offs?

                    If that card is referring to what I think it is, then it's a completely different purpose. I believe that's meant for actual animated objects imported from other tools, whereas the RMC (and the PMC it's meant to replace) are meant for being able to generate meshes at runtime to do things like procedural terrain, buildings, objects, or to be able to load a mesh from a raw model file at runtime when you don't have editor support. The RMC is just efficient enough that it can do some limited real-time vertex animation like that sine/cosine wave powered plane in my original example.
                    Last edited by Koderz; 07-22-2016, 02:27 PM.
                    Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                    Comment


                      #55
                      Thanks Koderz, that's helpful! I've always thought of your component in the context of my particular use case, which is closer to the sine powered plane.
                      Your response puts things back into proper perspective for me. Also thanks for your awesome work on this project!

                      Comment


                        #56
                        As a heads up to everyone currently using the RMC or thinking about using it!

                        First, the RMC is now on the Marketplace, and is now also downloading correctly for those of you who attempted to download it when it first went up and were unable to. The marketplace version is the same as the current released version on github (not the master branch source).

                        Version 2 should be out in about 2-3 weeks if all goes to plan, with some of the following either already in github, or showing up incrementally over the next couple weeks. Version 2 will, hopefully, bring the remaining tools from the PMC over including normal/tangent calculation, RMC <-> StaticMeshComponent conversions, and hopefully tessellation support. There's also a decent chance that it will have the initial round of improvements for collision cooking. Unfortunately though as those have taken multiple engine changes, it will require a source build of the engine at least until Epic hopefully merges part/all of it back into mainline UE. So far the collision cooker can be operated in its current game thread only mode but allow for some control over the quality of the cook cycle. There's a trade off between quality and speed of cooking, with lower quality cooked meshes being a little slower in the actual collision detection but this alone allows it to run up to ~6x faster. It should also support nearly full multithreaded cooking to move most of the work off the game thread.
                        Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                        Comment


                          #57
                          Originally posted by Koderz View Post
                          • Normal/Tangent Calculation (Like the PMC's current helper, but hopefully faster)
                          This. This one currently with PMC takes the most of the time to generate a mesh. I don't really need tangents there, just normals, is it possible to make a checkbox to skip the generation of one of the two in the Normal/Tangent Calculation helper? Just a hint...

                          Comment


                            #58
                            Originally posted by Z-enzyme View Post
                            This. This one currently with PMC takes the most of the time to generate a mesh. I don't really need tangents there, just normals, is it possible to make a checkbox to skip the generation of one of the two in the Normal/Tangent Calculation helper? Just a hint...
                            Normal/Tangent calculation in the PMC is slow due to needing adjacency information for smooth normals. Currently the helper on the PMC does this by brute force search which means O(n^2) "efficiency." I could definitely allow it to skip tangents, but the problem is the slow part is finding the adjacency. The only time you can get around that really is if you know each face is independent and doesn't share vertices (think Minecraft where each face is 100% separate) then it can just walk the mesh calculating the surface normal of that triangle.

                            So I think the best option is to allow turning on/off smooth normals first, then possibly turn off tangents. The new one with the RMC should be quite a bit faster but I haven't done tests with it in large meshes yet to really see how much of a difference.


                            Originally posted by Chariots
                            I've checked heightfield lighting system for terrain far shadows, DFAO, and heightfield GI. It is very easy to hook up to it provided you have the height information (and color info for GI, although I didn't try GI in depth). All it needs is a bool and maybe 2 functions (can't remember exactly) to get it working dynamically (it's all in runtime folders without editor defines). Only issue is the scaling settings of distance fields is a bit finicky (put off that for later), but still it works.

                            Are you planning to adding specific geometry modes to the component (like terrain mode for heightfield collision, heightfield GI etc), or would you rather keep it generic? If former, would you be interested in some terrain specific contributions down the line? If latter, would you mind if I release the modifications I've made on a separate repository at some point?

                            Also, thanks for releasing this!
                            I've never really looked into the DFAO or HFGI so not really sure what it would take. If it's practical to setup without hindering the performance in the general case then I'm not opposed to doing it, just not sure what it takes right now. I hadn't thought about specific modes, but I had thought about trying to support heightfield collision.
                            Last edited by Koderz; 07-24-2016, 10:22 AM.
                            Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                            Comment


                              #59
                              [MENTION=577]Chariots[/MENTION] I might look into it at some point, for now I have higher priority things like those listed above for v2. My question though would be how many people could/would really use it. The heightfield collision I might go ahead and try to do as a part of the current collision work depending what it takes to get it running.
                              Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                              Comment


                                #60
                                Originally posted by Koderz View Post
                                Normal/Tangent calculation in the PMC is slow due to needing adjacency information for smooth normals.
                                Okay, got it, and what about the situation, where I convert a static mesh plane to RMC? Then does the adjacency information is being copied as well as I assume.

                                Cause, what I want to achieve is this. Got plane, RMC, offset vertices and recalculate normals as fast as possible. If the adjacency information is cached from the original static mesh plane then it wouldn't be that heavy to calculate, right?

                                Comment

                                Working...
                                X