about UDynamicMeshComponent

Hi,
I am making a dynamics mesh component to help with debug visualization for my plugin,
as a substitute for the DrawDebugLine api.
DrawDebugLine api is fine for a small set of debug info, but it gets ridiculous slow if the debug code do too many lines, specially when the mesh been edited changes frequently in the editor.

it seems to be the consensus that UE::Geometry::FDynamicMesh3 is specialty designed for that purpose. Ther does no seem to be much sample code, so I am going alone.
I actually have the implementation working on the on the class bellow.

#include "NewtonDebugMeshComponent.h"


#include "ThirdParty/newtonLibrary/Public/dNewton/ndNewton.h"

UNewtonDebugMeshComponent::UNewtonDebugMeshComponent()
	:Super()
{
}

void UNewtonDebugMeshComponent::BuildDebugMesh()
{
	class PolygonizeMesh : public ndShapeDebugNotify
	{
		public:
		PolygonizeMesh(UE::Geometry::FDynamicMesh3* const mesh)
			:ndShapeDebugNotify()
			,m_mesh(mesh)
		{
		}

		~PolygonizeMesh()
		{
			for (ndInt32 i = 0; i < triangles.GetCount(); i += 3)
			{
				m_mesh->AppendTriangle(triangles[i], triangles[i + 1], triangles[i + 2], 0);
			}
		}

		void DrawPolygon(ndInt32 vertexCount, const ndVector* const faceArray, const ndEdgeType* const)
		{
			int face[32];
			for (ndInt32 i = 0; i < vertexCount; ++i)
			{
				FVector3d p(faceArray[i].m_x, faceArray[i].m_y, faceArray[i].m_z);
				face[i] = m_mesh->AppendVertex(p);
			}

			for (ndInt32 i = 2; i < vertexCount; ++i)
			{
				triangles.PushBack(face[0]);
				triangles.PushBack(face[i - 0]);
				triangles.PushBack(face[i - 1]);
			}
		}
		UE::Geometry::FDynamicMesh3* m_mesh;

		ndArray<int> triangles;
	};

	UDynamicMesh* xxxxxx = NewObject<UDynamicMesh>();
	{
		UE::Geometry::FDynamicMesh3* const xxx = xxxxxx->GetMeshPtr();
		PolygonizeMesh mesh(xxx);

		ndShapeInstance box(ndShapeInstance(new ndShapeBox(100.0f, 100.0f, 100.0f)));
		box.DebugShape(ndGetIdentityMatrix(), mesh);
	}

	SetRelativeLocation(FVector(200.0f, 200.0f, 200.0f));
	SetDynamicMesh(xxxxxx);
	NotifyMeshUpdated();
}

The problem, is that now I can’t figured out how to make it so that it does not render the solid mesh, but that only renders the wire frame overlay. Basically a hidden lines drawing.

I figured there has to be some material that can do that.
if I was doing this is open gl, all it has to do is make an empty fragment like the one below and is will make a stencil on the zbuffer, then the line draw will not override hidden pixels.

#version 450 core
void main()
{
}

I have not idea how to achieve this effect with a DynamicMeshComponent.
It seem to be design to draw a triangular mesh. and it has an option to do a secudn pass to draw the wire frame. But the passes are not indepemend.
This will make sence for most case, but in my case, this mesh is to be draw over a mesh that is already in the scene, so Ideally I will onel need the wire frame overlay part.

Obviously unreal can do this because there are lots of features that render a huge number of debug line not affecting the performance as drastically as DrawDebugLine would.
As an example, the image below show what I mean.

Untitled1

The mesh in green is a segment of a landscape.
The green lines is the debug with DrawDebugLine, the frame rate drops to about 1 every three seconds, and that a very simple map of (16 x 16 tiles of 128 x 126 point each)
ther performance is unacceptable.
however somehow unreal can draw all those lines and a lot more when editing land scape actor, if the user enable show collsion.

The small box is my custom UDynamicMeshComponent
But as you can see the mesh is solid, so if I draw it on top of the land scape,
the user is not going to be able to see what he or she is doing.

I hope this explains why, be able to draw the lines but no the solid triangles.

any help on this would be appreciated.

I have search on the api, but It does not seem this is a feature of the mesh component
so I assume of a material feature.

Thank
Julio

I little bit more context.
I beleive a fallback way to do this is by making a full transparent material, that is attached to the component at creation time.
so I try that but for some reason it does not seem to work on
UE::Geometry::FDynamicMesh3* const xxx = xxxxxx->GetMeshPtr();

here is the image of how I am doing it.

I expected the box to be render green, if I do this on any other mesh component it works,
but fail for UDynamicMeshComponent.
I try changing some of teh other parameters, but nothing works.
Is there something else I need to do? this is so confusing.
It seems override materials is ignored, so there have to be some option to active it.
the class does have a solid color, but that too ignore that alpha compoment.

sorry I ask these seemingly silly questions, but information about UDynamicMeshComponent and FDynamicMesh3 objects is nearly null or contradictory.
Basically is limit I am going by what I find in the headers.

Julio

ok I figured it out.

for what ever is worth, if any one has teh same issue.
It looks like the only way to assign a material to a DynamicsMeshComponent is procedurally in code.

however, the procedure is not trivial and as far as I can see it is no explained.

here are teh step I did.
-First you need to get the material and save with the Actor that will own that component.
this is what explain the existence of an UDynamicsMeshActor. one of the purpose is to just hold that material.
But it seems that the component can be assigned to any actor.

-you can create your UDynamicsMeshComponent in code (c++ or blue print)
you can assigned the material procedurally like this.

something like this.

	UDynamicMesh* dynamicsMesh = NewObject<UDynamicMesh>();
	{
		UE::Geometry::FDynamicMesh3* const triangleMesh = dynamicsMesh->GetMeshPtr();
		PolygonizeMesh mesh(triangleMesh);

		ndShapeInstance box(ndShapeInstance(new ndShapeBox(100.0f, 100.0f, 100.0f)));
		box.DebugShape(ndGetIdentityMatrix(), mesh);
	}

	SetMaterial(0, materialInstance);
	SetRelativeLocation(FVector(200.0f, 200.0f, 200.0f));
	SetDynamicMesh(dynamicsMesh);
	NotifyMeshUpdated();

the render mesh look like this now.
Untitled

This seems satisfactory for now, so unless I got something wrong, that anyone can see, this can be closed.
Julio.