Will the Fun Pimps ever allow better painting choices

[bobrpggamer]

How hard can it be to add say 200 different colors with different properties, like:

 

maroon - stucko

maroon - steel

maroon - drywall

maroon - concrete

maroon - tile high gloss

maroon - tile satin

 

light brown - stucko

light brown - steel

light brown - drywall

light brown - concrete

light brown - tile high gloss

light brown - tile satin

 

and so on.

 

- of course the tile would be a mixture of colors I guess -

 

I am completely tired of the same textures since A16 and It does not seem to be to hard to do. The shapes have increased, which is nice, but the painting has not been touched much since A16.

 

I am a base builder guy, that's my thing, so this may not matter to non-base builders I guess. I was also a house painter for a while to.

 

Example:

 

 

I know the FPs have this in their toolkit, which make the job seem too easy to do:

 

 

Edited March 19, 2023 by bobrpggamer (see edit history)

[pApA^LeGBa]

I remember someone saying no, because too many different textures in blocks would cause lag. Wich is a really farfetched excuse tbh. For most people 64 zombies cause huge lag and yet we can choose that option. Also mods. They can cause huge lag and some of them do. Yet we can mod the game.

 

I´d rather believe the sxplanation that the Huelnik brothers love the old, washed out apocalypse loook so much they don´t want to change that. Wich still doesn´t explain why they wont allow us to mod the colours and make it hardcoded.

 

There is still ways around this, you can mod in blocks with a fixed colour/texture, can´t be changed after placing them though.

[meganoth]

2 hours ago, pApA^LeGBa said:

I remember someone saying no, because too many different textures in blocks would cause lag. Wich is a really farfetched excuse tbh. For most people 64 zombies cause huge lag and yet we can choose that option. Also mods. They can cause huge lag and some of them do. Yet we can mod the game.

 

I have no idea whether their argument is correct. But your logic is faulty here: The option and mods to change zombie numbers does not influence the performance of the default setting. But for example if it is necessary to add more bits to block data to store more textures then that immediately changes default vanilla as well, whether it is used or not.

 

2 hours ago, pApA^LeGBa said:

 

I´d rather believe the sxplanation that the Huelnik brothers love the old, washed out apocalypse loook so much they don´t want to change that. Wich still doesn´t explain why they wont allow us to mod the colours and make it hardcoded.

 

Making something moddable is work. It took about 19 alphas until Localization.txt mods were sent from server to clients. We can definitely conclude texture modding was not high on their agenda.

 

2 hours ago, pApA^LeGBa said:

 

There is still ways around this, you can mod in blocks with a fixed colour/texture, can´t be changed after placing them though.

 

Edited March 19, 2023 by meganoth (see edit history)

[bobrpggamer]

22 hours ago, pApA^LeGBa said:

There is still ways around this, you can mod in blocks with a fixed colour/texture, can´t be changed after placing them though.

I have laid over 20 thousand blocks already so I would love to do this but it would require destructing thousands of blocks. Can you tell me how this is done, for the next playthrough.

 

I am dying for some medium charcoal-grey blocks with some white trim. I would almost sell my soul for it, It is that important (like A1 sauce on steak).

 

Quote

I remember someone saying no, because too many different textures in blocks would cause lag. Wich is a really farfetched excuse tbh. For most people 64 zombies cause huge lag and yet we can choose that option. Also mods. They can cause huge lag and some of them do. Yet we can mod the game.

Well the color of the block does not effect the attributes of the material, like normal map, reflections, glossiness and specular. The color is just a color not a hardcoded material with all of these attributes. I am talking about the diffuse color, like the dyes in game, they are just color. If anyone is familiar with 3D content creation, they will understand that the diffuse color does not effect the other parts of the material. Why not have the dyes added to the paint bucket somehow. Just collect dyes and mix them into the paint bucket in the inventory screen

 

Here's a color picker for lighting from a mod. Could the paint have base color to start with, say white using a materials properties already in the paint material, like "adobe white" and then click advanced and have the color picker, but then keeping the material properties of the base material you pick in the paint material picker, like normal maps, reflections and so on.

 

 

Edited March 20, 2023 by bobrpggamer (see edit history)

[pApA^LeGBa]

