The Polycount Newsfeed

There's a lot to unpack here...

Starting with the game engine. Its linage goes all the way back to the first game in the series. The engine's evolution has been influenced by a variety of factors but the niche focus of the games has a lot to do with why the internal systems are the way they are. Over the course of it's development there's been certain idiosyncrasies that have carried over from version to version.

So after almost 20 years there's a significant amount of institutional inertia, both within the parent company that develops the engine and the communities that create additional content for the games. There's a lot more publicly available documentation on how to create add on modules for the game now then there was back in 2002 but there's still a certain tradition around the hidden institutional knowledge that goes into getting things working in game.

The relatively convoluted process of getting stuff into the RV engine isn't as much complicated as it is obtuse and this is part of the reason why there's a certain level of opacity when it comes to how things are created and packaged for the game. Learning the ins and outs of the asset packing process and the custom tools required to do it is a significant time investment.

There's a lot of technical back end stuff that has to be dealt with to even get basic objects in game and that makes it difficult for the uninitiated. It's not an insurmountable barrier but it's significant enough that few people have the patience to do it end to end. Which makes these engine specific skills and knowledge very valuable to players who want to mod the game.

Unfortunately that means looking at some potentially unpleasant truths about communities, development and modding. Almost every player has their own great ideas for content that should be added to the game. A decent number of players will have some knowledge of or experience with 3D modeling and texturing. Very few players will have the experience, patience and time required to navigate the limited documentation then figure out how to use the asset packing tools and write the code so things show up in game.

So only a hand full of players will actually be any good at modding the game. Of those who are, most are probably focused on their own projects and won't have a lot of time for teaching other players how to mod, much less work on packaging, programing and play testing someone else's add on content.

Even for something as basic as adding a building to the RV engine there's individual process for packing textures, writing shaders for each texture set, importing the models, configuring the different types of LODs, setting up the proxy locations, applying the textures and materials, exporting the models, writing the scripts for certain types of object interactions, writing the asset configuration files, packaging all of the assets into PBO files then play testing everything to make sure it works in engine.

The hard truth about creating add on content for this family of games is that modeling and texturing for LOD 0 is actually a relatively small part of the modding process. So while you may view doing that portion of the work as a gratuity: the person being asked to optimize and package the content, so it will work correctly and interface with the rest of the features in that particular game, probably sees it as a mountain of uncompensated work that needs to be done. All of which takes time. Time that could be spent working on their own projects or doing other things that are more enjoyable than packing textures and writing config files.

There's also a fair bit of information available in old forum posts for the game, official wiki write ups and short YouTube videos from other modders. Most of which can be discovered by working through the packaging process and searching out the documentation as each problem is encountered.

Modding has always had a certain sort of ethos around the idea that if you want help, you have to first prove that you can help yourself. So there can be a lack of perspective on both ends of the conversation. A beginner may not know just how much they do not know and someone with more experience may have forgotten just how little they knew in the beginning. Which may explain their attitude towards asking the same questions multiple times.

The games aren't small by any means but they are quite niche and they have spawned a community of fairly tightly knit groups. More so for the long time members of the modding community. Some of whom may have been modding this series of games on and off for the better part of almost two decades now. Constant critique, coupled with endless requests for content and working on public facing projects without compensation can get pretty old pretty fast.

There's no doubt that some conversations with community members will be abrasive and may make you uncomfortable. If managing these sort of interactions with abrasive personalities causes a lot of stress then it may be worth considering that the community experience you have described isn't exactly unique. Military simulation games tend to draw a certain type of personality and small modding communities can be cliquey. So do with that information what you will.

As far as technical specs for the games go: the short answer is that you can do pretty much whatever you want, within reason. Use the existing assets in the licensed data packages to get an idea of how things are setup. Most buildings in the games have some unique texture sheets but also share some reusable elements like window and door textures. Other buildings are setup with some tileable texture sheets.Usually shared between similar buildings that will appear in the same town.

A significant number of models and textures have been recycled from previous releases. So there's a lot of old school modeling and texturing techniques. However that doesn't mean that more contemporary techniques can't be used. There's a clear progression in the way newer assets are modeled, textured and packaged compared to the older ones.

This shed is one of the assets in the building sample packages and has been used in some form in the last couple of games. LOD 0 has around 950 vertices, 1150 faces and two unique view textures that are tied back to two custom materials. There's also other generic materials that are loaded into the various LODs for other functions like sounds, hit effects, penetrability, etc.

The model has 5 aggressively optimized view LODs, a collision LOD, an effect position LOD, a stand area / path LOD, a shadow LOD and a penetrability LOD. Most of these LODs will need to be made by hand and configured with the appropriately named vertex selections and materials for the building model to behave as expected when loaded into the game.

View LODs have to be fairly aggressive because of the wide range of view distances. A player in a helicopter who has the view distance maxed out at 12,000 meters could be pulling in building assets from literally across the map. So not only will having poorly optimized view LODs cause performance issues they can also cause game play issues if they don't obscure players who are trying to hide from other players at long distances or high altitudes.

