Work Log

Texturing Frustrations     I don't have much tangible progress to show for the past few days, but I wanted to post an update about what I have learned and the many missteps I have taken.      Most of the frustration came down to the system of texturing the planets and trying to convert the linear color curves and atlases to textures. The first thing I wanted to fix was the fact that no matter what value you would enter for the color curve or atlas it would not apply to the material. This was because, unlike the vector parameter for height, I could not find a curve or atlas parameter that was accessible through C++. Eventually though, I found that you can use an atlas as a texture. So this means that I could use a texture parameter to pass through the atlas from the planet to the material without having to manually edit, or create a new material for each atlas.      The unintended consequence of this was that the planet now looked like this:     Admittedly, this might actually be us

Instancing Hell & Future Plans     Both yesterday and today I have worked on editing the settings data assets to be instanced like they should have been from the start as well as coming up with ideas for what features I should add once I'm done with planets.  Instancing:     There are two reasons that I decided to do this now. 1) When I made that video yesterday showing off the planet rotation, in order to get two different looking planets I would have to change one planet at a time, therefore tricking it into not updating the changes that were made to subsequent planets. This whole process was much more time consuming and cumbersome than it should have been. 2) When looking ahead in the tutorial series, I noticed how many data assets I would have to make, which would just compound issue number 1. Now, it took some time but I finally have it working.      My first target for instancing was the color settings because the next part of the tutorial required an array of data assets

Off The Beaten Path     Today I have decided to take a little break from following the tutorial verbatim. Instead I have decided to give some attention to two things that I have wanted to fix for a while now. These two things are planet rotation and a bug where the planet is not rendered at it's actor location in the scene.     First thing first, I wanted to get the planets showing up in the right part of space. The problem was, when I put a new planet in the scene the procedural mesh part of the actor would always snap to the world origin. Then if I moved the planet in the scene the meshes would always have the offset from where it was initially placed. I suspected that this was due to the root component being created at 0, 0, 0. To combat this, in the constructor I tried resetting this value, but that didn't work. What did end up working was setting the root component as a UPROPERTY then manually editing its transform. Yet another compromise that works for now, but that I wil

Planet Coloring pt.1.5     Within the past day, I have managed to add full color to the planets. Although it took more time and effort than I would have expected, I am happy with the result.     The biggest challenge I had to overcome was getting a color gradient. In Unity, there is simply a variable type 'Gradient' that gives you a nice small UI to pick colors and can be converted to a 2D texture that can be used in the shader graph. What's wrong with that? Well Unreal decided that wouldn't be complicated enough.     So after a bit of searching online for "ue4 gradient" or "color gradient ue4", I came across this forum answer that introduced me to curves. So instead of having variable type 'Gradient' you would have ' UCurveLinearColor' because that's so much more intuitive. Then you will have to create a Curve of type LinearColor in the content browser. Now once you assign assign that variable in the details panel, and open the

Planet Coloring pt.1     Today I managed to finish the terrain generation for now and have moved on to giving the planet some color.     The last thing I did to round out the terrain generation was to clean up those noise settings that I created last time. I wanted for only corresponding noise settings to be displayed in the details panel. In the Unity tutorial, this required editor scripting. I thought that this could have been taken care of by something more simple in Unreal like property specifiers or something (Spoiler: This was correct, but it would take some time before I would realize this).       After scanning the UPROPERTY specifiers page and found the metadata specifier  EditCondition="BooleanPropertyName". This took in any bool including anything you could format into a C++ expression which is quite cool. I used this to say that the properties could only be edited when the corresponding enum is selected (eg. EditCondition = "FilterType == 0"). I was temp

Procedural Terrain  Generation pt.3     Little progress has been made in actually fixing any of the things that I have meant to, but on the bright side I have managed to get different types of noise to work together.          First off, the layered noise/detail problem from last blog. Turns out it was me being stupid and the generation was working exactly as it was supposed to. The "problem" was that I was looking at a relatively low resolution gen of the planet, so no matter what I did it would always have a maximum level of detail that it could render. I had the resolution at 16x16 per side so that the planet would respond quickly to updated to the settings. If I upped that to 128x128 or even 256x256 it would take considerably longer to update but would be more detailed.     Once I figured that out I went no to creating different types of noise. The idea was to make ridge-like features on top of the rough and bumpy default generation. It ended up working, but only after fru

