Summer Work (Day 20)

Texture Automation

    First off, I haven't updated this blog in a few days. That's because I was out of town for some time, and until I go back to school that will happen a few more times, mostly over the weekends. Regardless, I have managed to make at least some progress today in the realm of texturing these planets. 

    The one thing that I wanted to accomplish today was to automate the process of creating the curve atlases. This was to catch up to the tutorial series in which Sebastian Lague creates a texture based on the color gradient. But as mentioned in previous blog entries, this approach will work in Unity but not Unreal. 
    In Unreal I decided to just use the atlas directly instead of trying to create a genuine texture. This meant that I had to fill all gradient curve slots in the atlas with the gradient that I wanted to use. The problem with this is that the atlases must be square. So if you want a texture resolution of 256 so you get the most color detail, that means you also need to fill 256 gradient curves. Doing that manually would be stupid and if you wanted to change the gradient you are using, it would be incredibly time consuming to manually replace all the curves. So instead of doing that, I decided to try to automate that process.
    Initially I tried this:
void ColorGenerator::UpdateColors()
{
	ColorSettings->Atlas->TextureSize = TextureResolution;

	for (int i = 0; i < ColorSettings->Atlas->MaxTextureSize; i++)
	{
	    ColorSettings->Atlas->UpdateGradientSlot();
	}

	ColorSettings->Atlas->UpdateTextures();

	for (int i = 0; i < ColorSettings->DynamicMaterials.Num(); i++)
	{
		ColorSettings->DynamicMaterials[i]->SetTextureParameterValue(FName("_texture"), Cast<UTexture>(ColorSettings->Atlas));
	}


This code resulted in this planet:

And this atlas:

    Very weird but not what I wanted. After some tinkering, I found that the UpdateGradientSlot() was not doing what I thought. Eventually I found that what I actually wanted was to change the GradientCurves array. This is what I ended up working for me:
void ColorGenerator::UpdateColors()
{
	ColorSettings->Atlas->TextureSize = TextureResolution;
	ColorSettings->Atlas->GradientCurves.SetNum(TextureResolution);

	TArray<UCurveLinearColor*> Curves;
	Curves.Init(ColorSettings->Curve, TextureResolution);
	ColorSettings->Atlas->GradientCurves = Curves;
	ColorSettings->Atlas->UpdateTextures();

	for (int i = 0; i < ColorSettings->DynamicMaterials.Num(); i++)
	{
		ColorSettings->DynamicMaterials[i]->SetTextureParameterValue(FName("_texture"), Cast<UTexture>(ColorSettings->Atlas));
	}
}

    The initialization of the array will need to change in the future as I go on to add biomes and that will require multiple sets of gradients. For now though the end result is the same, just the behind the scenes has become more streamlined.


Sidenote: The height issue from day 15 has decided to fix itself and the gradients actually read from 0 to 1 instead of 0 to 0.55. This might have happened when I updated the source engine but regardless I'm glad that it's fixed.

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