A question regarding the ideal work flow for texturing buildings in Dayz and Arma3.

odduy77

(i made a new account but im actually a shy polycounter of several years and I know how to model etc.)

after a long break away from modeling I'm planning on making some buildings for Dayz. (i tagged Arma3 in this because it seems a lot of the workflow is identical but somethings are different and this post could help arma people etc)

Currently the only problem is getting hold of enough information about the best workflow for texturing the models I intend to make.

I dont intend to do the porting, other people will do that, but i have to provide them with models in a game ready state, this includes the LOD models, as well as the hit boxes etc ( there are few other meshes, similar to hit boxes, for ai and things like that I wont go into that here.)

a lot of the modders/modellers I've spoken to online all have really varying levels of advice, and I've found the various online groups for discussing modding dayz very mixed in their views, some aren't fussed about the file sizes.

also sometimes those communities aren't too nice, if I ask the same question twice, on different communities, i will often receive a dm from someone scolding me for asking a question twice. etc. and I've found that a bit stressful to deal with, especially when you want to provide that community with free labor.

for example with my own experience with 3d environment/building texturing, I started off texturing scenes for architectural renders, which involved applying tiled textures in Google Sketchup to my bosses' models. size wasnt an issue for this and I could have a folder full of loads of 512 textures.

then I moved on making game assets, using tiled trim sheets and striving to squeeze as much visual data on to a 1k atlas map.

how many shaders/materials can  I give to an object?

now with Dayz, I can't find a clear answer from people regarding how to compile the visual data, how many maps/trim sheets, should a building have? (an ideal number)

do I need to produce mip maps? or does the engine generate those?

would you go with 2k or 4k? (someone told me the buildings they have made use loads of 4k tiled textures ! thats not trim sheets, thats loads of individual textures at 4k, which seems a bit absurd waste of memory or a bit amateur.)

How many uv maps can the models allow? is there a particular naming convention etc?

once i know this stuff, I can actually move on and make something, (speaking for myself) there is no point making anything until I know how it will be uv mapped so I know if it has parts which I will bake etc.

Ghogiel

Most of your questions rely on knowing what the environment you are building is, profiling/testing in the engine, limitations of the shaders/engine. You're probably not going to like the answers from here because I'd guess polycount collectively knows even less about the engine than those dedicated modding communities .

Use as few materials/trims as possible, the limit is going to be for the whole scene wih game conditions in engine, which no one knows, so nothing more specific can be said. You kinda need to have a real good look at existing levels, do some testing, and be prepared to make some optimisations if needed.

odduy77

Ghogiel said:

Most of your questions rely on knowing what the environment you are building is, profiling/testing in the engine, limitations of the shaders/engine. You're probably not going to like the answers from here because I'd guess polycount collectively knows even less about the engine than those dedicated modding communities .

Use as few materials/trims as possible, the limit is going to be for the whole scene wih game conditions in engine, which no one knows, so nothing more specific can be said. You kinda need to have a real good look at existing levels, do some testing, and be prepared to make some optimisations if needed.

i just had a message from someone elsewhere saying that the object they made had 7 different materials/shaders! no idea if thats what the engine was designed for, but it definately seems to go in the face to the usual stuff we get taught at polycount and in the cg community.

also, currently I can't test out the models (Arma and Dayz have a thing called a p drive for stuff like this) because I'm actually without a gaming pc at the moment and im doing everything on a tablet.

FrankPolygon

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.

Another thing is that, since the vast majority of mods are distributed at no cost to the players, it builds up certain expectations around modders working for free. Which can lead to certain cycles of toxicity within the player base and modding communities. While this does not excuse toxic behavior nor does it belittle your experience, it does explain some of the factors behind it.

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.

There's also a whole host of building specific, named vertex selections that control things like rotation points, light / sound emission points, script action points and so on that all have to be tied back to game functions via the model itself and the add on configuration file. Proxy objects and memory points will also need to be added to the model for things like internal debris, doors, ladders, etc.

