Alternative Painting

[4sheetzngeegles]

@Riamus Gave me this idea when I read a post about new paints.
I combined it with Joel's response Paraphrased: There is a limit to textures available for every 1 thing added
something has to be removed.

One thing that was in game prior, and one that is still used, if combined "may possibly allow for more variety"
While simultaneously lowering paint textures, and having the excess be reallocated to another area, like biomes
maybe. Just an errant thought.

The thing that was in game was the full working Light enabler that allowed you to change the color of lights manually.
The thing that is still in the game is the Gradient that is used for the different lighting tones. It is 1 texture that can represent
the full color spectrum, and grayscale simultaneously. Here is the example of which I speak.


My thought regarding this is the small size of the gradient because of the dimensions, approx 50 kilobyte.
@faatal answered a question for me regarding dying the weapons and armor. Again paraphrasing: by using
masks.

I often go to Photoshop pick a color from the pallet and plug it in to xml to change the dye color for my weapons.
If the textured textures meaning woodgrains, metals grains, etc. Were Black and transparent, but would show up as black and
white like what happens with PNG format. Then if a pointer were added to the paint selector, and added to what ever seamless
texture is chosen. It would simply plug in the hex value and render that color. Hypothetically being able to render 16Million color,
plus BW grayscale using minimum texture resources. So say there were 20 plus raw color textures, instead you would use 1to cover
the spectrum. Using variable grade transparency on the default image would allow for grain and depth.

To see the possibility simply log into a demo map, and turn the speed up to 400 to see the light change, same principle, and it would free
up textures that may be useful elsewhere like terrain or biome, or clouds etc. The following is an example used for 24hour sunlight.


15kilobyte.
Alternate thought is that it can be used to vary fog color, or the dust particles.

 

[Riamus]

You are basically talking about tinting versus actual paint textures. This is something that could be done, but it adds another value to track for every side of every block in the game, which would likely increase the size of saves by quite a lot. Just as a very quick example - and this isn't intended to be accurate or include every piece of information....

Let's say you have a block. It has 6 sides. Each side can have a paint. That requires a stored value for each side that is the paint being used. Now, you add a new piece of information to track the tint being used on each side. That just doubled the amount of data needed for that block. Of course, if you are storing more data for each side of the block - say 10 pieces of data and you add 1 more, then it's only a 10% increase. But it's still more data. And if you start counting the number of blocks in the game, that quickly becomes a LOT of extra data. Your world sizes would be much larger and your saves would also be larger for every new block or changed block (saves are changes that are made to the original world). Considering consoles are already extremely limited on the number of saves they can have, I doubt they'd want to increase sizes and perhaps limit them to only 1 world/save.

