Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

    #31
    Wow, great thing you're making!
    Just remembering old Carmageddon with ability to smashing cars by every vertices.
    Do you have any metrics how slower RMC is than SMC? Rendering, transformation?
    Hope Epics will support your work and you and your work will not go to shadow.

    Comment


      #32
      [MENTION=141752]Koderz[/MENTION] - Make a PR whenever you think you have reached a good point. Things like PMC->SMC really shouldn't be too hard for me to fix, even if you haven't done them yet. It probably will take a while to review, as your changes sound pretty major, but it sounds like some good wins too. I'll probably need some input from the Rendering Team as well.

      I already had it on my list for 4.13 to look at cooking performance and tesselation for PMC, so I'm very interested to know what you find out there! Maybe we do one PR soon with the basics, and then a further one which are those changes later on.
      Lead Programmer - UE4 Animation/Physics/Audio Team - Epic Games
      Twitter: @EpicJamesG

      Comment


        #33
        Originally posted by JamesG View Post
        [MENTION=141752]Koderz[/MENTION] - Make a PR whenever you think you have reached a good point. Things like PMC->SMC really shouldn't be too hard for me to fix, even if you haven't done them yet. It probably will take a while to review, as your changes sound pretty major, but it sounds like some good wins too. I'll probably need some input from the Rendering Team as well.

        I already had it on my list for 4.13 to look at cooking performance and tesselation for PMC, so I'm very interested to know what you find out there! Maybe we do one PR soon with the basics, and then a further one which are those changes later on.

        I'm just finishing up a couple things related to my personal project over the weekend and I have finals this week, but then I'll try to tackle the up-convert on load, and a couple other minor things I want to add pretty quick then I guess we can start there! I kind of want to improve the serialization in general as currently it will only handle sections made via the old PMC style API. At this point it's been used by quite a few people and appears solid (I did find a memory leak since V1 that I have since fixed). Currently it's a feature complete version of the PMC (except those utilities and things in the BP function library)... It's definitely major changes, I didn't go into this trying to keep much from the PMC. I just tried to mimic it's interface and functions, but structurally it's similar, but a bit more complex. I'll let you know when I'm ready, probably be 2-3 weeks would be my guess.

        I remember the settings you where talking about in the pmc question I asked on the AH where you mentioned exposing the cooker config options, what else where you thinking about? I'd be more than willing to try to do whatever changes I need to do within whatever idea you/Epic has and submit them back if it helps to get it done quicker as I know that's just one of a list of things you/Epic are trying to do. I'll probably dig into collision for real Monday, so I'll have a better idea after that but...

        From my preliminary look a couple weeks back I figured to attempt to make the cooker callable from alternate threads and just let the PMC/RMC store a copy of the result and let the current path that happens when you invalidate the mesh use an extended version of the IInterface_CollisionDataProvider and return the cooked data instead of the raw mesh. That lets me offload the cooker entirely to a different thread, but it doesn't take advantage of some of what Ales Borovicka was saying about being able to bypass the serialization that's currently done. It would however let the RMC/PMC have almost direct control over the cooker and its configuration and let it pull it out of the GT. The serialization might still add some unnecessary time/work, but that at least gets the primary work moved and looked to be relatively simple way to do it compared to some of the alternatives. That's all based off what I remember from a few weeks back, and I haven't dug into it super deeply yet to see exactly how all parts fit together. That also didn't assume that it would ever be used by more than just me, but if I'm going to do it and it's reasonable to give that back since I'm sure others can use it then I'm more than willing to go a different route.
        Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

        Comment


          #34
          Cheers for the work on this, been in touch on Slack with you about it.

          Just updated my terrain plugin to use the RuntimeMeshComponent, just a straight switch so far, will start looking into the new options now

          https://forums.unrealengine.com/show...orld-Generator

          Comment


            #35
            One change that needs to be made to cooking is to remove the cleaning step. That can change the vertex count, which breaks the 'fast update' path for collision (UpdateMeshSection), and should also speed things up a bit. Threading the cooking is an option, but I think its worth getting it as fast as possible single-threaded first, as making it async will add a lot of complexity!
            Lead Programmer - UE4 Animation/Physics/Audio Team - Epic Games
            Twitter: @EpicJamesG

            Comment


              #36
              Originally posted by JamesG View Post
              One change that needs to be made to cooking is to remove the cleaning step. That can change the vertex count, which breaks the 'fast update' path for collision (UpdateMeshSection), and should also speed things up a bit. Threading the cooking is an option, but I think its worth getting it as fast as possible single-threaded first, as making it async will add a lot of complexity!
              I definitely agree that speeding it up on single thread needs to happen first and is what I plan to dig into later today. One thing I'll mention with the fast update path you brought up is there's a way to keep the cleaning an get that from what I know. IIRC the cooker can output a face remapping table so that as long as you don't update the triangles you could quickly forward map the vertices into the ones PhysX needs and continue to use that path as even doing that should be far faster than involving the full cooker, but also give the best collision performance. With that said I think the best solution would be to allow you to configure your way into and out of that part so if you want super fast updates and are fine with degrading collision speed a little then disable cleaning, but if you want quick updates and fastest collision then cook on create get and store the remap table then on update remap the vertices and use the same path that you're wanting to use in update.

              Edit: James, I looked into tessellation yesterday and it appears nothing really has to change about the RMC/PMC to support PN. The problem is the helper someone mentioned in the engine to calculate it appears to be in a developer/editor module that I'm not sure can be linked at runtime. Internally it appears to just call the nvidia tessellation library helpers so I could re-implement it depending directly on that library but wanted to see if we could link that at runtime instead of recreating it?
              Last edited by Koderz; 06-20-2016, 04:34 PM.
              Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

              Comment


                #37
                Runtime Mesh Component keeps shooting my (test-)project: when I dublicate a blueprint containing RTM and then doubleclick to open the blueprint, the engine crashes with this report:

                -------------------------------------



                "Assertion failed: Vertices.Num() > 0 && 'Vertices length must not be 0.' [File:C:\..\Documents\Unreal Projects\ULNExample\Plugins\RuntimeMeshComponent_v1.0\Source\

                KERNELBASE
                UE4Editor_Core
                UE4Editor_Core
                UE4Editor_Core
                UE4Editor_RuntimeMeshComponent!URuntimeMeshComponent::CreateMeshSection() [c:\..\documents\unreal projects\ulnexample\plugins\runtimemeshcomponent_v1.0\source\private\runtimemeshcomponent.cpp:850]
                UE4Editor_RuntimeMeshComponent!URuntimeMeshComponent::CreateMeshSection_Blueprint() [c:\..\documents\unreal projects\ulnexample\plugins\runtimemeshcomponent_v1.0\source\private\runtimemeshcomponent.cpp:948]
                UE4Editor_RuntimeMeshComponent!URuntimeMeshComponent::execCreateMeshSection_Blueprint() [c:\..\documents\unreal projects\ulnexample\plugins\runtimemeshcomponent_v1.0\source\public\runtimemeshcomponent.h:62]
                UE4Editor_CoreUObject
                UE4Editor_CoreUObject
                UE4Editor_CoreUObject
                UE4Editor_CoreUObject
                UE4Editor_CoreUObject
                UE4Editor_CoreUObject
                UE4Editor_Engine
                UE4Editor_Engine
                UE4Editor_Engine
                UE4Editor_Engine
                UE4Editor_Engine
                UE4Editor_Engine
                UE4Editor_Engine
                UE4Editor_Kismet
                UE4Editor_Kismet
                UE4Editor_UnrealEd
                UE4Editor_UnrealEd
                UE4Editor_UnrealEd
                UE4Editor
                UE4Editor
                UE4Editor
                UE4Editor
                UE4Editor
                kernel32
                ntdll

                -------------------
                After restarting, the blueprint is gone from the content browser, even though the files are still in the project folders.

                Comment


                  #38
                  [MENTION=43854]Stoon82[/MENTION] I'm not quite sure I understand what you're attempting to do. That assert is when you pass an empty vertices array to CreateMeshSection since it can't handle that safely. I need to switch those over to log errors in editor though instead of just assert crashing the engine...

                  Let me know more what you're trying to do, or if you can recreate it in a little test project and share that, and I'll try to figure out why it did that.
                  Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                  Comment


                    #39
                    It's probably exactly that... I'm doing all the work in the blueprint's construction script as of now: create the vertex-array, index-array, add runtime mesh component, create mesh section.
                    But I have the array creation behind a boolian-branch (if initialize_mesh_data == true, add vertecies to array)... so when I duplicate the BP, the array is still empty and the RMC crashes the engine and the BP is taken from the content browser. It's not too hard to get back, but actually, I can't edit it, since every time I open it, the engine crashes again. recreating that shouldn't be too hard, if still neccessary.
                    But after all, I didn't want to be all that negative: I love the procedural mesh component, and from all I could try and see, the runtime mesh component works a treet (besides the mentioned effect) and adds even more speed and flexibility.

                    If someone knows how to make and octree-database on server side to stream data to the client, the step to have something like midgen's CashGen Plugin and add editable landscape like here (https://www.youtube.com/watch?v=yTRrv4lBVyc) with overhangs and cliffs.

                    Comment


                      #40
                      Another question though:
                      I had trouble creating an array of 'color structur' from a BP and it doesn't allow for feeding in an array of linear colors; the same goes for procedural mesh component. I could be totally of the track here, but I tried quite some time to find a workaround and never got it to work. Any advice anyone?

                      Comment


                        #41
                        Originally posted by Stoon82 View Post
                        It's probably exactly that... I'm doing all the work in the blueprint's construction script as of now: create the vertex-array, index-array, add runtime mesh component, create mesh section.
                        But I have the array creation behind a boolian-branch (if initialize_mesh_data == true, add vertecies to array)... so when I duplicate the BP, the array is still empty and the RMC crashes the engine and the BP is taken from the content browser. It's not too hard to get back, but actually, I can't edit it, since every time I open it, the engine crashes again. recreating that shouldn't be too hard, if still neccessary.
                        But after all, I didn't want to be all that negative: I love the procedural mesh component, and from all I could try and see, the runtime mesh component works a treet (besides the mentioned effect) and adds even more speed and flexibility.

                        If someone knows how to make and octree-database on server side to stream data to the client, the step to have something like midgen's CashGen Plugin and add editable landscape like here (https://www.youtube.com/watch?v=yTRrv4lBVyc) with overhangs and cliffs.
                        I can add editor only conditions to just log an error and bail instead of assert crashing here later on tonight, that will let you in to edit it without crashing.

                        Worth of your other question with the octree-database, it's not easy to stream large binary data in ue4's networking from everything I've seen. If you're around the Unreal Slackers chat you can find me, I'm working on things that might be somewhat similar to what you're wanting.

                        Also, while I don't really use BP functions for the RMC/PMC the PMC was updated not too long ago to use LinearColors in BP saying that the regular color didn't work so I stuck with that in the RMC.
                        Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                        Comment


                          #42
                          [MENTION=141752]Koderz[/MENTION] this is an awesome plugin! thanks for releasing it for free
                          I'm using it for an interactive fluid surface which needs a buffer of the previous vertex positions so this is pretty great for this sort of thing

                          Is there any chance you can look into tessellation? It's probably the only missing feature I need!

                          4.10 Update! -> [Community Project] WIP Weather & Ocean Water Shader
                          WIP Interactive Water Shader, WIP 2D Water Sim
                          WIP FFT Ocean w/ Foam, Quad-tree Infinite Ocean LOD

                          Comment


                            #43
                            Originally posted by TK-Master View Post
                            [MENTION=141752]Koderz[/MENTION] this is an awesome plugin! thanks for releasing it for free
                            I'm using it for an interactive fluid surface which needs a buffer of the previous vertex positions so this is pretty great for this sort of thing

                            Is there any chance you can look into tessellation? It's probably the only missing feature I need!


                            I do plan to look into that here soon. IIRC from my quick research a while back it requires adjacency info in the index buffer which there's a utility function in the engine to calculate but I think it's currently only in editor builds. So you can probably use it right now in editor, but since we can't link editor modules at runtime we'll likely have to get Epic to allow it to be in packaged versions. I might look into it more in the next few days assuming I wrap up my collision work soon, which has been slow going due to 15-20 minute re-compiles of half the engine any time I breathe in the direction of a header...


                            [MENTION=1374]JamesG[/MENTION], just wanted to check that you got the stack trace and other information I sent you regarding the physx crash? Hopefully in the next couple days I'll have a working setup for multi threaded cooking. Also as a part of the statement above, any chance we could get BuildStaticAdjacencyIndexBuffer from the MeshUtilities (assuming that really is what's needed for that) in a way we could use it in a packaged, non-editor build? Or should I just re-implement it in the RMC, since all it's really doing is wrapping the nvidia tessellation library?
                            Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                            Comment


                              #44
                              Koderz, this is some great work! Thank you for the amazing contribution.

                              Quick question for you regarding materials, a friend is trying to create some procedurally generated terrain using cubes (for the moment) and is having a hard time deciding how to apply several materials for each type. I suggested a texture atlas, but she would much rather create the materials individually.

                              Any suggestions I could pass along?

                              Comment


                                #45
                                Originally posted by S0rn0 View Post
                                Koderz, this is some great work! Thank you for the amazing contribution.

                                Quick question for you regarding materials, a friend is trying to create some procedurally generated terrain using cubes (for the moment) and is having a hard time deciding how to apply several materials for each type. I suggested a texture atlas, but she would much rather create the materials individually.

                                Any suggestions I could pass along?
                                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.
                                Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 3.0 Out Now!

                                Comment

                                Working...
                                X