Procedural Terrain  Generation pt.2     So yesterday I implemented the most sloppy multi-layer noise system ever created by man. I tried to stick to the tutorial as much as I could, but some things just wouldn't cooperate.     The main thing that Unreal didn't agree with was a nested class. The basic idea behind the need for the nested class was it was to be a container for some modifiers to the noise settings. The problem was that I was unable to make an array of this class into a UPROPERTY. This is because, quite understandably, UPROPERTY's require the variable type to be derived from an unreal class, struct, or enum. But these things require special things that a nested class is unable to have (eg. GENERATED_BODY(), .generated.h). To get around this I just created another data asset that would hold the same information. The problem with this is that is adds lots of unnecessary clutter to the details panel in Unreal. I will continue looking for a fix for this, but for now

Procedural Terrain  Generation pt.1     Since I have moved past the color settings debacle of this week I have started working on making the planets more planet-like and not just boring old spheres.          I knew I would have to use perlin noise for this and so I went looking around for some way to implement it in Unreal. I eventually found though that Unreal's math library already contains functions to generate 3D noise. This system is quite simple though and some of the plugins and stuff that I found would give more control of the noise, this will work for what I want to do.      The next step was to create some more classes that would deal with this noise. One of these was a class that didn't inherit from anything. When I tried to compile it though it had the same problem as before where it wouldn't recognise the syntax. The fix for this as I found before was to regenerate the VS project files. It seems that this is some sort of bug with the version of Unreal that I ha

In Editor Live Updating pt.3     Small update for today as all I have done is  partially solved the issue of editing the settings properties within the planet blueprint. It's not as I would have hoped but in time I think I can manage it.      Basically, I wanted the settings to be editable within the planet blueprint so that I would be able to save that data asset and choose between previous settings. Right now I can edit the settings within the blueprint but I cannot choose between data assets. All this has been done with a combination of property and class specifiers.     I started out with property specifiers on the settings variables. With the specifiers EditAnywhere and BlueprintReadWrite I was able to set the data asset used, which was half of what I wanted. I added the Instanced specifier and that allowed me to edit the properties of the data asset, but simultaneously took away my ability to choose between data assets. I don't know if this is intentional behavior for thi

In Editor Live Updating pt.2      As I stated in the last update, I am working on the planet generation settings. These are Shape Settings, which right now is just planet radius, and Color Settings, which is just a solid color. I am doing this with the use of Unreal's data assets. I did this because it is more or less the equivalent to Unity's scriptable objects, which is what's used in the tutorial.      At the time of writing, the system is capable of updating the color and radius of the planet when the data asset is changed. This is done with the help of the  PostEditChangeProperty function I found last time, expanded for more property changes. However, right now the function only detects if the entire asset is changed, so in the future I would like for the data asset to be editable within the plant's blueprint and update based on that.     The first problem I ran into through this process was faulty engine generated files. Essentially, when I tried to create the Sha

In Editor Live Updating pt.1      For the past few days I worked on getting the resolution of the planets to be editable inside the blueprint editor and to make it update in real time. After many false leads, I have finally figured it out.      The solution comes as a combination of two things; UPROPERTY specifiers and an editor function. The UPROPERTY specifiers that I used were  EditAnywhere and BlueprintReadWrite. EditAnywhere allows the property to show up in the details panel, and BlueprintReadWrite allows the value to be written to effect the C++. Though, I think I will end up using EditInstanceOnly over EditAnywhere when I move to using the planets in the scene. One of the red herrings I ran across while looking into the specifiers was the metadata specifier BlueprintCompilerGeneratedDefaults. This was because, at the time, I thought that I had to set the initial value to the blueprint value and reinitialize from there. As it turns out though, it doesn't really matter what t