I am sorry, i have no experience in making mods myself, only using them. There is mods that already have coloured blocks. Try the mod section in this forum, maybe someone can help you with making your own coloured blocks.

 

@meganoth a few not worn out crappy looking colours sure wouldn´t hurt. That would be a very welcome addition. People like to build. A lot. And even beeing in a apocalyptic scenario, there is absolutly no reason what so ever why we wouldn´t be able to make good looking colour when we can craft weapons and vehicles.

Edited March 20, 2023 by pApA^LeGBa (see edit history)

[meganoth]

2 hours ago, pApA^LeGBa said:

I am sorry, i have no experience in making mods myself, only using them. There is mods that already have coloured blocks. Try the mod section in this forum, maybe someone can help you with making your own coloured blocks.

 

@meganoth a few not worn out crappy looking colours sure wouldn´t hurt. That would be a very welcome addition. People like to build. A lot. And even beeing in a apocalyptic scenario, there is absolutly no reason what so ever why we wouldn´t be able to make good looking colour when we can craft weapons and vehicles.

 

Last time I tried to paint my base I was shocked myself how few (and ugly) options I had. I opted for maximum cringeworthiness at the time because beauty was not available 😉. I didn't find colors at all, just textures and don't even know if I just missed some menue or this is really all. So I understand the desire to get some good looking alternatives to what is available.

 

I just don't know what compromises have to be taken to make that possible (for example performance or maybe textures lost for the POI designers?) and with my limited knowledge I don't see any obvious flimsy excuse by the developers. The limited knowledge is half me having only vague theoretical knowledge in that area and also me not having knowledge about the constraints of this specific game.

Edited March 20, 2023 by meganoth (see edit history)

[bobrpggamer]

15 hours ago, meganoth said:

Last time I tried to paint my base I was shocked myself how few (and ugly) options I had. I opted for maximum cringeworthiness at the time because beauty was not available 😉. I didn't find colors at all, just textures and don't even know if I just missed some menue or this is really all. So I understand the desire to get some good looking alternatives to what is available.

 

Do you remember the alpha that started using the paint feature? I had it in A16 and I swear the painting materials have not changed much at all since then.

 

I think it is time for an update to this, but it sadly may never happen.

 

I just thought of this putting up "Concrete_2_Trim" with the middle normal map on it. It would be cool to rotate the material on the z axis so that you line up the middle channel properly on arches and other shapes that are not cube like.

 

Sorry for carrying on with this but I am very into 3D graphics of almost all kinds, being game engine level editor, or blender like software, and I keep on treating the building of my base like that of using a level editor and not remembering that the game is a Voxel engine and not a polygon engine.

 

I am not using unreal engine to make levels, I need to remember that I guess. Its just a game.

 

If this game stopped base building, I would not play the game.

Edited March 21, 2023 by bobrpggamer (see edit history)

[meganoth]

When I tried painting the first time (may have been A15 or A16) it had a range of colors available, I remember painting the walls of a subbase somewhere with a very conspicuous and ugly yellow so I would recognize it immediately.

When I tried to paint again recently (notice how often I do this 😁) I saw only textures, no colors anymore.

 

So either it didn't change since then and I just didn't see how to access the colors, or it was really reduced in functionality since A15/A16, for example to make way for something else.

 

[theFlu]

I'm not sure, but I think they didn't really change the system, they changed the textures available .. all kinds of wallpapers and such taking the space of the Nth color of the same rusty metal. Makes it feel like a color loss, but the system was the same; just less types with more color options.

[RipClaw]

1 hour ago, meganoth said:

So either it didn't change since then and I just didn't see how to access the colors, or it was really reduced in functionality since A15/A16, for example to make way for something else.

In A17, the existing textures were replaced with HD textures. This means that you can now see cracks, peeling paint or weathering. What was previously a uniform color became flaking paint.

[bobrpggamer]

On 3/21/2023 at 11:38 AM, RipClaw said:

In A17, the existing textures were replaced with HD textures. This means that you can now see cracks, peeling paint or weathering. What was previously a uniform color became flaking paint.

Well this may due to using normal maps or similar, I  went from bump mapping and displacement mapping in 1999 and then they started to use Nvidia's normal mapping, but its been so long since I worked in a 3D engine, it could be something else, like parallax maps, whatever that is, which I am not familiar with. A well done normal map looks like there are really cracks and other depressions or extrusions, you have to zoom in to see it is really just a flat texture map.

 

