Announcement

Collapse
No announcement yet.

Runtime Mesh Component

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

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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Click image for larger version

Name:	c3bea9c659053e15e7660b1698387633.jpg
Views:	1
Size:	492.1 KB
ID:	1124929

    It gets pretty complex on the highest LOD level.

    Click image for larger version

Name:	5a2dcdf93b28821c4f8caebdc01df84f.png
Views:	1
Size:	847.0 KB
ID:	1124931


    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)

    Click image for larger version

Name:	f64f2f6717f9d19463396904d9ba0de2.jpg
Views:	1
Size:	449.2 KB
ID:	1124932




    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?
    Last edited by DennyR; 03-19-2017, 05:46 PM.

    Leave a comment:


  • replied
    Hey, just found your plugin and it appears to be awesome, I am on 4.15 however and 2.0 from github doesn't compile. Any chance to get an updated version? Otherwise I will go and try to fix the compiler errors.

    Edit: Pulled master branch and it works.
    Last edited by DennyR; 03-19-2017, 03:39 PM.

    Leave a comment:


  • replied
    I finally managed to solve the problem. I will post it if somebody encounters a similar problem.

    Code:
    for (int i = 0; i < NumVerts / 3; i++)
    	{
    		Colors[i * 3] = FColor(255, 0, 0); 
    		Colors[i * 3 + 1] = FColor(0, 255, 0);
    		Colors[i * 3 + 2] = FColor(0, 0, 255);
    	}
    Click image for larger version

Name:	blueprint2.png
Views:	1
Size:	130.6 KB
ID:	1124761

    Click image for larger version

Name:	ue4.png
Views:	1
Size:	333.2 KB
ID:	1124762

    Leave a comment:


  • replied
    Actually probably not, I am googling on how to do it, but I couldn't find the exact way to do it.

    //EDIT: I am posting the blueprint of the material I am using. This material doesn't show the vertex colors.

    Click image for larger version

Name:	blueprint.png
Views:	1
Size:	115.5 KB
ID:	1124759

    //EDIT2: I also tried changing it, so it would look like in the picture below, but still no luck.
    Click image for larger version

