Summer Work (Day 8)

Making a sphere

    Possibly my greatest programming achievement so far; I have made a sphere. It sounds very simple (and with hindsight it was) but after a few days of work I have managed to render a procedural sphere in unreal.

     From my last post, I said that the last thing that needed to be fixed was the nullptr issue a variable that was passed to the GeneratedPlanet() function. This ended up just fixing itself I guess. Like I just came back the next day and it didn't happen anymore, so that's cool.

    Although, as I correctly predicted last time, this was not in fact the final issue. There were actually two final issues. I recognised the issues because on the first test that didn't crash the editor there was only one section of the sphere rendered, and on top of that it was rendering inside out. 

    My instinct was that either it was a problem with the math of finding triangles and vertices, or it was a problem with the array of procedural mesh components. I decided to focus first on the chance that it was the array, because how hard could that be to fix? Answer: a full day. The first giveaway was that in the component hierarchy there was only one procedural mesh component when there should be six. The declaration of the array was 

TArray<UProceduralMeshComponent*> meshes[6];

and the initialization was:

meshes->Init(CreateDefaultSubobject<UProceduralMeshComponent>("Mesh"), 6)

    I thought that this would create 6 procedural mesh components called "Mesh", filling up the array. In reality it created 6 references to the same component. I found this out by watching the value of the array in the VS debugger and seeing that the memory address of all the elements were the exact same. This meant that every time a mesh was generated it was written to the same component, therefore overwriting every previous mesh. I fixed this by taking on a different form of initialization. 

	meshes = { CreateDefaultSubobject<UProceduralMeshComponent>("Mesh0"),
                   CreateDefaultSubobject<UProceduralMeshComponent>("Mesh1"), 
                   .
                   .
                   . };

    So now there are six meshes, but they will still be inside out. This no doubt was a problem with the math. I got lucky and decided to negate the localUp when calculating pointOnUnitCube and that worked.

    The last thing left to do was compile, and... crash. This stupid problem took a while, so I will boil it down to the problem and the solution that I found.

The problem:

TArray<UProceduralMeshComponent*> meshes[6];

Returns a reference to a UProceduralMeshComponent and not a pointer like the terrain generator expects.

The solution:

Get rid of the [6] so it becomes an array of pointers and not references. The reason I didn't do this sooner was I thought I had to have it in order to make sure there were exactly 6 procedural meshes until I figured out the other form of initialization. In this time I also learned more about pointers, references, and addresses to better understand the system I was working with.

Finished product:

Other Learnings:

• Clamping the value of a uproperty int: UPROPERTY(... meta = (ClampMin = "2", ClampMax = "256"))
• "Range-based" for loops
• VS debugging is really cool and useful
• C++ pointers and stuff would be really cool if I knew how use them properly
• I should look at documentation before stackoverflow.com