Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

    Hey [MENTION=141752]Koderz[/MENTION], I'm trying out your Runtime Mesh Component (on 4.15) as performance is critical on what I am doing but I think I found a crash Calling URuntimeMeshLibrary::CalculateTangentsForMesh for a simple plane mesh causes a crash on GetUv() line 786 on RuntimeMeshBuilder.cpp, this is called by line 241 of the same file. It seems it's counting on a second Uv Map but there is none because CalculateTangentsForMesh passes a nullptr to the UV1 argument on the vertex builder.
    My Mesh as only one uv map, but nonetheless even if it had two only the first one is used to calculate normals/tangents so I think this might be a bug.

    As a "workaround" I am using Epic's implementation of CalculateTangentsForMesh which works but the problem is, not only to I not gain the speed upgrade of RMC's function as I have to spend more cycles converting back and forth between the FProcMeshTangent and FRuntimeMeshTangent.

    Maybe you could take a look at it? It might be an easy fix for you as I am sure you know that class like the palm of your hand by now :P

    Comment


      Originally posted by Koderz View Post
      Usually they're pretty quick for updates, but I haven't heard anything back... Wondering if the email failed to go through because now that I look back I don't even have the automated response I usually get from the ticket system it goes too. Just resent it, we'll see how it goes!
      I just checked again then and the epic turtle hasn't moved yet. I'm wondering if there is something wrong, like they aren't receiving any of your communication or something.

      Comment


        Looks like Epic just updated the plugin to 4.15! Thanks Koderz!

        Comment


          Marketplace RMC on UE4.15!

          Originally posted by wilberolive View Post
          I just checked again then and the epic turtle hasn't moved yet. I'm wondering if there is something wrong, like they aren't receiving any of your communication or something.
          Originally posted by Feifox View Post
          Looks like Epic just updated the plugin to 4.15! Thanks Koderz!
          As Feifox already mentioned... The marketplace version of the RMC has been updated to 4.15 as of this afternoon!




          Originally posted by DennyR View Post
          First off, sorry for the double post, but I got it working and I love that I was just able to pop it in for the ProceduralMeshComponent.
          I have a few questions though.

          I am working on a pretty large and complex procedural hex grid terrain.

          It gets pretty complex on the highest LOD level.

          At the moment I have everyting separated into 8x8 chunks to make use of automated frustum culling
          (chunks are actually of variable size, so I can tweak frustum culling vs draw calls)

          It actually blows the ProceduralMeshComponent out of the water in terms of performance. But, the more chunks I add the more it slows down though. Which would be expected but frustum culling should also make sure that the meshes out of the view can just be ignored for the most part.
          So my main question is: how to get the most out of this for large terrains with high poly count (other than a dynamic LOD system - which I am working on atm). Mesh extraction/polygonizing is quite costly and I'd like to implement a multithreaded solution for it, but not sure how the UpdateFrequency thing works.
          Could you give me some hints?
          It's a tradeoff. You're going to have to accept some overdraw and things as the overhead of too many individual chunks will outweigh the speed benefit of not rendering parts. Frustum/occlusion culling are obviously very useful but having 100k draw calls just to have chunks so small as to not have much overdraw or offscreen is going to hurt more than the gain. With my voxel engine I was running variable size chunks based on LOD/distance and it will depend too much on what you're doing for me to give you an accurate balance point.

          There's some things coming in v3 that might help with what you're doing, especially the threading parts, and LOD. I have no real estimate on a release date on that yet, it's coming along, but slowly due to work/school.

          The UpdateFrequency is used internally to control how the rendering is setup. I'm going to slightly oversimplify this but, basically UE4 has a static and dynamic draw path. The static path is generally faster for multiple reasons but it can only be configured when the scene proxy is created, which right now requires a resync of all the the mesh data to the GPU. The dynamic path doesn't require recreating the scene proxy, and instead updates only what's necessary so the updates are faster but the draw speed is a little bit slower. Now, at the GPU memory buffer level, the RMC uses 2 possible configurations, static and dynamic (this doesn't relate to UE4's 2 rendering paths). static buffers are meant to be set and used over and over, whereas dynamic can be set multiple times. That UpdateFrequency flag controls which combination the RMC uses for that section..

          UpdateFrequency::Frequent = Dynamic Render Path + Dynamic Buffers (Use this if you update super frequently, like every frame)
          UpdateFrequency::Average = Dynamic Render Path + Static Buffers (This is the happy middleground if you need to update some sections sometimes but not all of them at once)
          UpdateFrequency::Infrequent = Static Render Path + Static Buffers (This is only for sections that update very infrequently as it forces a total resync of the entire RMC, but provides the fastest rendering path)

          In RMCv3 this won't be exactly the same as the mesh data is stored separately and so won't be resynced on recreate of the scene proxy which means it will more frequently use the static draw path (probably for both Infrequent and Average).


          Originally posted by DavidNSilva View Post
          Hey [MENTION=141752]Koderz[/MENTION], I'm trying out your Runtime Mesh Component (on 4.15) as performance is critical on what I am doing but I think I found a crash Calling URuntimeMeshLibrary::CalculateTangentsForMesh for a simple plane mesh causes a crash on GetUv() line 786 on RuntimeMeshBuilder.cpp, this is called by line 241 of the same file. It seems it's counting on a second Uv Map but there is none because CalculateTangentsForMesh passes a nullptr to the UV1 argument on the vertex builder.
          My Mesh as only one uv map, but nonetheless even if it had two only the first one is used to calculate normals/tangents so I think this might be a bug.

          As a "workaround" I am using Epic's implementation of CalculateTangentsForMesh which works but the problem is, not only to I not gain the speed upgrade of RMC's function as I have to spend more cycles converting back and forth between the FProcMeshTangent and FRuntimeMeshTangent.

          Maybe you could take a look at it? It might be an easy fix for you as I am sure you know that class like the palm of your hand by now :P
          Right now the RMC's normal/tangent calculation isn't really faster than the PMC's. That will change in v3. I might try to push a update soon to fix a few small things like this in the interim till v3 is done though.
          Runtime Mesh Component - The best way to render procedural/runtime created meshes! - Version 4.1 out now!

          Come talk about anything RMC or Procedural Mesh Related in our Discord!

          Comment


            Originally posted by Koderz View Post
            Right now the RMC's normal/tangent calculation isn't really faster than the PMC's. That will change in v3. I might try to push a update soon to fix a few small things like this in the interim till v3 is done though.
            I ended up rolling code to "manually" calculate the tangents and normals, the PMC's code is dreadfully slow not even suitable for editor time let alone runtime. if you're are going to push an update to v2 (which I would really appreaciate) and I am the only one affected by the CalculateMeshTangents problem then I would say not to brother fixing it for me cause I'm no longer using that functionand V3 is coming anyways. However....there is something else that bothers me with V2....I've looked through your code and examples to find the cause and I found a few hints. When selecting (in editor) an actor with a RMC the "selected outline" (that little orange line that outlines the selected object) actually fills the entire component/mesh instead of just outlining. To make matters worse, if the update frequency is set to "Infrequent" the outline/fill will Never disappear! not even by unselecting the object. when the update frequency is set to "Average" the outline/fill disappears when the actor is deselected....but the problem is the outline is not a outline but rather it fills the entire mesh changing it's color and making debugging and level design a lot harder as it drastically changes the color of the mesh. Where's a picture of the problem:

            Click image for larger version