Normal Map:

 

I know normal maps are hard to make, but you can use the same normal map on 10 different color choices and you get the same result.

 

I was wrong in thinking that the materials just need color, I forgot that they are using real textures like the wood is a texture map, but it is still super easy to change the color balance in Photoshop.

 

Here is an example of a concrete texture and the different color which took me 3 minutes to do.

Spoiler

 

 

I realize there is a good reason of why there are not more materials to choose from in the paint selector. i just do not know why and I may be the only one making a big deal out of it.

 

I hope no is thinking that I am just being a "know it all", its just that I have worked game engines making levels in the mid 2000s, like thief3edit (unreal engine modified for thief 3), the Valve source engine (Half life 2) using hammer 4.0 making day of defeat maps and the dark mod (modified doom 3 engine for the dark mod).

 

And I have used 3DS max back when it was 3D Studio Max (version 3.2). Which I self taught myself, because I had no internet and I just had the 3D Studio Max 3.2 manual.

 

My First creation in 3D Studio Max:

Spoiler

I tried to simulate Global Illumination by putting omni light all around the scene.

 

Edited March 24, 2023 by bobrpggamer (see edit history)

[meganoth]

7 hours ago, bobrpggamer said:

I realize there is a good reason of why there are not more materials to choose from in the paint selector. i just do not know why and I may be the only one making a big deal out of it.

 

 

 

Thanks for the information, this mapping stuff I read about maybe once or twice years ago and there usually isn't much left of that knowledge.

 

Just on the chance I didn't explain my point ver well: It isn't difficult to add color to a block graphically, but to have that color permanently on that block in the game needs the color information to be stored in world and savegame data for every block. Adding just 3 colors to a block needs 2 bits more to be stored in each and every block.

I don't know how big each block is in storage, but likely 16 or 32 bits. And likely each bit already has a purpose. So adding just 1 bit would mean doubling the size of world data as they would have to jump to 32 or 64 bits per block.

 

This has huge implications for internal RAM and cache usage on CPU and GPU, and the amount of data transfered between disk and RAM or RAM and GPU. In consequence a serious performance hit.

 

 

Edited March 24, 2023 by meganoth (see edit history)

[Crater Creator]

I’d love to see the ability to tint the existing textures. The explanation I’ve heard from programmers, which I hope I can do a decent job of regurgitating, is that this isn’t currently possible with texture atlases.

 

It’s a sandbox game where the player can build anything anywhere, and put any block texture on any of those blocks. Ergo, all those textures have to be loaded all the time. To facilitate this the game uses a texture atlas: one giant patchwork of all the available block textures, like a quilt. When you paint a block, you’re telling the game how much to offset the atlas so the game shows the texture you want. Unfortunately, a consequence of this system is that while you could add a tint, it would tint the entire atlas at once. Meaning, that all block textures would get tinted. And if you put each texture in its own atlas, you’d be defeating the point of using texture atlases.

 

I haven’t found the exact conversation where this was explained, but here’s a reply from faatal to me asking for basically the same thing a couple of years ago.

 

 

Edited March 24, 2023 by Crater Creator
grammar (see edit history)

[meganoth]

Ok, so my guess was wrong, but memory constraints actually were part of the reason. Thanks CC for the actual facts.

 

[bobrpggamer]

50 minutes ago, Crater Creator said:

I’d love to see the ability to tint the existing textures. The explanation I’ve heard from programmers, which I hope I can do a decent job of regurgitating, is that this isn’t currently possible with texture atlases.

 

It’s a sandbox game where the player can build anything anywhere, and put any block texture on any of those blocks. Ergo, all those textures have to be loaded all the time. To facilitate this the game uses a texture atlas: one giant patchwork of all the available textures, like a quilt. When you paint a block, you’re telling the game how much to offset the atlas so the game shows the texture you want. Unfortunately, a consequence of this system is that while you could add a tint, it would tint the entire atlas at once. Meaning, that all block textures would get tinted. And if you put each texture in its own atlas, you’d be defeated the point of using texture atlases.

 

