Summer Work (Day 19)

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 useful in the future for creating a mask separating land from sea; but it wasn't what I wanted. I eventually realized that this happened because of the way the atlas was created. Whereas before I was plugging in the height directly into the 1D curve, now I was plugging that value into a 2D texture. The atlas had a resolution of 256x256 but only one of those rows was populated by the color curve. When I reduced the resolution of the atlas to 32x32 and populated all of them with the curve (because there was no way I was going to manually add 256 curves) the planet went back to how it should look. 
    Now, in hindsight, I should have stopped here. I should have continued using the atlas as a texture because it gave me all I needed, but I didn't. Because I have a stupid ape brain I decided that since the tutorial created an actual texture, so should I.
    This sent me down a long rabbit hole trying to find a way to either convert an atlas to a texture (which as previously mentioned I didn't need to because atlas inherits from UTexture) or write pixels directly to a texture (like Unity would do). The only little thing that I found was TextureRenderTargets. A cool feature in Unreal, but not for what I wanted to use them for. Other than that all I found were super complicated ways of getting pixel values but never setting.
    After all this time of ignoring atlases, when I finally looked back at them being a possibility I noticed all the ways in that they could be superior. They support linear colors unlike any of the other options, they can be used as textures, the curves they contain can be edited and referenced within C++ (this will help when I do biomes), and they have a lot of editing options just to name a few. 
    With that, going forward I will commit to using atlases as my planet texture. My hope is to be finished with this tutorial within one and a half to two weeks.

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