Fatal error when accessing from FPositionVertexBuffer::VertexPosition

I’m currently running 4.10.4, built from source. My project will run fully well in the editor even when spawned as it’s own process. However, all attempts to package and run the game standalone appear to trigger a fatal error when a part of my code calls FPositionVertexBuffer::VertexPosition(int32). I’ve submitted a crash report with this, I’d just like to know if anyone else has insight on this particular issue.

Hey Pecon-

Can you post the code where you using VertexPosition so I can attempt to reproduce the crash myself along with your machine id to help me locate the crash report you submitted?

Here is the machine ID: 6097EA0E46F8EE48D5E01483276D1721

Here is the function where it is being used

void AVertexColorSpreadMesh::BuildAdjacencyCache(FStaticMeshLODResources& LODModel)
{
   if (AdjacencyCache.Num() != 0)
	   return;

   int32 meshVerts = LODModel.GetNumVertices();

   for (int32 StartVertex = 0; StartVertex < meshVerts; StartVertex++)
   {
	   FVector StartPosition = LODModel.PositionVertexBuffer.VertexPosition(StartVertex);
	   for (int32 EndVertex = 0; EndVertex < meshVerts; EndVertex++)
	   {
		   if (StartVertex == EndVertex)
			   continue;
		
		   FVector EndPosition = LODModel.PositionVertexBuffer.VertexPosition(EndVertex);
		   if (FVector::Dist(StartPosition, EndPosition) <= (float)3.0)
		   {
			   AdjacencyCache.Add(StartVertex, EndVertex);
		   }
	   }
   }
 }

The callstack points specifically to the instance in the second for loop there.

I copy/pasted the function into my project and there was a compile error regarding AdjacencyCache. based on the data type of StartVertex and EndVertex it seems AdjacencyCache is an array of int32, is that correct? Once I can compile successfully I can try to package to see if my results match what you’re getting.

It’s a TMultiMap of int32, int32

I was going to just paste in the definition but the comment system seemed to think that I was using an html tag and stripped out part of it.

Can you post the definition and any initialization code separately. I am still running into compile errors and want to ensure that I am following as closely to your setup as possible.

There is actually quite a lot of context to this code, and I don’t feel like posting the whole thing here in a comment would work out that well. So I’ll give you the project files instead.

This is based off the FPS template, so you should be able to just swap in these files. The function in question is in VertexColorSpreadMesh.cpp

Hey Pecon-

After speaking with another developer it was noticed that in the BuildAdjacencyCache function, you define the variable meshVerts which calls LODModel.GetNumVertices(). The problem here is that this returns the verts in VertexBuffer, not PositionVertexBuffer. Calling LODModel.PositionVertexBuffer.GetNumVertices() instead allows the packaged game to run without the crash.

Cheers

Hi, thanks for taking the time to look into this. I’ve updated my code to call the correct member function to get the vertex count, but I continue to get the exact same crash when I package the game. To be sure I’ve even done a full rebuild of the binary in VS before packaging, to no avail.

The new crash is due to the for loop inside the AVertexColorSpreadMesh::GetNearestVertIndex function. The for loop uses the same LODModel.GetNumVertices() call as its condition check. Editing this to LODModel.PositionVertexBuffer.GetNumVertices() should fix the crash.

I’ve gone ahead and made sure that all my calls are to the member function on PositionVertexBuffer, but I still continue to get crashes on my packaged builds that point directly to the function call in BuildAdjacencyCache.

If you are still getting a crash in the BuildAdjacencyCache function, can you post an updated version of your project after the first fix? I am not seeing a crash in that function after making the change to LODModel.PositionVertexBuffer.GetNumVertices().

Here are the new files.

http://justfilehosting.space/download.php?f=rrwwu&name=project.rar

I also submitted the crash report in the last build I tried to run. MachineID should be the same.

Hey Pecon-

After further testing I found that if I change the static mesh assigned to the VertexColorSpreadMesh assets to the default cube I am able to launch/run a packaged game without the crash. Looking at both the default cube and the “Oliver Wall” in the static mesh editor, I noticed that the wall mesh had17k verts and 33k triangles. If possible, it may help to reduce the number of vertices/triangles for the Oliver Wall mesh or use a less intensive mesh.

Cheers