I haven’t found the exact conversation where this was explained, but here’s a reply from faatal to me asking for basically the same thing a couple of years ago.

 

 

I do not know what to say, other than the explanation makes sense to me.

 

I just REALLY wish it was simpler.

Edited March 24, 2023 by bobrpggamer (see edit history)

[Crater Creator]

Adding more textures to choose from means a bigger texture atlas. I want to stress that all block textures have to be loaded at once.

 

In most games, the level artist makes a static world and can use textures more strategically. When the player climbs a ladder out of the sewer area to enter the secret lab area, the sewer textures are unloaded from memory and the secret lab textures are loaded into memory. The level artist specifically doesn’t use any sewer textures in the secret lab area, and vice versa. But 7 Days to Die can’t guarantee this kind of mutual exclusivity. The player gets to decide what world texture goes where, and 99% of players aren’t going to account for texture memory when they paint.

 

So the texture atlas is likely already as packed with textures as it can be, just short of the point where TFP would deem the performance/memory requirements unacceptable. I’m sure if they could do more textures, they’d already have more textures. Because the level designers are in the same boat: using that same set of block textures in every POI is limiting.

 

Now, their ‘out’ is in unpaintable, standalone art assets. You know all those miscellaneous decorations, like movie posters and computers and covered wagons, that players can’t craft? Their textures aren’t part of the texture atlas. And that could be a problem, if the game had to load all these decoration assets at the same time on top of the block texture atlas. But it doesn’t, because level designers are aware that these decorations are ‘expensive.’ So they only use so many of them in any given POI. They’re relying on these decorations more and more to make POIs look better, since more block texture variety isn’t an option.

 

With that said, some block textures are very old and are slated for an update, without increasing the total number of textures.

[bobrpggamer]

5 hours ago, Crater Creator said:

With that said, some block textures are very old and are slated for an update, without increasing the total number of textures.

Well this is encouraging anyway. Thank you again for explaining the engines use of textures.

[zztong]

I wonder... just spitballing here... could you conceivably add a second (or multiple) texture atlases? If so, you'd need a way to convey which atlas to use other than via block data. Could a block be associated with data from the POI from which it was placed? If you use F11 in-game, it knows which POI you're standing on. If so, how about if the POI picks which texture atlas is used for its blocks? Then you'd have maybe one byte to be sent/stored for each POI.

[Riamus]

3 hours ago, zztong said:

I wonder... just spitballing here... could you conceivably add a second (or multiple) texture atlases? If so, you'd need a way to convey which atlas to use other than via block data. Could a block be associated with data from the POI from which it was placed? If you use F11 in-game, it knows which POI you're standing on. If so, how about if the POI picks which texture atlas is used for its blocks? Then you'd have maybe one byte to be sent/stored for each POI.

This could be a very useful solution to the problem, at least for POIs.  It wouldn't help with bases unless your base is in a POI, but it's a big improvement for POI design.  Here are a couple thoughts on this...

 

• Option 1: Provide a lot more textures (each with different colors) to choose from and allow a POI designer to create their own atlas by selecting the textures and color combinations they want to use in their POI.  There would be a maximum number that can be equal to what we have now and this atlas would be used in place of the default atlas.  Benefits: You can have a huge number of texture and color combinations and options for the POI designer to choose from and they'd just have to pick up to the maximum number and those would be used for all painting within the confines of that POI.  Cons: To create their own atlas for each POI means that each POI needs a fair amount of extra space to store the values of each texture/color.  However, because you have a relatively (compared to blocks) limited number of different POI in a game, this will not be a serious increase is save space.
• Option 2: Create a variety of preset atlases to choose from and allow POI designers to select one of these atlases.  Benefits: You only need to save enough addition information to select the correct atlas saved in each POI, so space is insignificant.  Also, POI designers just select from a group of preset atlases and don't need to spend time creating their own.  Cons: Preset atlases may not have the combinations of textures and colors that the POI designer really wants.  Perhaps this can be made possible to mod in your own atlases to compensate?

One thing about these is that if the atlas has to be loaded to view the textures and colors, it becomes problematic when you are viewing something from outside the POI's area.  You could conceivably see it with one set of colors and textures only to have it change when you go onto the POI.  There would need to be some way around this problem.  You wouldn't want to load a bunch of atlases at once just because each nearby POI uses a different one.

 

