Summer Work (Day 16)

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 new asset, you will see that the simple UI from Unity has been replaced with an over-complicated menu that gives you more options than you will ever need in your lifetime. But for real though, it gives you lots of really cool options to mess with the colors, even if you won't need all of them at once.
    So now you have a color gradient, but how do you get that into the material? Good question. The answer is by creating another asset to bridge the gap between color and material. This asset is called a "CurveLinearColorAtlas" and you need it for the parameter in the material graph. But before that happens, you first have to plug your Color Curve from before into the new Atlas.


    Now to get all of that into the material. The node needed is called "CurveAtlasRowParameter". With that in your material graph, you can select the Atlas and "Row" which is the Color Curve that was added to it. At this point the curve can be hooked up to the rest of the graph and be functional.


    Here's where I ran into a problem. I wasn't able to figure out how to access the curve variable from within C++. All I was able to find were getters to for the Curve variable and I was unable to set it to the variable that I defined in the beginning. I hope to find a solution for this soon, but since it works right now I am satisfied.
    The second problem has to do with the curve itself:


    As you can see in the picture above, the "mountain" part of the texture starts at about .5 where it should be at 1 or the highest elevation on the planet. I did some testing to find out why this was and I think I have an answer. The min/max values that I made last time are working correctly and are also applied to the material correctly so it wasn't that. My suspicion is the problem lies in the LocalPosition->VectorLength value that controls the lerp (see second picture up). Somehow this value isn't quite reaching the max elevation of the planet so I will have to find some way to fix this in the future.


All current code available here: https://github.com/setg2002/CppGame

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