Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

  • replied
    Originally posted by wilberolive View Post
    OK, fair enough. Is the new version stable enough to work with and is it a drop in replacement for 2.0 or has the public interface changed too? This bug is driving me to try anything at this point.
    I'm trying to remember what caused it, as I think if you did one specific thing without changes in the RMC it would shut up.

    As for V3. the core is very stable, but it's not feature complete,or technically even feature parity of v2. The public interface has changed, but if you only ever use the basics (create/update/clear) then it hasn't changed a whole lot and there's deprecated functions to ease the transition.If you accessed the sections directly, and some of the collision stuff has changed and there's not a good way to wrap some of that. They're all changes that would be easy to update for, but it's still technically got breaking changes. My hope is to set in on v3 here in about 2 weeks (this week is ECGC and end of course exams and stuff so it's super hectic) so it's still likely 4 weeks out to a usable version that I'll start sharing (that won't be feature complete or the final version obviously but I'll let people start testing it that want to)

    I might be willing to share a subset of it earlier but that's still likely 2 weeks.

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    I might if I get some time. The problem is I fixed that in the new RMC which is architecturally different and don't remember what I had to do to fix that off hand.
    OK, fair enough. Is the new version stable enough to work with and is it a drop in replacement for 2.0 or has the public interface changed too? This bug is driving me to try anything at this point.

    Leave a comment:


  • replied
    Originally posted by DavidNSilva View Post
    Setting EUpdateFrequency to "Infrequent" will cause the outline to always get stuck 100% of the time. EUpdateFrequency::Average seems to solve the problem, but nonetheless on any updatefrequency there still remains the problem that the entire mesh get's a fill effect and not an outline which causes the color of the mesh to change and makes it very hard to debug materials without deselecting it. As a workaround I added an #if WITH_EDITOR flag to my code to set the updatefrequency conditionally so it works on the editor and doesn't affect the performance of the shipped game.
    Ok, well I'll see if I can replicate that. I obviously see the fill effect but haven't ever seen it get stuck.




    Originally posted by wilberolive View Post
    Yep. I do most of my work in C++, so after every compile and run I hit this exception in PrimitiveSceneProxy.cpp. Any chance you could update the marketplace version with the fix?
    I might if I get some time. The problem is I fixed that in the new RMC which is architecturally different and don't remember what I had to do to fix that off hand.

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    I have that fixed in v3 but haven't gone back to v2 to fix it. Is this still causing you problems?
    Yep. I do most of my work in C++, so after every compile and run I hit this exception in PrimitiveSceneProxy.cpp. Any chance you could update the marketplace version with the fix?

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    Surprisingly I guess I haven't seen this myself even though I work with it daily. What specifically will cause it to get stuck?
    Setting EUpdateFrequency to "Infrequent" will cause the outline to always get stuck 100% of the time. EUpdateFrequency::Average seems to solve the problem, but nonetheless on any updatefrequency there still remains the problem that the entire mesh get's a fill effect and not an outline which causes the color of the mesh to change and makes it very hard to debug materials without deselecting it. As a workaround I added an #if WITH_EDITOR flag to my code to set the updatefrequency conditionally so it works on the editor and doesn't affect the performance of the shipped game.

    Leave a comment:


  • replied
    Originally posted by DavidNSilva View Post
    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:


    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.
    Surprisingly I guess I haven't seen this myself even though I work with it daily. What specifically will cause it to get stuck?


    Originally posted by Thumper View Post
    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.
    I'm a bit late here but yes you can add it directly to your project file. You'd just want the download from github master, not the release version, and then make sure you uninstall it from the engine if you installed it there.


    Originally posted by linmeeka View Post
    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.


    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!
    The solution for you specifically would be to use the MeshCollisionSections not the convex as you're right it will get turned into a convex hull. The Convex collision is required for moving bodies but for static objects like your ground there mesh collisions will give you the per triangle detail you need.



    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. Any idea what might be causing this [MENTION=141752]Koderz[/MENTION]?

    I have that fixed in v3 but haven't gone back to v2 to fix it. Is this still causing you problems?


    Originally posted by shunwang View Post
    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!
    Thanks! I am still quietly working on it, just far slower than I'd like. Good luck on your project!


    Originally posted by Rumbleball View Post
    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?

    That's a PhysX error so I probably can't do a whole lot about it. Why are you needing collision on something that small? You might be able to get around it by making the mesh larger and then scaling it down but something that small is likely to break other pieces of PhysX internally.



    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...
    [MENTION=28104]wilberolive[/MENTION] already got most of this (and yes it really does work) but I wanted to add one other thing. You might have to set bTraceComplex to true on the raycast parameters if you're raycasting against the mesh collision. I don't remember offhand what the defaults are for a ray trace but a standard static RMC with mesh collision will for sure work as I do that daily.



    Originally posted by wilberolive View Post
    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.
    I assume what you're talking about doing here is using the face index of a ray cast to index into your array of data? I hand't really thought about adding any direct support for things like that to the RMC other than possibly being able to take a raycast face index and telling you the section and face index within section since that face index is based off a monolithic mesh created from all the sections of one RMC. I will likely do that part but storing actual data per face I'm not as sure about. What do you see that being used for?



    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.
    Wilber beat me to it but yes the RMC will usually far surpass the performance of ISMC/HISMC for things like block voxel. Be warned it is harder to work with. The common approach for things like Minecraft, as wilber said is to break the world into chunks (I believe MC is 16x16x256 but I could be wrong on that) within each chunk, you create one RMC, with one section per material you need and add all the blocks using that material to that same mesh section. To handle multiple textures, the usual approach is either an atlas, or texture arrays (the latter of which isn't yet supported in the engine unless you count the Pull Request I'm assisting to bring support) That lets you have multiple different textures of blocks in the same material which is how you really get the performance benefit. ISMC/HISMC are based on hardware instancing which has some overhead in the vertex processing to instance the input mesh. The RMC doesn't need that, so you can get more throughput in vertex processing, with the same few draw calls if setup correctly. The only downside to the RMC is it means far more memory usage for the mesh data as instead of one 36 point mesh (24 vertices, 36 indices) combined with an instancing list (basic transform information, with some added properties) it becomes the combined sum of all visible faces. The naieve way is to just add all the blocks to the mesh, this is the worst idea as it will create thousands of unseen faces due to adjacent blocks. The basic upgrade is to not add faces to the mesh that are up against an adjacent block. There's ways to go further but I wouldn't try them until you're comfortable with building a full MC like system at this level.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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...

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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?

    Leave a comment:


  • replied
    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!

    Leave a comment:


  • replied
    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]?

    Leave a comment:


  • replied
    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!

    Leave a comment:

Working...
X