Rock and Roll…
It’s time to rock out! A parametric equation is designed to create an infinite variety of unique rock shapes to sprinkle onto our generated map (map specifics explored in previous posts). These rocks are then hand painted to match the visual style of our existing map and biome.
The program used to create the 3D models is Grasshopper, which is a plugin for the 3D modeling program Rhinoceros 3D. Grasshopper allows you to string modeling commands together in a connected linear fashion while simultaneously incorporating options and alternatives into the network of commands. This ‘equation’ is parametric because it allows for the output of many different models that are both unique and visually similar because of the subtle tweaking of parameters throughout. This particular parametric equation is based on random point population, random list culling, 3D voronoi shapes, and mesh smoothing. The various rock shapes below were all created from the same parametric equation and all have a 500 mesh face count.
These shapes are then imported into Blender for texture painting. A base of brown cloud distortion is used as a strong starting point that is irregular and seamless. A different flavor of irregular noise is then layered on with a lighter color at the edges. Darker cracks are then painted across the edges to increase the nonuniformity of the colors and edges of the rock. Darker textures are then added to enhance surface variations and produce the illusion of subtle shadows and details. Finally, another layer of cloud noise is painted on top of the previous layers with a darker brown color and a soft light blend mode to produce a cohesive look.
After painting rocks, we will be rolling on to other 3D map models such as trees and small grass tufts. - Will
Blob Asset Loading Changes
Initially our Blob Assets were created in a very hands-on way within the editor. Our scene contained a Blob Asset GameObject which contained variables for the entities we wished to add to our Blob Asset. It did not take long for the number of variables we needed to assign within the Unity editor to become unmanageable, especially after the introduction of decal tiles as Blob Assets. It was not feasible for us to continue this method as a single 20 x 20 decal for the map would require 400 variables.
. The Resources folder in Unity has an API that allows for asset loading and creation via script. Our GameObjects needed to be restructured inside of that folder in order for us to take advantage of those capabilities. The idea driving this reconstruction of our GameObject hierarchy was to make our jobs, and modders jobs easier in the future. Our Resources folder would be structured in a way that would make the introduction of new designs for existing entities as easy as dragging and dropping a new folder underneath the proper parent folder in our project hierarchy.
The New Resource Folder Hierarchy
If we wanted to have multiple enemy base designs, just drop a new folder with the prefab under the EnemyBase parent folder.
The new structure of the Resources folder is arranged in a way that utilizes folder names that match enums. These enums are then used to populate the variables within a list of PrefabData structs that is created parallel to the list of loaded GameObjects. This PrefabData struct contains information useful to us when converting these loaded GameObjects to Blob Assets. Different types of GameObjects need to be in different Blob arrays, such as player building entities vs map tile entities. The folder path for each loaded GameObject is split up and parsed into their enums which allow us to add the proper data to the PrefabData struct for that particular type of GameObject.
Once the list of PrefabData structs and loaded GameObjects are populated, a Conversion GameObject is created which contains a custom ConvertToEntity script on it. This custom script uses the GameObjectConversionSystem handle contained within the ConvertToEntity method to loop through the list of loaded GameObjects and call GetPrimaryEntity on them. Essentially we are piggy backing off of the built in GameObjectConvertToEntity method to use its ConversionSystem to create the entities we will use for the Blob Assets. After all entities have been created they are added to a NativeList which is passed into the Blob Asset creation ECS system along with the NativeList of PrefabData structs.
The list of converted entities is then looped through and the Blob Asset is created with the help of the PrefabData struct accompanying the game object. This allows us to keep our Blob Arrays separate and orderly. This is still a work in progress, but the concept of loading the GameObjects, converting them using the method described above, and then creating a usable blob asset from them has been tested successfully on a smaller scale. It is now just a matter of moving our multitudes of prefabs into the newly defined Resources folder.
Stay Classy Internet,
Oggy
Continuing the trough train
The troughs are shaping up to be a much more complete package. They do some new tricks not only to continue the optimization angle, but also some quality of life. The plan is to complete the full concept of the troughs before moving onto the next big animal in the room, the gameplay loop. This week has been spent on setting up the foundation of the troughs “Master Plan”.
Centralizing resource data
Resources were placed into the game ~6 months ago and have not been touched since. They consisted of Resource Data, Physics Data, and a Mesh. Everything is identical in these resources, except for the Mesh. This placed them into different Archetypes, basically spacing them out and making literation over a lot of different types very inefficient. This is because different Archetypes cannot reside in the same ECS memory chunk. The new resources were stripped of their Meshes so they all fit into the same chunk, and a system was designed to spawn the matching Mesh along with the resource and have it match the resources movement like a vampire in a mirror. This should help some systems iteration over resources to be faster and more centralized in RAM.
LOD
For those that don’t already know, LOD stand for Level of Detail and is used in a variety of ways throughout the gaming industry. It basically will determine which model to used based on the distance the object is away from its camera (for the ones that are in rendering view). The farther you are away from the object, the less detailed that object needs to be.
I just tried this out on the Bauxite resource as it’s constantly used in our testing. In the gif above you can see there are 3 levels of the LOD. These levels consist of different complexity, one with ~200, ~30, and 6 faces respectively. The angle here is to prevent the GPU from rendering all 200 faces of the complex model x times when it just isn’t possible to see the added detail. Time will tell on how performant this really is when applied to a lot more objects, as I can only assume this is constantly calling a distance check to the camera.
Random Spawn Locations
Another small detail that turned out to be more of a task than I first thought was random placement of resources. Computers are incapable of truly generating random numbers, because no mathematical operation is truly random. Unity does have a solution for this in DOTS. They supply the Random struct as a variable, but there was some more trickiness than just that. Special shoutout to Turbo Makes Games as he had a nice video guide on how to implement this using DOTS.
The main difference between using the normal Unity Random and the DOTS Random is that one is compatible in Bursted Jobs and the other is not. Some set up is required, but its wasn’t too complicated once you have it running.
This minor change effects how troughs are filled quite a lot and leads to less predictability in the resource movement. A nice touch without effecting gameplay.
I’m holding some information back this week in hopes for next week. The dream is to have troughs complete and tie all these tiny changes together to make a truly special and unique feeling logistics approach.
Cheers,
Steg