Going back to the atlas situation that was being discussed earlier... why does color have to be attached to the atlas?  It could be entirely separated from the atlas.  Or, better... let's say the atlas can have 30 items without using too much memory.  Would it not be possible to have the first 20 or so be unpainted textures and the last 10 or so be colors.  Then blocks can point to 2 items- texture+color and those would be combined.  I do know this adds another value necessary for the block for each side and therefore can add significant space.

 

Another thought... Are we using numbers (I assume we are) to point to textures?  I know we have more than 10 textures to choose from right now, so we are presumably pointing to a texture with a 2-digit number, allowing for up to 100 choices (00-99) without changing the size space needed to store the info.  Switch to alpha-numeric and you have significantly more space with only the 2 bytes of space.  With that significant number of choices, you can have something like 1-10 being ten textures unpainted, 11-20 being the same ten textures in red, 21-30 being the same ten textures in blue, and so on.  Even with only 100 choices, you could do this if you don't want alpha-numeric!  The atlas would just have unpainted textures, so can have more than we have now by not having multiple versions of many of the textures in different colors (like cement).  What is saved to the block's side is still pointing to the atlas, but it is grabbing the texture and color based on where in the range it's looking.  Basically, the atlas isn't storing colored versions.  The game is setting the color on the block after getting the texture from the atlas.  So in the example I gave, 11 is really pointing to 1 in the atlas, but because it is 11, it is coloring that texture red on the block.  Not sure I explained that as well as I would like... if anyone isn't sure what I'm meaning, feel free to ask.

 

At the very least, if modders were allowed to edit the textures/colors used in the atlas, it would at least allow for people to use their own stuff even if those would apply to everything in the game.

Edited March 25, 2023 by Riamus (see edit history)

[meganoth]

16 hours ago, Riamus said:

Another thought... Are we using numbers (I assume we are) to point to textures?  I know we have more than 10 textures to choose from right now, so we are presumably pointing to a texture with a 2-digit number, allowing for up to 100 choices (00-99) without changing the size space needed to store the info. 

 

No. You are presuming that numbers are stored as texts. But internally and in binary data structures on disk all numbers are usually already stored as binary. Only in xml files would numbers be stored wastefully as texts.

But check out the POIs for example, there is one xml file and two binary files for each POI and texture data is not in the xml. World data is also stored in binary files and because they have to constantly write to them (in the save game) they can't be stored as compressed data (which is way to store text data efficiently but at the cost of computing power for compressing and decompressing).

 

16 hours ago, Riamus said:

Switch to alpha-numeric and you have significantly more space with only the 2 bytes of space. 

 

You get 256 values into a single byte (i.e. 2^8) and 65536 values into 2 bytes of space (2^16).

 

16 hours ago, Riamus said:

 

With that significant number of choices, you can have something like 1-10 being ten textures unpainted, 11-20 being the same ten textures in red, 21-30 being the same ten textures in blue, and so on.  Even with only 100 choices, you could do this if you don't want alpha-numeric!  The atlas would just have unpainted textures, so can have more than we have now by not having multiple versions of many of the textures in different colors (like cement).  What is saved to the block's side is still pointing to the atlas, but it is grabbing the texture and color based on where in the range it's looking.  Basically, the atlas isn't storing colored versions.  The game is setting the color on the block after getting the texture from the atlas.  So in the example I gave, 11 is really pointing to 1 in the atlas, but because it is 11, it is coloring that texture red on the block.  Not sure I explained that as well as I would like... if anyone isn't sure what I'm meaning, feel free to ask.

 

 

 

That scheme you are suggesting here is identical to storing color as a separate number. It needs free bits in the block definition, i.e. the problem I was talking about previously.

 

The question you should be asking is how big (in bytes) the atlasses are that 7D2D is using and how many textures are stored in there right now.

 

Edited March 25, 2023 by meganoth (see edit history)

[zztong]

19 hours ago, meganoth said:

That scheme you are suggesting here is identical to storing color as a separate number. It needs free bits in the block definition, i.e. the problem I was talking about previously.

 

I think he was riffing on a question I asked. I was asking if a 2nd texture atlas was possible?

 