A lot of these are represented by single, named vertices and will have to be added manually to each applicable LOD in the tools provided by the developers. All of these different LOD meshes and named vertices will also have to be packed into a single engine specific model file for each structure. No small task for something even as simple as a small shed.

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.

It is possible to assign basic texture files directly to the model but to enable the specular and normal passes it's necessary to write a material shader that references each texture file required for each type of unique material. This material file can then be assigned to the model in place of whatever basic textures were loaded before hand. There's some official tools and a few unofficial tools that can be used to speed up texture packing and material creation.

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.

Other thoughts about modding in general: At the end of the day there's the unfortunate reality that a lot of players have a lot of good ideas but there's very few who are willing to put the time in to learn about and figure out all the stuff that goes into making things work in game. Those who do are inevitably swamped with their own work and requests to work on other people's projects. There is a certain amount of hidden institutional knowledge but even quick searches to confirm some of this information turned up lots of threads and documentation.

There's a fine line between asking for help and expecting other people to do everything on the back end to make it work. Modders who aren't being compensated for their time don't really owe anyone in the community anything. Trying to give someone else more work to do and expecting them to do it for altruistic reasons isn't fair compensation, it's exploitation. The amount of effort that goes into gaining this back end knowledge and putting it to work deserves to be compensated.

A more equitable solution is to pay more experienced people for tutelage or join an existing mod team and get some seat time doing the grunt work to get a better understanding of the whole optimization and packaging process.

It's just one of those things where there really isn't a short cut around it unless you want to pay someone else to do it for you. Sometimes it works out where it's a mutual thing and a few artists work together to add some content or features they want to see. Other times it's just one person that wants to work on their own thing.

The world is full of people with ideas and dreams. Only a few are able to pay someone else to do the work for them. The rest have to be willing to make time to sit down, learn and work to make their art happen. Show some finished work in game to people and it's easier for them to get on board with helping.

One of the reasons mod projects fail is most people just want to do the cool creative stuff and few people want to do all of the back end technical stuff that's required to get the models into the game. This can lead to a lot of internal friction. So it can be relatively difficult to find someone who will stick around long term and reliably do all of the heavy lifting on the tech work without some kind of compensation.

When the tech artist inevitably burns out they leave the project and the team has to scramble to find a replacement and bring them up to speed on the existing project structure that may or may not be well documented. Experienced modders tend to be aware of this cycle and are understandably cagey about requests that require significant time investments and are outside of their area of interest.

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.

Ghogiel

I take back what I was saying about polycount not knowing as much about that engine....

sacboi

Cheers, thanks for sharing your insight Frank, as an ex-player come wannabe modder of the game.

gnoop

FrankPolygon said:

There's a lot to unpack here...

One of the reasons mod projects fail is most people just want to do the cool creative stuff

For some reason all game companies I ever worked for  never  cared too much  for making something  simple and easy, and as much automatic  as possible   to do all that  game mechanics stuff.

I recall writing and editing  long  special scripts  and then wasting hours trying to figure out what went wrong,    dealing with super crashy  and super user unfriendly  in house tools or even writing lengthy "objects properties" and viewing distances  in 3d max for one mobile game.

My guess it's lots of expensive programmers time  vs cheap artists one and never a priority. 

 

Even Unreal which is way ahead of anything in that regard is not a  great User Experience  achievement  IMO.

odduy77

FrankPolygon said:

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.

Hey, sorry about the late reply, the last year or so, I haven't really been doing any 3d design stuff and I kept forgetting to look at polycount.

firstly thank you for the in-depth reply.

since the point when I last wrote this message, i have been asking the same sort of questions elsewhere and I have come across a really wide range of answers, one person said 'just dont go above 2k cause...' another person said they do all of their building textures in 4k, these are tiled textures for buildings, and no mipmaps they also claim, they didnt seem to know much about multiple UV systems.

another person ex-BI via artstation gave some better answers, but still it was really vague and didnt answer the question, of how many textures I could expect to use on a house, what size they are and how they should be compiled.

i will keep asking people. but it seems like the range of answers if quite wide and I prefer to go with the professional approach to this, instead of myself creating something which will be buggy and cause problems and generally be a waste of time.

