Connected Textures & Meta Data

[Azurite]

So, I'm not sure if this has been suggested before, but I just thought about it.

I'm working on a texture pack and one of the main issues to work around is basically "making tiled things look less noticeable or at least tolerable".

Then I remembered a few things. A lot of scifi ships have the mismatched welded look. And minecraft has "connected texture" capability (basically multiple added textures for a single block, under the hood, that replace the one single texture).

Mash the two ideas together and that has the potential to relieve the tiled look for a better, random style hull pattern.

Think of each one of these textures as the same type of block, but different meta data. Disable the feature and each one of these new textures returns back to the default hull texture. Simple.

Ships would look way cooler and it could open up possibility for multiple decorative blocks without mods, more terrain detail, randomized hull damage textures, you name it. Endless possibilities for us texture artists to make more cool stuff without the headache.

Anyone agree? Disagree? Thoughts?

 

[therimmer96]

I agree, although this could create even more data to be sent over the network, and therefore more lag. Perhaps if this was handled exclusively by the client, that may reduce server lag caused by this

 

[Azurite]

I'd say leave the actual textures to the packs but still build the ground work in the game files for the potential of block meta data.

To cut down more, maybe only have the hulls and terrain have the feature, instead of every block. And maybe give each block a maximum of 5 different meta textures to cycle through.

Short and sweet.

Come to think of it, this sort of thing could also call for a new file structure to have block textures, GUI, sounds, etc, all within one master "resource pack" folder of sorts.

Because As of now, any other reskin other than blocks is considered a mod and not a texture pack.

 

[NeonSturm]

We don't need that much meta-data.

Just let every block with even x and even y have texture 1, odd x, even y have texture 2, even x, odd y texture 3, odd x, odd y texture 4...

If that would be an overlay, hull elements could have an underlying individual texture and a shared overlay (darkening/lightening of parts) to keep the texture packs at reasonable sizes.
Just like bump-mapping?

 

[Sven_The_Slayer]

We don't need that much meta-data.

Just let every block with even x and even y have texture 1, odd x, even y have texture 2, even x, odd y texture 3, odd x, odd y texture 4...

If that would be an overlay, hull elements could have an underlying individual texture and a shared overlay (darkening/lightening of parts) to keep the texture packs at reasonable sizes.
Just like bump-mapping?

The problem with that idea is now hull textures will just repeat over 4 blocks instead of one.

 

[NeonSturm]

The problem with that idea is now hull textures will just repeat over 4 blocks instead of one.

That was an example...

You could let hull repeat each 4*4, (8 colors * 2 textures * 16 bump-map overlays, jet only 26 used texture tiles).
But let wood or grass repeat only over 2*2 tiles.


I think the problem is more that blocks have to be 1 metre high, instead of 1/2 or 1/3 metre for more details with joined 4x4x4 mega blocks for less ram-consumption.
This game lacks three things:

1. Details below 1-metre blocks.
2. The ability to use tools like in better 2D image editor programs (Gimp has a paths-tool, just implement it for 3D auto-generated bridges and we would have much more awesome content).
3. Performance - Generate a 2D high-map terrain with space below blocks = impassible before loading stuff below for example.

I hope at least two points mentioned above can be changed.

 

[ltmauve]

Well, if you were referencing your textures off of a larger image it would have to at least be large enough so that you couldn't see it start patterning again clearly. I'm not sure how large this would be, given sizes of screens and the apparent size of a block at different angles and distances, but such a texture would probably wind up being pretty large.

 

[Azurite]

I think I explained it oddly. Basically, minecraft does it this way:

You have your default textures for each block on one png image in the default game files. Then you have separate folders for each block (one for "grass", "stone", etc) with single 32x32 png images in it for each new "meta texture". In the game, when connected textures is turned on, the whole block's texture is replaced with the textures in these folders. It cycles between the textures in the corresponding folder as well as the default texture on the master texture png.

This works so that when you place blocks, a different texture (between 1-5, we will say) shows up, varying the look of it. That's what my image showed. 1 of those blocks would be the default and the others would be the extras in the corresponding "hull" folder with separate 64x64 png images in it.

Hope this makes sense lol

 

[NeonSturm]

Well, if you were referencing your textures off of a larger image it would have to at least be large enough so that you couldn't see it start patterning again clearly. I'm not sure how large this would be, given sizes of screens and the apparent size of a block at different angles and distances, but such a texture would probably wind up being pretty large.

Except you have:

• 8x Colour
• 4x texture
• 4x relief overlay

All merged together, make 4*4 = 16 different block styles.

I don't know how Space Engineers did it, but having a fast algorithm to calculate the sunken or raised parts of a texture and draw them may be less memory-consuming.
Thinks like darkening/lightening may even be 4-bit grey-scale textures (16 colors) instead of full 32-bit and thus save 7/8 memory.


But the biggest problem will be to make blocks not have sunken/raised lines unconnected to neighbours and blocky looking or consuming too much cpu/mem.