Name:	selected outline.png
Views:	1
Size:	630.6 KB
ID:	1125044

            I know your time is limited and if you can only push a fix or two I would rather you fix the outline problem than the tangents one

            P.S - Please note they bug out more often when freshly dragged in from the content browser (100%) but they can also get stuck after being saved in a level, it's just more rare. But in all cases I would rather have an outline instead of that annoying "fill" effect.

            Comment


              I'm having trouble getting RMC to work in UE4 4.15. Is it possible to get the plugin with the project file? There's no way for me to rebuild the plugin (fixing any dll issues) because it isn't included in the zip file.

              Comment


                Hello,i'm trying add collision to the mesh.I used function RuntimeMesh->AddCollisionConvexMesh(Positions);.
                However,The collision body is not exactly the same as the mesh shape.As the picture shows,when i use TArray Positions create the wave-shaped mesh,the collision body seems like a big cuboid.And when i create a mesh that middle part raised,the collision body seems like a Round table body。
                I added fluid to see collision body shape.the red line draws the collision body shape i am looking for.

                Click image for larger version

Name:	picture1.png
Views:	1
Size:	440.8 KB
ID:	1126087
                Click image for larger version

Name:	pictur2.PNG
Views:	1
Size:	494.6 KB
ID:	1126088

                so the problem is,when i use l lot of point to create a complex collision body,it will be a convex hull instead of the mesh shape.
                How should i solve it?
                please help me!

                Comment


                  Since updating to 4.15 I'm getting an odd exception in PrimitiveSceneProxy.cpp. My C++ code is identical between my 4.14 and 4.15 projects. I compile and run both projects, the 4.14 version runs fine, but the 4.15 version triggers a breakpoint with an exception.

                  The exception occurs on line 599 of PrimitiveSceneProxy.cpp, which is an engine file. Here is the actual code from that file. Line 599 is at the ensureMsgf call.

                  Code:
                  void FPrimitiveSceneProxy::VerifyUsedMaterial(const FMaterialRenderProxy* MaterialRenderProxy) const
                  {
                  	// Only verify GetUsedMaterials if uncooked and we can compile shaders, because FShaderCompilingManager::PropagateMaterialChangesToPrimitives is what needs GetUsedMaterials to be accurate
                  #if WITH_EDITOR
                  
                  	if (bVerifyUsedMaterials)
                  	{
                  		const UMaterialInterface* MaterialInterface = MaterialRenderProxy->GetMaterialInterface();
                  
                  		if (MaterialInterface 
                  			&& !UsedMaterialsForVerification.Contains(MaterialInterface)
                  			&& MaterialInterface != UMaterial::GetDefaultMaterial(MD_Surface))
                  		{
                  			// Shader compiling uses GetUsedMaterials to detect which components need their scene proxy recreated, so we can only render with materials present in that list
                  			ensureMsgf(false, TEXT("PrimitiveComponent tried to render with Material %s, which was not present in the component's GetUsedMaterials results\n    Owner: %s, Resource: %s"), *MaterialInterface->GetName(), *GetOwnerName().ToString(), *GetResourceName().ToString());
                  		}
                  	}
                  	
                  #endif
                  }
                  Here is the call stack. You can see it seems to be originating in RuntimeMeshComponent from FRuntimeMeshSceneProxy::GetDynamicMeshElements(...) at line 320.

                  Code:
                  UE4Editor-Engine.dll!FPrimitiveSceneProxy::VerifyUsedMaterial(const FMaterialRenderProxy * MaterialRenderProxy) Line 599
                  UE4Editor-Engine.dll!FMeshElementCollector::AddMesh(int ViewIndex, FMeshBatch & MeshBatch) Line 233
                  UE4Editor-RuntimeMeshComponent.dll!FRuntimeMeshSceneProxy::GetDynamicMeshElements(const TArray<FSceneView const *,FDefaultAllocator> & Views, const FSceneViewFamily & ViewFamily, unsigned int VisibilityMap, FMeshElementCollector & Collector) Line 320
                  UE4Editor-Renderer.dll!FSceneRenderer::GatherDynamicMeshElements(TArray<FViewInfo,FDefaultAllocator> & InViews, const FScene * InScene, const FSceneViewFamily & InViewFamily, const TArray<unsigned char,SceneRenderingAllocator> & HasDynamicMeshElementsMasks, const TArray<unsigned char,SceneRenderingAllocator> & HasDynamicEditorMeshElementsMasks, FMeshElementCollector & Collector) Line 1958
                  UE4Editor-Renderer.dll!FSceneRenderer::ComputeViewVisibility(FRHICommandListImmediate & RHICmdList) Line 2617
                  UE4Editor-Renderer.dll!FDeferredShadingSceneRenderer::InitViews(FRHICommandListImmediate & RHICmdList, FILCUpdatePrimTaskData & ILCTaskData, TArray<TRefCountPtr<FGraphEvent>,TInlineAllocator<4,FDefaultAllocator> > & SortEvents) Line 2860
                  UE4Editor-Renderer.dll!FDeferredShadingSceneRenderer::Render(FRHICommandListImmediate & RHICmdList) Line 589
                  UE4Editor-Renderer.dll!RenderViewFamily_RenderThread(FRHICommandListImmediate & RHICmdList, FSceneRenderer * SceneRenderer) Line 1728
                  [Inline Frame] UE4Editor-Renderer.dll!FRendererModule::BeginRenderingViewFamily::__l21::EURCMacro_FDrawSceneCommand::DoTask(ENamedThreads::Type) Line 1896
                  UE4Editor-Renderer.dll!TGraphTask<`FRendererModule::BeginRenderingViewFamily'::`21'::EURCMacro_FDrawSceneCommand>::ExecuteTask(TArray<FBaseGraphTask *,FDefaultAllocator> & NewTasks, ENamedThreads::Type CurrentThread) Line 883
                  [Inline Frame] UE4Editor-Core.dll!FBaseGraphTask::Execute(TArray<FBaseGraphTask *,FDefaultAllocator> & CurrentThread, ENamedThreads::Type) Line 488
                  UE4Editor-Core.dll!FNamedTaskThread::ProcessTasksNamedThread(int QueueIndex, bool bAllowStall) Line 954	
                  UE4Editor-Core.dll!FNamedTaskThread::ProcessTasksUntilQuit(int QueueIndex) Line 701
                  UE4Editor-RenderCore.dll!RenderingThreadMain(FEvent * TaskGraphBoundSyncEvent) Line 325
                  UE4Editor-RenderCore.dll!FRenderingThread::Run() Line 476	
                  UE4Editor-Core.dll!FRunnableThreadWin::Run() Line 76
                  UE4Editor-Core.dll!FRunnableThreadWin::GuardedRun() Line 25
                  This exception comes up when I try to create a runtime mesh section for the first time. I have a valid material assigned to the mesh section. If I close the breakpoint exception dialog in Visual Studio and click Continue, then it continues running as per normal and the runtime mesh works fine from that point forward, until I close and run again, then I hit it again. So every time I run my project, I hit the breakpoint, close the exception dialog, then click Continue to keep going. Any idea what might be causing this [MENTION=141752]Koderz[/MENTION]?

                  Comment


                    Hi Koderz,

                    I'm Going To Build My Own Theme Park With Blackjack and Hookers (c), but I need your amazing plugin for that! With best colliders on mobile platforms/HTML5, with great skeletal mesh creation possibility, with a lot of other unbelieveable stuff Please keep this (membership in my Theme Park?) in mind next time when you open up your project!

                    (Hmm, almost Rama's style, it seems that I read his posts a lot

                    Anyway man, you are the best, please keep the work, I wish you a lot of energy and positive ideas!
                    Will wait for next version! cheers!

                    Comment


                      Hey Koderz. In out project it can happen that really small actors are created, talking about 0.0001cm³. This causes issues, as it seems, with collision cooking for the RMC. The following error is dispatched.

                      PHYSX: (D:\Build\++UE4+Release-4.15+PhysX_Compile\Sync\Engine\Source\ThirdParty\PhysX\PhysX_3.4\Source\PhysXCooking\src\mesh\TriangleMeshBuilder.cpp 1080) eINTERNAL_ERROR : cleaning the mesh failed

                      You now if this is something that could get fixed? Or a way for us to get a notification about that issue and provide a self made collision shape in that case?
                      NodePrefabs | PluginBuilder | NotificationBackbone | WidgetBox | DebugWidget

                      Comment


                        Originally posted by wilberolive View Post
                        Since updating to 4.15 I'm getting an odd exception in PrimitiveSceneProxy.cpp. My C++ code is identical between my 4.14 and 4.15 projects. I compile and run both projects, the 4.14 version runs fine, but the 4.15 version triggers a breakpoint with an exception.

                        The exception occurs on line 599 of PrimitiveSceneProxy.cpp, which is an engine file. Here is the actual code from that file. Line 599 is at the ensureMsgf call.

                        This exception comes up when I try to create a runtime mesh section for the first time. I have a valid material assigned to the mesh section. If I close the breakpoint exception dialog in Visual Studio and click Continue, then it continues running as per normal and the runtime mesh works fine from that point forward, until I close and run again, then I hit it again. So every time I run my project, I hit the breakpoint, close the exception dialog, then click Continue to keep going.
                        I saw the same issue, and I solved it with just commenting out the ensureMsgf there, it's surely not clean, but it works.
                        Easy to use UMG Mini Map on the UE4 Marketplace.
                        Forum thread: https://forums.unrealengine.com/show...-Plug-and-Play

                        Comment


                          Hey guys, anyone tried to raycast runtime mesh? My test collide by LineTraceSingleByChannel is only working on static meshes but not procedurally generated mesh, I try all the options of channels/responses but with no success...

                          Comment


                            Originally posted by John Alcatraz View Post
                            I saw the same issue, and I solved it with just commenting out the ensureMsgf there, it's surely not clean, but it works.
                            That requires modifying the UE4 source and recompiling it right? If so, I'd rather avoid something that drastic and find an actual fix for the issue. Any idea whether this is an issue with the runtime mesh component or with UE4 itself?

                            Originally posted by shunwang View Post
                            Hey guys, anyone tried to raycast runtime mesh? My test collide by LineTraceSingleByChannel is only working on static meshes but not procedurally generated mesh, I try all the options of channels/responses but with no success...
                            Yes, it does work. Make sure you have collisions turned on when you create your runtime mesh section. Then ensure the collision channel of the runtime mesh and the channel of the line trace are both set to block each other (or overlap if you just want that).

                            If all you care about is knowing whether your runtime mesh has been hit or not, this will work fine. If however you want more detailed information depending on which face is hit, then you will need to store this additional information yourself in an array that you populate in the same order as you add triangles to the runtime mesh. Unfortunately, the runtime mesh component doesn't have a facility to store a custom data blob on a per face basis... perhaps that could be a feature request, unless there is something I'm not aware of??? Very useful in situations where you are using a runtime mesh to render hundreds of batched objects for example and you want to know which object the player shot or clicked on for example. You could store an object index integer per face that can be retrieved from the hit face.

                            Comment


                              For rendering cube-shaped voxels aligned to a grid (think minecraft), does RMC have a performance or feature benefit over instanced static meshes? I know this is a high level question, I just wanted to do a bit of research before deciding if it's worth diving into this.

                              Comment


                                Originally posted by ryeguy View Post
                                For rendering cube-shaped voxels aligned to a grid (think minecraft), does RMC have a performance or feature benefit over instanced static meshes? I know this is a high level question, I just wanted to do a bit of research before deciding if it's worth diving into this.
                                RMC is exactly what you need for a situation like that. I would break the world up like an octree. Then use an RMC per node in the tree (so they can be culled) with a mesh section per material type.

                                Comment

                                Working...
                                X