It is possible to get models in game without creating and configuring all of these LODs but that means most of the special attributes players will interact with (Like basic collision, having cast shadows, being able to stand on multiple levels, climbing, opening doors, firing through glass,etc.) won't work and [if memory serves] in extreme cases it can cause undefined errors that just churn out nondescript error messages.

Properly configuring the model for a small house by setting up all the LODs with the correct textures and named selections can take a while.  Not to mention the amount of time that goes into setting up the config file so the game recognizes all of the named selections and proxies so they will trigger the correct effects and scripts when players pass by or interact with the building.

Though the RV engine can load textures in formats like TGA and JPG this is mostly for testing purposes and not recommended for final asset packaging. So textures will need to be properly packed into PAA files with the appropriate channels setup for the texture type. There's also an official texture naming convention but not all modders follow it and most textures are going to be packaged and loaded from the final PBO file. MIP levels are usually handled by the texture conversion tools.

One thing to consider is that it is possible to call up material and texture files from the existing game files. So it's not uncommon to see existing texture and material assets reused on new models. Though obviously there's a limit to how many materials should be called up for any given object.

After the model is imported, the LODs are setup and the materials are referenced it's time to create the config file and tie all of the interactive features in the model back to any custom scripts and the defualt functions in the engine. This config file will tell the game engine exactly what to do with the assets. Both in the mission editor and when the building is loaded into a world.

Once all of the assets are configured and exported to the appropriate file types the whole add on package can be compressed into the PBO format for play testing. Most config errors will show up on launch but some deeper script or function based errors won't show up until players interact with the object.

As far as hard technical requirements go: the recent community art contest had an entry for static terrain props and that had some detailed restrictions since the final winner would be used in a DLC package. The poly count was set around 10k triangles, with 1 to 4 custom materials and 1 to 3 unique textures 2k or less.

Based on that information, looking at sample files and being somewhat familiar with the game: it seems about right for the average building. LOD switching and MIPping is very aggressive at long view distances to try and keep the performance bottlenecks under control. So having well optimized view LODs and reasonably sized, well packed textures is important.

It is worth noting that there is [or used to be] a hard vertex limit of around 32k per LOD per model file. Anything beyond that used to cause an engine crash but it looks like they may have done some upgrades to the engine that allow it to support larger vertex counts. Older version of the engine will probably still have that limit. Either way, most small buildings shouldn't require a lot of polygons. Interior fixtures and other debris can be loaded separately either as proxies or as individually placed objects. Otherwise the collision LOD could become overly complex.

Opinions on technical restrictions and existing content: What's going to make sense for this project really comes down to the individual buildings and how they will be used. Is this something in the background players will just pass by or is this a key location that players will be interacting with up close?

If this is a bunch of sheds and minor outbuildings that aren't related and will be sprinkled across the map then it probably makes sense to follow what the developer has been doing and put each of them on their own smaller texture sheet with a single material.

If this is a medium sized house or larger then it starts to make more sense to use a 1k or 2k trim sheet for that house since that still only counts as one material. In the end, that level of optimization is still on par or better than what's already in the game.

If this is a large complex building or a series of buildings that will load in at the same time when players visit a town then it starts to make sense to use more polygons, trim sheets and a higher material count.

Overall the materials system is fairly limited and the games tend to have a very specific aesthetic so there's only so much that can be done with the dynamic elements of the shaders. Pretty much just basic specular and some normal details. Texture size is probably fine at 2k but it really comes down to matching the textel density of the existing assets.

Most of the medium sized buildings in the game are already using a few different texture sheets with unique unwraps and multiple materials. So it might make sense to use some more contemporary texture layout strategies with old school modeling techniques to try and keep the texture count and poly count on the lower side to match the existing assets in the game.

Going from multiple unique unwraps per building to a single unique unwrap with shared trim sheets seems like it would be an easy way to cut down on the number of unique textures and materials that are being loaded for any one building or at any one location on the map.

There may be an argument against using trim sheets because of how aggressive the view LOD optimizations have to be but it's still hard to justify not moving to a more efficient packing system like building or location specific UV sheets with trim elements at the top or bottom.

Even if it requires a slight bump in the poly count at lower view distances and stretching or omission of certain trim elements at the 1-2km view distance, loading a shared trim sheet and unique texture should still be more efficient then what's currently happening with the buildings that have their own unique unwraps spread out over multiple texture sheets.

Even as obscure as some of this technical  stuff is, with all the documentation that's currently floating around, it's possible for a single artist to slowly work their way through  the process and get stuff in game. Just takes some determination and a desire to learn how things work.

Sometimes the best place to start is searching for existing documentation and looking at how the existing game assets are structured. Use this information to try and work through the entire process on a smaller scale to get a sense of what's all involved in moving something from a concept to working in-game asset.

Addendum 2023: This post was written before the launch of the Enfusion site, ARMA Reforger and the associated modding tool kit. At the time of writing, DAYZ standalone still relies on the older development tools and processes discussed in this post. The important takeaway here is less about the engine(s) and more about jumping into a modding project to figure out how things work.