Python & Planets

     This week I enabled python in the project and I've begun the process of adding randomization to the planets.


Python

    I wanted to enable python scripts for the project because I knew that Unreal supports it, but I've never tried it. It's also been a while since I used Python and I wanted an excuse to use it again. The simplest use-case I could think so use it for was to generate the skybox texture. This would involve interfacing with the editor world, accessing actors from the world, and executing preexisting C++ code on said actor. All basic building blocks of things I may want to do in the future.
    I began by following the official Unreal docs, and I was able to get it up and running relatively quickly. I did hit a small snag in getting PyCharm to recognize the interpreter that comes with the engine. But of course I wasn't the first to have this issue and as always the forums were able to guide me through it. Once I had the interpreter and auto-complete working it was time to make that first script.
    Writing the script to generate the skybox was relatively simple. The UE Python API is quite straightforward and you can do things in much the same way as you would in C++. In fact, the unreal module exposes nearly everything that is exposed from C++ to blueprints. You're able to see everything in the gargantuan unreal.py file, which is hilarious to debug.
    So when I went to call MakeTexture() on the skybox actor it was already there waiting. This is the script that I came up with:


    It is very simple, but having this in my back pocket will allow me to use Python to script in the editor however I want in the future. Also, while I was doing this I realized how slow it is to generate the texture and it got me thinking that the work could be parallelized. It's not something I would be thrilled to go back to so soon, but I don't know, maybe I could put something quick together to make it a little smoother.

Randomization

    The main goal that I am now working towards is being able to generate an entire solar system fully procedurally. The player should be able to select a new game save and be able to pick between a preset system and a new random system. Maybe even with some parameters that can be tweaked for a custom starting system. This will be a multi-part undertaking as I need to implement ways to randomize multiple very different systems. 
    I am starting with the terrestrial planets as they are the most complex and will also have the most overlap with other systems. Finishing them first will make everything else much more simple. There are two steps to randomizing the planets: shape and color. The shape randomization was very simple. I was able to randomize the different float, integer, and vector parameters of the noise used for terrain generation within a range. I will need to revisit this later to tune the ranges and probably make some sort of algorithm to tie certain parameters together as right now it is capable of making some planet shapes that are totally incomprehensible. 
    Randomizing the color was a bit more involved. The color settings contains pointers to multiple UCurveLinearColor or color gradient assets. Of course I already had helpers to create the asset, but filling it with random colors would require a bit more thought. I knew I didn't want to just choose colors completely at random as that would probably result in some parts of the gradient going white as it transitioned between colors, and it would also be less cohesive.
    Looking at the way the engine picks a random color (FLinearColor::MakeRandomColor()) I noticed it was using a method that used a random hue. If I did the same thing and then clamped the delta between hues at sequential points then I could make a more visually pleasing gradient. So I came up with this:



    It uses this method to create colors for each biome that it makes as well as the "oceans". I'm quite happy with the results:


    This will certainly be an iterative process as I tune and refine the randomness to make a system that can consistently generate interesting planets. Next up I want to add similar randomization options to gas giants and stars.

Comments

Post a Comment

Popular posts from this blog

Progress Update #19

Image
  Orbit Debug/Visualizer Optimization     This week I tasked myself with optimizing the orbit visualizer. The reasoning behind this was that I couldn't render an entire orbit of planets with large orbit radii without the framerate plummeting to the low teens and that would need to change. Finding the Root Problem     The first thing I set out to do was to find out exactly why the engine was having a hard time with rendering orbits far into the predicted future. While looking for methods of debugging optimization in Unreal, I came across a presentation by the Unreal team on  Profiling and Optimization in UE4 . This talk introduced me to the stat unitGraph console command as well as the GPU Profile accessible with the shortcut Ctrl + Shift + ,     Through these methods of debugging I realized that the debug line method of rendering would hit the CPU render thread (draw) while the spline method would hit the CPU game thread. Baseline (0 step...
Read more

Progress Update #9

Image
  Bugs Beget Bugs     In the process of fixing a recent bug I have inadvertently discovered many more.     The issue that I just fixed had to do with biomes, and has existed since I implemented biome blending. The issue being that if you had more than 2 biomes the material would freak out and band the biomes around latitude lines quite strangely. Here are some pictures to help explain what I'm talking about: No biome blending Blended biomes @ 0.1 strength Expected outcome w/ three biomes Actual outcome     To try to debug this problem I first tried ol' reliable; the print string. I set up a UE_LOG in the BiomePercentFromPoint() function to see what it was returning. The weird thing was it was supposed to return something between 0-1 but it was always returning either 0, a really large number in the billions, or the same large number but negative. Something was clearly amiss so I dug deeper with breakpoints.     I set a breakpoint at the end ...
Read more

Progress Update #17

Image
Asteroid Heightmaps in UE4     The task for this week was to make asteroids more interesting by having their meshes not be plain old cubes. The original plan was to basically copy the terrain generation system from the terrestrial planets, but instead I tried challenging myself by creating a world displacement material instead. Method of Terrain:     Starting out this feature I intended to copy, essentially line for line, the terrain generation process of terrestrial planets. This wouldn't have been terribly difficult but would defiantly have been very boring, so I looked for an alternative.      I knew from messing around in the editor that you can offset vertices of a mesh through a material, so googling that led me to a video which explained all the ways you can fake depth through a material. This video also introduced me to tessellation which adds more vertices to the mesh during the vertex shading stage of a shader (...
Read more