Alex_J

odduy77 said:

I prefer to go with the professional approach to this, instead of myself creating something which will be buggy and cause problems and generally be a waste of time.

I think you got it backwards. Testing case by case basis is the professional approach. Because it is the only way to know.

Make something based on the information you have now (frank outlined what the specs are in a recent challenge so that is probably as good as you can get), and get it in engine. Identify any problems. Then you'll be able to get it right through process of iteration (i.e., doing the work many times).

That's called testing. Everybody does it. Nobody can avoid it. If you don't like doing work many times, you won't be a professional. That's just how the work goes. How do you think technical requirements are determined in the first place? Somebody spent time testing.

It's not a "my daddy beat me, so I'll beat you" thing. It's just that you cannot know what the truth actually is until you do the test. Every situation is different so a responsible person who understands the work environment isn't going to say, "this is what you must do." Because they haven't done the test. They don't know.

Having a narrow scope of responsibility and not having to do any testing will only exist on the largest teams and at the lowest levels. In making mods or your own projects, you'll never be able to work like that. The biggest part of your workday will be spent testing to figure out tech requirements and designing workflows through iteration. Once everything is figured out, then you actually grind out some art. Then you learn something new and go back to the testing phase. It never ends. 

If you just want to make models and textures and not worry about anything else, you can do that but it would have to be part of a large team.

odduy77

Alex_J said:

odduy77 said:

I prefer to go with the professional approach to this, instead of myself creating something which will be buggy and cause problems and generally be a waste of time.

I think you got it backwards. Testing case by case basis is the professional approach. Because it is the only way to know.

Make something based on the information you have now (frank outlined what the specs are in a recent challenge so that is probably as good as you can get), and get it in engine. Identify any problems. Then you'll be able to get it right through process of iteration (i.e., doing the work many times).

That's called testing. Everybody does it. Nobody can avoid it. If you don't like doing work many times, you won't be a professional. That's just how the work goes. How do you think technical requirements are determined in the first place? Somebody spent time testing.

It's not a "my daddy beat me, so I'll beat you" thing. It's just that you cannot know what the truth actually is until you do the test. Every situation is different so a responsible person who understands the work environment isn't going to say, "this is what you must do." Because they haven't done the test. They don't know.

Having a narrow scope of responsibility and not having to do any testing will only exist on the largest teams and at the lowest levels. In making mods or your own projects, you'll never be able to work like that. The biggest part of your workday will be spent testing to figure out tech requirements and designing workflows through iteration. Once everything is figured out, then you actually grind out some art. Then you learn something new and go back to the testing phase. It never ends. 

If you just want to make models and textures and not worry about anything else, you can do that but it would have to be part of a large team.

so regarding my original question, do you have any idea if they use a single atlas texture or just a folder with loads of individual tiled textures in them?

Alex_J

Arma 3: How to make and import custom textures into Arma 3 via Editor - Bing video

quick search i see at least five tutorials like this ^

I skimmed through a couple and it looks like most vehicles are using a single texture image for most of the body. Probably other parts use another, and of course there is extra decals sometimes to. 

So I think you are safe to assume a building can use a few texture sheets or more. If you go slightly overboard it's not the end of the world, you can always repack. 

If you don't know a lot about how shaders typically work but you can get the textures from an existing building, it wont be too hard for any enviro artist to understand how they are being used. That is a more specific question that can yield a more specific answer. But you have to do some leg work first obviously. 

Get ahold of an existing model and it's textures - one from bohemia base game would be best - and you'll be a lot closer to answering your question. Enviro artist can help you understand what you are seeing, doesn't have to be somebody who knows about modding this game.

another caveman

So this is not about the Arma integration, but about modeling-texturing itself, for this kind of levels.

Here is a tutorial series from Radiant (Call of duty) patch modeling, it's very relevant even for modeling in other engines / other softwares

https://www.youtube.com/watch?v=3EmyjrIELjg

Check the youtube channel for much more tutorials. I guess you can watch them at increased speed as you don't really mind knowing the Radiant (engine) UI but there are some good tips given out loud in there.