Better would be to just fill in the paints that were removed with new ones and then perhaps consider adding a new set of paints that could be optional as a game option and only available on PC if it won't work on console. They could be used only in game and not in POI so there's no issue with POI not showing paints properly if it's disabled or the POI is used in a console game, or they could make those paints "fallback" to the original series of paints so if it's disabled or unavailable, it would show one of the original series of paints instead. For example, if you had 20 paints in the original set of paints (I don't know how many there actually are) and they added a new set of 20, value 0-19 would be the original and 20-39 would be the new ones. If paint 20 is used and the extra paints are disabled or unavailable, it would automatically revert (fallback) to 0. 21 would be 1, and so on. Of course, to do that and not make things look really weird, they'd need to make the new ones be at least somewhat similar to the originals. So you might have a blue cement paint from the original paints in position 0 and then the paint that is in position 20 (that would fallback to 0 if not available) could be another kind of blue cement paint... perhaps a nice looking one instead of the old and faded one. Then it at least doesn't break the look of the POI if the second set of paints aren't available or are disabled.

Not sure how feasible that would be or if there are better options, but the goal would be to avoid adding additional data to track.

There could be another option as well... instead of a new set of paints, the use of a value in the next "set" of numbers could instead indicate a tint. So, for example, paint 0 could be a blue cement paint and then paint 20 (the first paint in the next set) could be the same paint texture but in red, then paint 40 (the first paint in the third set) could be the same paint texture in green, and so on. That would keep you with the same amount of saved data while still allowing tinting.

 

[4sheetzngeegles]

The top part of your post is way more than what I was talking
about. It looks like replacing actual textures in the texture2darray.

The bottom is much closer to what I meant.

All I was talking about is using the gradient as a pointer guide.
Instead of having black,white,yellow, red, blue,green,purple swatches etc.
Just one 24k image to represent the entire color spectrum.

Then have the program add the hexadecimal color representation or
value for the paint to be applied to the block or block face being tinted,
but as an overlay. Like a semi-opaque layer in Photoshop, or the texture layers
in the images they use now.

The reason for overlay is because the regular blocks and their textures
stay the same, be they whole blocks or partial.

You don't paint a block before it's placed, so it is already a part of
the data cube or voxel being monitored the only thing being added is a hexadecimal
for the custom tinted overlay for that cube.

Your point about added data size, in the save file, was valid so I found a converter
and used a calculator.

A hexadecimal uses 4 bits.
So each block if fully painted adds 3 bytes or 24 bits of data storage.
1333 blocks all six faces painted = 1 kilobyte.
1,365,333 blocks all six faces painted = 1 megabyte. That's a lot of painting

So I took it to an extreme to see viability.
Painting every block in a solid cube dimensions L 30M x W 70M x H 300M would be
512k extra save data, that's 630,000 blocks fully painted from game base to 45 blocks
passed the default 255 world height.

Adding 10 megabyte additional save data thinking about a multiplayer server would be
12,600,000 blocks manually and fully painted on six sides.

Those are 3 actual game textures, to show what it could look like. I didn't
de-saturate the textures I just did a once over with overlay. It allows the original
texture to show through.

If the detailed textures in the paint scheme were de-saturated the effect would be more
brilliant.



Secondary application
For standard tints that are represented by the bottle Icon or mod. It would simply edit the file
property by program instead of manually. But only the bottle you are using at that time.
I just thought if I do it manually, the expanded choice mechanically would do it way better,
since its just changing the hexadecimal value. and only using one source file.

All things owned by a player are indexed, that is how they got items and gear to return to the
same basic position.

Select bottle, sub menu opens like when cooking at a fire, you see the gradient, put your
pointer over the color you like hit ok it sets it in the temporary paint file. When you
exit it returns to the neutral color. But the voxel data cube has recorded the hex value the
same as present painting but using a broader color pallet.

 

[theFlu]

1,365,333 blocks all six faces painted = 1 megabyte. That's a lot of painting

The zeros for non-painted blocks take as much space as the numbers for the values. IF they were to add a tinting option, they'd probably want to use it for their own designs, so it can't be "just in modified save data", it's every block that can be tinted. I don't know if terrain saved different to paintable blocks, or if it can be, but .. it's a lot of data

 

[Adam the Waster]

The top part of your post is way more than what I was talking
about. It looks like replacing actual textures in the texture2darray.

The bottom is much closer to what I meant.

All I was talking about is using the gradient as a pointer guide.
Instead of having black,white,yellow, red, blue,green,purple swatches etc.
Just one 24k image to represent the entire color spectrum.

Then have the program add the hexadecimal color representation or
value for the paint to be applied to the block or block face being tinted,
but as an overlay. Like a semi-opaque layer in Photoshop, or the texture layers
in the images they use now.

The reason for overlay is because the regular blocks and their textures
stay the same, be they whole blocks or partial.

You don't paint a block before it's placed, so it is already a part of
the data cube or voxel being monitored the only thing being added is a hexadecimal
for the custom tinted overlay for that cube.

Your point about added data size, in the save file, was valid so I found a converter
and used a calculator.

A hexadecimal uses 4 bits.
So each block if fully painted adds 3 bytes or 24 bits of data storage.
1333 blocks all six faces painted = 1 kilobyte.
1,365,333 blocks all six faces painted = 1 megabyte. That's a lot of painting

So I took it to an extreme to see viability.
Painting every block in a solid cube dimensions L 30M x W 70M x H 300M would be
512k extra save data, that's 630,000 blocks fully painted from game base to 45 blocks
passed the default 255 world height.

Adding 10 megabyte additional save data thinking about a multiplayer server would be
12,600,000 blocks manually and fully painted on six sides.

Those are 3 actual game textures, to show what it could look like. I didn't
de-saturate the textures I just did a once over with overlay. It allows the original
texture to show through.

If the detailed textures in the paint scheme were de-saturated the effect would be more
brilliant.

View attachment 36754

Secondary application
For standard tints that are represented by the bottle Icon or mod. It would simply edit the file
property by program instead of manually. But only the bottle you are using at that time.
I just thought if I do it manually, the expanded choice mechanically would do it way better,
since its just changing the hexadecimal value. and only using one source file.

All things owned by a player are indexed, that is how they got items and gear to return to the
same basic position.

Select bottle, sub menu opens like when cooking at a fire, you see the gradient, put your
pointer over the color you like hit ok it sets it in the temporary paint file. When you
exit it returns to the neutral color. But the voxel data cube has recorded the hex value the
same as present painting but using a broader color pallet.

I was going to post something like this i love it

 

[4sheetzngeegles]

The block count I posted did not mean to include terrain, it was an example of
how much data a solid building with a hex value on all six sides would add.

I was hoping that if they could use this formatting, that all players including
console and multiplayer servers could use it. and not over bloat, because I
agree with what Riamus posted. I falls in line with Joel's post and posts from
Faatal.

Textture2darray terrain blocks as well as poi blocks, would remain untouched,
but a single property line that works like the loot placeholders would be there
but invisible like the air blocks are. And only changed after a block is placed.

So in a sense the player would be doing a tinting overlay, just by changing that
null hex, to a colored hex in the voxel space.

I did write that it was a screwball idea. But I was trying to think of something that
fit within the guidelines, to keep efficiency, benefit everyone, and if it were possible
to do, additional paint color request would be a thing of the past. Plus with masks
armaments could be as individual as the person that tints them. Like body art tattoos,
graffiti that actually follows the texture deformations.

I just thought that 512k or 630,000 blocks should cover more than enough for anyone
that decides to paint a base. Numerically an data size it would allow any user to
paint an average of more than 20 bases for 512k. Considering most bases are less than
30 meters tall, and not solid. I hope it is viable, or gives someone more skilled at
programming an idea.

 

[murky water]

so i destroy a LOT of blocks in my regular playthroughs and i can tell you right now there are so much more than 630k blocks in any given town you walk through even disregarding terrain tiles. it would eat into the game so bad to add a kb to each one and it would waste so much space to have non-player blocks be duplicated to have an unpaintable variant to counter the +1kb per block.