If so, you'd need a way to associate a POI with it's atlas and that could be done in XML, even if wasteful because it would be only a few bytes per POI. In this example, it is smaller than the number of unused XML tags that are still being carried around by POIs.

 

<atlas>2</atlas>

 

Then, the Prefab Editor knows which textures are to use for that POI.

 

We'd need a way for the Game to know which textures to display. And I was asking that since F11 seems to know which POI the player is standing on, would the same logic allow the Game to get a reference to the POI and find the associated atlas code?

 

If that were possible, then it boils down to is that process fast enough to not mess up play.

 

There are a number of trip-up points in there and I'm sure the Devs have looked at this kind of approach. It is similar to memory paging.

 

If it worked, POI designers would have to pick an atlas (~palette) to use with a POI and you'd only get the textures on that atlas to use, so there would likely be a high number of duplicate textures.

 

Update: Indeed, I worry that even if the technicalities were adequately addressed, this approach would be of limited appeal. Perhaps if you wanted all POIs in the Industrial district of a city to use an "industrial" palette, so you end up with the "residential" version of "yellow concrete" versus the "industrial" version of "yellow concrete", versus etc. While it adds new appearances on a large scale, it doesn't add new functionality to the available textures. You might find a few of the textures can become something different... like an industrial palette might not need the "log cabin" texture, making room for one new texture but only if you're on an industrial Tile.

 

So, while this might be technically feasible, it creates all sorts of POI and Tile design complications. I'd skip doing it.

Edited March 26, 2023 by zztong (see edit history)

[theFlu]

4 hours ago, zztong said:

I was asking if a 2nd texture atlas was possible?

With 0 overlap, perhaps. But you'll lose your ability to build in POIs. The atlas is the size of "every bit of memory you're willing to sacrifice for it", so you can't load 2 simultaneously. Loading one, takes out the other. Any texture that can be used in an area, must be in the current one. So you couldn't use "blocks of POI 1" in POI 2, and vice versa.

 

Additionally, everything outside the POI in drawing range would need to be from the same atlas, so you couldn't place POI 1 and POI 2 next to one another. Not even in the same town, as you can't have both sides of the boundary visible at once.

[zztong]

35 minutes ago, theFlu said:

Additionally, everything outside the POI in drawing range would need to be from the same atlas, so you couldn't place POI 1 and POI 2 next to one another. Not even in the same town, as you can't have both sides of the boundary visible at once.

 

Ah, I was afraid that might be a limitation. Even if it switched at city district borders, or biome borders, there's still be times when you'd want multiple atlases. Thanks for thinking it through.

[Riamus]

I am curious, and maybe no one can answer this... does an atlas have to increase size by a certain amount?  In other words, if you wanted to increase the atlas size by one level, does that add one texture or 50 or 100 or ...?  And how much extra memory is needed to increase it by one level?  I'm just thinking that if you could add only 10 or 20 textures without increasing RAM required by a significantly large amount, it could be worth it.  I'm assuming they've already looked at this and determined that what we have is what they think is acceptable for RAM usage, but I'm just wondering what that difference would be if it's known and allowed to be stated.

 

Is it possible for unpainted surfaces (wood, cobble, cement, etc.) need to be included in the available textures?  I have a feeling they do, but is there a way to move those out of there and make room for textures you'd actually use to paint with?

 

And, could we at least see the textures/atlas opened up for modding?  Even if you can't change the number of textures, just being able to make your own could be nice.  I do understand that making such a change would affect the textures on all POI, so you'd either have to disable vanilla POI or else edit them so they look okay.  But I would imagine overhaul mod authors would be open to that as an option so they can make a more appropriate theme for their overhaul mods.

[theFlu]

8 hours ago, Riamus said:

In other words, if you wanted to increase the atlas size by one level

I haven't handled them for reals, so some salt to be taken, but one "level" is basically a new bit of addressing to a two-dimensional array. So if you had 16x16 textures earlier, next "optimal" step is 32x32; quadrupling the memory.

 

And then it all depends on the tool chain, GPUs may have demands, the game engine may have demands etc - I don't even know where the thing is actually handled, but wherever it is, there's going to be plenty of algorithmic optimization going on based on some standard solutions decided somewhere at some point in time ...