Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

    #16
    Merging back to the Engine would be awesome!

    There could still be the need for a more rapidly evolving side project to test new features. but for mainstream usage official in-engine component is best.

    Edit: all your above reason to wait before merging are valid. Basically, I think you should wait until you do not much more development (not when you have no more ideas!) that is, when it stabilize
    Last edited by SRombauts; 06-15-2016, 02:34 AM.
    [Gamedev programmer at Darewise (Paris) - We are hiring]
    UE4 Git LFS 2.x Source Control Plugin 2.12-beta for UE4.22 - (v1 integrated by default in Beta status since UE4.7)
    UE4 Plastic SCM Source Control Plugin (1.4.5 for UE4.22)

    Comment


      #17
      I'd also love to see these changes in the engine, I don't see any reason to use the standard RMC anymore.

      But like other people here I'm also concerned by the release schedule of new features, at least while the component is still maturing.
      Programmer at Klang Games | Ex-CCP (EVE Valkyrie / Sparc) | @SiggiGG
      Check out my procedural mesh examples

      Comment


        #18
        Thanks for the quick reply!

        What you say certainly makes sense, I wouldn't want to impede your ability iterate quickly and get improvements out to the community. But it seems like a lot of the work you have done would improve ProceduralMeshComponent for everyone, even if it lags behind your 'cutting edge' module.

        I think the serialization problem you mention is solvable with some backwards compat code (keep the old structs around for old content, but convert on load).

        I'm interested to hear how the changes to improve cook times go.

        Do let us know when you get to a point that you think it is worth sending us some changes to merge into PMC.

        James
        Lead Programmer - UE4 Animation/Physics/Audio Team - Epic Games
        Twitter: @EpicJamesG

        Comment


          #19
          Hmmm... I was thinking of migrating Eden from PMC to RMC but will make things complicated if I want to try and sell Eden down the track?

          Comment


            #20
            There is also another thing to take into consideration before doing a Pull Request: it takes a lot of times (for everyone involved) to prepare/clean/document, then to follow/update...

            So you have to take your time, even if just to avoid doing another PR a month after that with some more features.

            Cheers, and thanks again Koderz!
            [Gamedev programmer at Darewise (Paris) - We are hiring]
            UE4 Git LFS 2.x Source Control Plugin 2.12-beta for UE4.22 - (v1 integrated by default in Beta status since UE4.7)
            UE4 Plastic SCM Source Control Plugin (1.4.5 for UE4.22)

            Comment


              #21
              Originally posted by JamesG View Post
              Thanks for the quick reply!

              What you say certainly makes sense, I wouldn't want to impede your ability iterate quickly and get improvements out to the community. But it seems like a lot of the work you have done would improve ProceduralMeshComponent for everyone, even if it lags behind your 'cutting edge' module.

              I think the serialization problem you mention is solvable with some backwards compat code (keep the old structs around for old content, but convert on load).

              I'm interested to hear how the changes to improve cook times go.

              Do let us know when you get to a point that you think it is worth sending us some changes to merge into PMC.

              James

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

              Comment


                #22
                Originally posted by ioFlow Studios View Post
                Hmmm... I was thinking of migrating Eden from PMC to RMC but will make things complicated if I want to try and sell Eden down the track?

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

                Comment


                  #23
                  Click image for larger version

Name:	excellent.gif
Views:	1
Size:	544.5 KB
ID:	1108391
                  1234567890

                  Comment


                    #24
                    Nice work!
                    I have a question for you: UE4 PMC does not work with PN Triangles tessellation, because there is no way of passing some needed data to the shader (see https://answers.unrealengine.com/que...-for-upro.html ). Is there any chance your Runtime Mesh Component might support this in the near future?

                    Comment


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

                      Comment


                        #26
                        Originally posted by francesco.cat View Post
                        Nice work!
                        I have a question for you: UE4 PMC does not work with PN Triangles tessellation, because there is no way of passing some needed data to the shader (see https://answers.unrealengine.com/que...-for-upro.html ). Is there any chance your Runtime Mesh Component might support this in the near future?
                        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.


                        Originally posted by JamesG View Post
                        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.
                        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.
                        Last edited by Koderz; 06-16-2016, 12:41 PM.
                        Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                        Comment


                          #27
                          Originally posted by Koderz View Post
                          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.
                          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: https://forums.unrealengine.com/show...l=1#post266026

                          Comment


                            #28
                            Originally posted by francesco.cat View Post
                            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: https://forums.unrealengine.com/show...l=1#post266026
                            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.
                            Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                            Comment


                              #29
                              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 Koderz))
                              Last edited by Swinny_; 06-16-2016, 03:19 PM.

                              Comment


                                #30
                                Originally posted by bswinbanks View Post
                                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 Koderz))
                                Thank you!

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

                                Comment

                                Working...
                                X