Name:	blueprint1.png
Views:	1
Size:	112.0 KB
ID:	1124760
    Last edited by PJ87; 03-15-2017, 12:28 PM.

    Leave a comment:


  • replied
    [MENTION=391838]PJ87[/MENTION]: Are you using the vertex colors in your material? You need to apply a material to the mesh that uses the vertex color.

    Leave a comment:


  • replied
    Hi, I really like the plugin, congratulations Koderz for your work. I'm completely new to UE4. I am also implementing Dual Contouring algorithm and at the begining was using Procedural Mesh Component. After a while I found your Runtime Mesh Component, I wanted to try it out. The issue I am having is: I would like to have a colored vertices, instead of materials. Could you help me with this?

    I tried changing your examples a bit to fill the ColorBuffer with apropriate colors:
    RuntimeMeshLibrary.cpp:
    Code:
    void URuntimeMeshLibrary::CreateBoxMesh1(FVector BoxRadius, TArray<FVector>& Vertices, TArray<int32>& Triangles, TArray<FVector>& Normals, TArray<FVector2D>& UVs, TArray<FRuntimeMeshTangent>& Tangents, TArray<FColor>& Colors)
    {
    	// Generate verts
    	FVector BoxVerts[8];
    	BoxVerts[0] = FVector(-BoxRadius.X, BoxRadius.Y, BoxRadius.Z);
    	BoxVerts[1] = FVector(BoxRadius.X, BoxRadius.Y, BoxRadius.Z);
    	BoxVerts[2] = FVector(BoxRadius.X, -BoxRadius.Y, BoxRadius.Z);
    	BoxVerts[3] = FVector(-BoxRadius.X, -BoxRadius.Y, BoxRadius.Z);
    
    	BoxVerts[4] = FVector(-BoxRadius.X, BoxRadius.Y, -BoxRadius.Z);
    	BoxVerts[5] = FVector(BoxRadius.X, BoxRadius.Y, -BoxRadius.Z);
    	BoxVerts[6] = FVector(BoxRadius.X, -BoxRadius.Y, -BoxRadius.Z);
    	BoxVerts[7] = FVector(-BoxRadius.X, -BoxRadius.Y, -BoxRadius.Z);
    
    	// Generate triangles (from quads)
    	Triangles.Reset();
    
    	const int32 NumVerts = 24; // 6 faces x 4 verts per face
    
    	Colors.Reset(); 
    	Colors.AddUninitialized(NumVerts);
    
    	for (int i = 0; i < NumVerts; i++)
    		Colors.Add(FColor(255, 0, 0, 255)); 
    
    	Vertices.Reset();
    	Vertices.AddUninitialized(NumVerts);
    
    	Normals.Reset();
    	Normals.AddUninitialized(NumVerts);
    
    	Tangents.Reset();
    	Tangents.AddUninitialized(NumVerts);
    
    	Vertices[0] = BoxVerts[0];
    	Vertices[1] = BoxVerts[1];
    	Vertices[2] = BoxVerts[2];
    	Vertices[3] = BoxVerts[3];
    	ConvertQuadToTriangles(Triangles, 0, 1, 2, 3);
    	Normals[0] = Normals[1] = Normals[2] = Normals[3] = FVector(0, 0, 1);
    	Tangents[0] = Tangents[1] = Tangents[2] = Tangents[3] = FRuntimeMeshTangent(0.f, -1.f, 0.f);
    
    	Vertices[4] = BoxVerts[4];
    	Vertices[5] = BoxVerts[0];
    	Vertices[6] = BoxVerts[3];
    	Vertices[7] = BoxVerts[7];
    	ConvertQuadToTriangles(Triangles, 4, 5, 6, 7);
    	Normals[4] = Normals[5] = Normals[6] = Normals[7] = FVector(-1, 0, 0);
    	Tangents[4] = Tangents[5] = Tangents[6] = Tangents[7] = FRuntimeMeshTangent(0.f, -1.f, 0.f);
    
    	Vertices[8] = BoxVerts[5];
    	Vertices[9] = BoxVerts[1];
    	Vertices[10] = BoxVerts[0];
    	Vertices[11] = BoxVerts[4];
    	ConvertQuadToTriangles(Triangles, 8, 9, 10, 11);
    	Normals[8] = Normals[9] = Normals[10] = Normals[11] = FVector(0, 1, 0);
    	Tangents[8] = Tangents[9] = Tangents[10] = Tangents[11] = FRuntimeMeshTangent(-1.f, 0.f, 0.f);
    
    	Vertices[12] = BoxVerts[6];
    	Vertices[13] = BoxVerts[2];
    	Vertices[14] = BoxVerts[1];
    	Vertices[15] = BoxVerts[5];
    	ConvertQuadToTriangles(Triangles, 12, 13, 14, 15);
    	Normals[12] = Normals[13] = Normals[14] = Normals[15] = FVector(1, 0, 0);
    	Tangents[12] = Tangents[13] = Tangents[14] = Tangents[15] = FRuntimeMeshTangent(0.f, 1.f, 0.f);
    
    	Vertices[16] = BoxVerts[7];
    	Vertices[17] = BoxVerts[3];
    	Vertices[18] = BoxVerts[2];
    	Vertices[19] = BoxVerts[6];
    	ConvertQuadToTriangles(Triangles, 16, 17, 18, 19);
    	Normals[16] = Normals[17] = Normals[18] = Normals[19] = FVector(0, -1, 0);
    	Tangents[16] = Tangents[17] = Tangents[18] = Tangents[19] = FRuntimeMeshTangent(1.f, 0.f, 0.f);
    
    	Vertices[20] = BoxVerts[7];
    	Vertices[21] = BoxVerts[6];
    	Vertices[22] = BoxVerts[5];
    	Vertices[23] = BoxVerts[4];
    	ConvertQuadToTriangles(Triangles, 20, 21, 22, 23);
    	Normals[20] = Normals[21] = Normals[22] = Normals[23] = FVector(0, 0, -1);
    	Tangents[20] = Tangents[21] = Tangents[22] = Tangents[23] = FRuntimeMeshTangent(0.f, 1.f, 0.f);
    
    	// UVs
    	UVs.Reset();
    	UVs.AddUninitialized(NumVerts);
    
    	UVs[0] = UVs[4] = UVs[8] = UVs[12] = UVs[16] = UVs[20] = FVector2D(0.f, 0.f);
    	UVs[1] = UVs[5] = UVs[9] = UVs[13] = UVs[17] = UVs[21] = FVector2D(0.f, 1.f);
    	UVs[2] = UVs[6] = UVs[10] = UVs[14] = UVs[18] = UVs[22] = FVector2D(1.f, 1.f);
    	UVs[3] = UVs[7] = UVs[11] = UVs[15] = UVs[19] = UVs[23] = FVector2D(1.f, 0.f);
    }
    RuntimeMeshLibrary.h:
    Code:
    UFUNCTION(BlueprintCallable, Category = "Components|RuntimeMesh")
    	static void CreateBoxMesh1(FVector BoxRadius, TArray<FVector>& Vertices, TArray<int32>& Triangles, TArray<FVector>& Normals, TArray<FVector2D>& UVs, TArray<FRuntimeMeshTangent>& Tangents, TArray<FColor>& Colors);
    BasicRMCActor.cpp:

    Code:
    void ABasicRMCActor::OnConstruction(const FTransform& Transform)
    {
    	TArray<FVector> Vertices;
    	TArray<FVector> Normals;
    	TArray<FRuntimeMeshTangent> Tangents;
    	TArray<FVector2D> TextureCoordinates;
    	TArray<int32> Triangles;
    	TArray<FColor> Colors;
    
    	URuntimeMeshLibrary::CreateBoxMesh1(FVector(500, 500, 500), Vertices, Triangles, Normals, TextureCoordinates, Tangents, Colors);
    
    	// Create the mesh section specifying collision
    	RuntimeMesh->CreateMeshSection(0, Vertices, Triangles, Normals, TextureCoordinates, Colors, Tangents, true, EUpdateFrequency::Infrequent);
    }

    But the effect is as shown in the image below:
    Attached Files

    Leave a comment:


  • replied
    Originally posted by wilberolive View Post
    Thanks. Though Epic's update process must be painfully slow. Such a tease having a shiny new engine version that I can't update to.
    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!

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    No, actually I thought I submitted it but apparently I never actually sent it! It's now sent so hopefully it will get updated once Epic has time to get it through their update process.
    Thanks. Though Epic's update process must be painfully slow. Such a tease having a shiny new engine version that I can't update to.

    Leave a comment:


  • replied
    Originally posted by Koderz View Post
    I can't say I've seen that. What version of the engine is this?
    Tested on 4.12. I'm not sure about 4.13+. It bugged If you reference to actor containing ProceduralMeshComponent or RMC (plugin ver. 2) from FPC actor (for example to get variables from target). https://answers.unrealengine.com/que...eshcompon.html

    Originally posted by kara-mveit View Post
    Hi,

    I'm using the plugin through it's sources. The integration into my project works fine for about 3 months. Basically I'm using it to import user data at runtime from files (FBX, SKP, ...). I have to mention that I'm using only the C++ API.
    Don't you use fbxsdk?
    Last edited by Two-faced; 03-05-2017, 12:37 PM.

    Leave a comment:

Working...
X