Summer Work (Day 18)

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 for biome data. I started as I always do with these kinds of things and looked into UPROPERTY and UCLASS specifiers. The thing is, I thought I had already solved this problem with the EditInlineNew class specifier. But in reality I needed to use EditInlineNew in conjunction with DefaultToInstanced (recommended by this discussion board). On top of that, with lots of trial and error I found that you also need to use EditInstanceOnly on the property in order to edit the instance (duh). The last thing I had to do was delete the old data asset. To get it to fully work I had to replace the old data asset which I can only guess had some cached memory for being non-instanced. Now all I have to do is the same thing for all the shape settings data assets and everything should be good to go. 

All of these changes (plus some smaller ones not mentioned here) can be seen at the github repo

Future Plans:
    Also, completely unrelated to instancing, I started thinking about other things to add once I'm done with these planets. I began thinking about other things you have in space and landed on at least a few things that I also want to add besides these planets. 
    The first of these is gas giants. They make up half of the planets in the solar system and would also add variety to the planets having something other than just terrestrial planets. I am thinking the best way of making these kinds of planets would be to have a basic sphere with some sort of procedurally animated texture to look like turbulent gas movement. I have no clue how to do this as of yet but I'm sure I will figure it out when I get there.
    Another thing that is possibly more important to add would be stars. These would be quite similar to the gas giants but would emit light. This light I see as being a possible problem and something that I might have to do myself as the way that I know light in UE4 a spot light would completely overexpose close bodies and would leave bodies further away completely in the dark. 
    The last thing I thought of for now is asteroids. I would want these to be minimally compute intensive but also react to the gravity of other planets. I'm thinking this is a job for the new niagara particle system, I just don't know if it is capable of running the gravity script faster than a full actor would be.

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