Well, it’s been quite some time since I last updated the site, and I’ve been hard at work during that time. I have completed the majority of the work on the modding code to allow modders to create content of their own and package it all up into a mod that players could unzip into the “Mods” folder of the game. This is done via the UGC Plugin that was developed by Epic as part of their VR game, titled RoboRecall. However, there were some pretty glaring omissions in the functionality, due to the intentions of the plugin’s scope.
The UGC Plugin was meant to be very bare-bones in functionality, allowing the developer to decide what, exactly, they wanted to allow their modders to do. The plugin could enable mods as small as just remeshing/skinning some of the in-game weapons, to fully side-loading entire levels with custom game modes. The largest omission of functionality was the ability to easily get players to a new level provided by the mod, and get them back to the main world. This needs to be done entirely within the mod, without the ability to place anything in the main world, and with as few other limitations as possible on the mod developer. I came up with a solution that I hope modders will find a good compromise…spawnable POIs.
A spawnable POI (or Point Of Interest) is a self-contained POI that can include a special trigger volume that will transport players to a separate map that the mod developer has created. This system can handle POIs that have multiple entry/exit points, without the mod developer having to jump through too many hoops to get it all to work. This would allow, for example, a cave complex with numerous entrances to it. When the player(s) enter the cave, they will spawn in at the correct entrance and, when they leave the cave complex, they will spawn back into the main world in the correct location. If they enter through a jungle cave and exit right back out the way they came in, they should be in the jungle. However, if they enter the jungle cave entrance and exit via the tundra cave entrance, they should spawn into the world in the tundra. This seems simple, but keep in mind that the mod developers will not have any way to directly place anything in the main world. Everything will have to be done via the spawnable POIs. We wouldn’t have a problem including the main world, but we are using quite a lot of licensed assets, and we do not have the legal right to distribute those assets to mod developers. Copyright issues are a tricky subject, and are best avoided whenever possible.
The last bit of functionality for our version of the UGC Plugin will be UI related. This functionality isn’t worked out yet, but it really does need to be in place when the game ships. I realized that this was missing while watching some videos on YouTube. I noticed a content creator using a mod for a game, and this mod reorganized the UI for that game. This is something that I will need to add to our version of the plugin, but I don’t anticipate any major hurdles to this…famous last words, right?
Aside from all of the work on the UGC Plugin, I have been working on some procedurally generated models that are part of a modular kit that will be used in the game. This modular kit is for a long house used by some of the peoples that inhabit the tundra region of the crossroads. These are the Daursynka people, and they are loosely modelled after the Iroquois Confederacy of the north-eastern region of North America and the Viking peoples of Scandinavia. These houses were a challenge due to their size and detail. They need to be large enough to house an entire extended family, and be detailed enough to maintain the visual fidelity that the other game assets are already at. But, I also needed a fair amount of variety in the pieces because there will be multiple longhouses at each settlement. I want to avoid obvious repetition as much as possible, while maintaining a reasonable degree of performance. The latter part of the previous sentence is key here; performance must always be considered in any real-time application.
To create the kit pieces for the longhouses, I chose to procedurally create all of them from “building block” pieces that I could easily obtain from Quixel. For example, the roof tiles seen in the featured image for this article are all positioned via geometry nodes in Blender. This allows me to randomize the individual tiles and get a nice variation between the roof sections. Please note, however, that I was lazy in the creation of the image above and I just used an “Array” modifier in Blender to duplicate the roof sections (I am sufficiently ashamed by my laziness here). The modular kit features numerous variations of the roof section, not just a single section with a single tile pattern. This approach allows me to use a set of textures for the tiles, wall slats, beams, and other individual pieces and get a level of quality that would have required much more texture space in the RAM of the player’s video card if I had went with a more traditional approach. The traditional approach is to create all of the geometry in your software of choice (Maya, 3DS MAX, Houdini, Blender, etc.), and then import that geometry into Substance Designer or Quixel Mixer to “paint” the textures onto the geometry. With this more traditional approach, we would need to use a much larger texture to get the same visual quality. We are still using a not-insignificant amount of RAM, but nowhere near the amount that would be needed to get both this level of quality and this degree of variation in the kit.
In Image 1, you can see the picture used as the featured image of this post. Each element that makes up the modular kit pieces is an individual object that is placed via geometry nodes, with it’s rotation randomly tweaked ever-so-slightly to break up the uniformity of just laying everything out using the modifiers available in Blender. This could also be done in an application like Houdini, which I have used before. Blender doesn’t feature the same freedom in it’s procedural tools as Houdini, but the geometry nodes are quite powerful, and do allow for an amazing amount to be done with them. Doing something like this by hand would take many, many more hours than I spent learning the geometry nodes in Blender. The same basic approach was taken for the wall pieces, which are made up of slats with the gaps in between being filled with tar covered thatch. Geometry nodes can also be used to affect the vertex colors of geometry, and this was used to allow blending between a “tar” material and the material used for the wooden slats. You can see the effect of this in Image 2. The tarred thatch is represented by a simple plane that is textured to look like thatch that has been dipped into a vat of tar. At least, that is what I hope it looks like.
The image above shows a simple rendering of the front of the example longhouse. If you look at the wall that is set further back, you can see that the slats have “smears” of tar where they come close to the plane representing the tarred thatch. However, to work with the vertex colors of the generated mesh, the modifier for the geometry node network used to generate the wall piece needs to be applied. Only after that was I able to add the vertex color map and use the geometry node network that alters the vertex colors. If you look closely at the wall for the front of the foyer, you will notice that it lacks the darker smears of tar that the back wall features. This is because the foyer’s front wall hasn’t had the node network generating it applied yet. Without this, any vertex color map added to it will not be accessible to the node network designed to change the vertex colors. At least, I couldn’t get it to work, and I spent quite some time trying.
What you don’t see in the images above is the sheer volume of variety that can be obtained by creating the wall pieces (or any pieces for that matter) via the geometry node network approach. Each slat type used is a separate mesh, with it’s material applied to it. There are six different slats, all held in a single collection, that the geometry node network chooses from when placing each individual slat. All of the wall slats for any of the wall pieces can be randomized not only in the slat mesh chosen, but also the positioning and rotation as well. Once the vertex color network is applied to the wall piece, it is hard to believe that it is made up of nothing more than six different slat meshes randomly chosen and placed.
Another feature of these longhouses that is not visible in the images above is the thatch cards that are placed on the plane that represents the tarred thatch that is shoved in between each slat. It is highly unlikely that anyone stuffing thatch into these gaps would get it into the gap perfectly, which means that there would be a bit of thatch sticking out here and there to flutter in the breeze. That is where those little thatch cards come into play. Using a traditional modelling approach, placing each thatch card would be done by hand, probably by an intern who was questioning their life choices as they positioned each little thatch card. But, through the power of procedural modelling by virtue of geometry nodes, we can easily place thatch cards in between each wall slat. The best part is that no matter how each slat is rotated and positioned, the geometry node network for the thatched tar plane will recalculate where a thatch card can be placed without it ever being positioned where a slat is.
In Image 3, you can see a small portion of the node network used to place the thatch cards on the plane representing the tarred thatch. The entirety of the node network isn’t shown because the view would need to be zoomed so far out that you wouldn’t be able to read or see anything of note. The key idea to take away from Image 3 is the Raycast node in the network (you should be able to right-click on the image above and view it in a separate tab, allowing you to zoom in to read the node names). First, I used a “Distribute Points on Face” node to randomly place points on the tarred thatch plane. These points are where thatch cards could potentially be placed. With the Raycast node, we can do line traces and check if there is an intersection anywhere. In my case, I didn’t want to place a card anywhere that there was an intersection with the wall slats. Only where the raycast found no intersection should a thatch card be placed. The Raycast node is a bit strange to get used to, because it doesn’t work exactly the way that a line trace does in, say, the Unreal Engine. So if your interested in using this node, read the documentation and experiment a bit with it. It is worth your time to learn it.
Well, that was a lot to take in. I hope that I was clear in my descriptions, but the topics covered in this post are very complex. Without a large number of visual aids to help, it can be difficult to get my point across. Modding is a huge feature that I felt would be a great benefit to the game. Players will not be beholden solely to us for game content. If a mod developer wants to create a completely new dimension to the game (a new level of Hell perhaps), they will be able to do so. And, with the power of procedural modelling via Blender (or some other software like Houdini), they will be able to shorten the development time needed to make the custom assets they want. Thank you for taking the time to read this post, and I hope that you have a great day.