Summer Work (Day 14)

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 frustration with VS. This was because I wanted a tree of inheritance in the noise generation classes to make iterating and creating new ones easier. I settled on an interface that would have the one required Evaluate() function for all noise types. Everything was fine until it came to creating the generator from the given generation type.
    I wanted to have a switch that would return a generator from the given generation type. The catch was that it had to return the parent class so that all the places that were using it could accept any variation in the type. I thought, since all of the generation classes were derived from this one parent, that there would be no problem... and I was right. Only VS was having a bad day or something and refused to compile. The first thing I tried was: "return new SimpleNoiseFilter(NoiseSettings);". VS didn't like it, saying there was no way to convert from SimpleNoiseFilter to INoiseFilter (the parent class). I then thought that I might have to cast, and that would be no problem because of the inheritance I described before.
    But using Unreal's Cast<T>() wouldn't work either, this time saying that it wouldn't take the argument list. I then turned to basic C++ casting and that gave me no red squiggles. I did: "dynamic_cast<INoiseFilter*>(SimpleNoiseFilter(NoiseSettings));". I compiled and then it gave errors. At that point I gave up for the day and left it to future me to solve.
    I came back today and "return new SimpleNoiseFilter(NoiseSettings);" worked. Just like that I had ridged mountains and hilly continents.

    Other than that, I have put some time into making the project cleaner. I realized that you can put UENUMs above a UCLASS in the same file so that's cool, and as a bonus also means I have less files to deal with. I then went on to tackle making the noise settings variables cleaner. My first thought was to make them into structs. Then by using a USTRUCT I could still see and edit them in editor but I could also use extra things that are special to structs. 
    I tried this out and the problem that I have run into is actually accessing these variables. Now that they are now technically UNoiseSettings.... nevermind. While writing this I went back to the code to see if I could grab the error message to put here, but instead I managed to fix it. The downside is that it requires that I move the UENUM back to its own separate file so that it can have a specialized .generated.h.
    So it turns out the problem was I was just using the wrong syntax to try to access the struct. I was trying to do UNoiseSettings::FSimpleNoiseSettings where I should have just been using FSimpleNoiseSettings. Makes sense now but I'm really glad that works. The only remaining problem is that the noise variables don't show up in the editor anymore because they are part of the struct... hmmm.
    Another win! All that took was the struct specifier "BlueprintType". Now I'll stop. The real last problem is that all settings show up when you have one selected. This was also an issue in the Unity project and to fix that it took editor scripting. I assume Unreal will have something similar, or maybe it's just more specifiers. ;)

Comments

Post a Comment

Popular posts from this blog

Polishing the Foundation

Image
     This sprint was relatively uneventful; mainly cleaning up the existing foundational elements of the game (the first person character and spell component) and continuing to improve the necessary elements of the game like the pause screen. Player Character & Spells      The improvements to the player character come in two parts; the ability to have, use, and change spells, as well as interaction via an interface. Both of theses are as simple as I could make them. Utilizing inheritance from USpellBase using the spells is only really a single line, and changing out the spells we can use the NewObject factory to make a new spell very simply. FirstPersonCharacter.h FirstPersonCharacter.cpp      As for the interaction interface, it only consists of two functions right now, one to fire an interaction event and one to check if the object can be interacted with. This second function is used mainly to show UI on the player's screen like...
Read more

Progress Update #13

Image
  Niagara Asteroids in UE4     These past few days I have continued work on asteroids. Only that now I have ditched instanced static meshes in favor of getting my hands on the new-ish Niagara particle system.  Learning Niagara     I have decided that since this is an entirely new subsystem of the engine I would do everything in blueprint first, then transition everything to C++ when I knew it was working reliably. Additionally, because Niagara is still relatively new, the official documentation is sparse if existent at all. So with most tutorials at this time geared towards blueprint implementation, starting in blueprint will give me the highest likelihood of finding a solution to any problems I may come across. The Niagara Workflow     The first thing I learned about Niagara is that the workflow has changed significantly from what cascade was. Where in cascade (to my limited knowledge) you worked in one particle system where e...
Read more

A New Chapter

Image
     This week has presented the biggest change probably since the release of Mini Solar System; I was offered a full-time position as a junior programmer at Studio 369 which I was happy to accept. I start on Monday and I couldn't be more excited to work with the team there! However, this did mean though that my priorities shifted quite instantaneously. I went from working full-time on "RPG_Game" to preparing for this new job. This mainly meant getting up to speed on networking as that is the one area of Unreal Engine I feel I have a lack of knowledge in (I'm already proficient in UI, AI, gameplay, materials, and general backend work), and since 369's specialty is networking I figured I would come prepared. I did do a little work on "RPG_Game" but it was minimal just to tie up some loose ends. Unreal's Multiplayer Framework      As explained by the Unreal Engine documentation, "multiplayer programming [is] inherently more complex than programmin...
Read more