Doing textures right

Modding
1

Hello!

I saw another post on here about adding the ability to edit textures. (This isn’t exaaaactly what this is about. It’s more about a suggestion on how to do it right, as I was very dissatisfied with the approach that was suggested in that post):

I know the devs have already said that they are going to finish the core game first, and make sure that the textures they made are done, feel great and most users wouldn’t want to change them, which I completely agree with! Great job devs!

First off, I don’t know exactly how your textures are done right now, but having messed with some voxel engines in the past, I’m assuming your using a texturemap or something of the like, to reduce drawcalls.

I would never suggest going away from that system. But there’s a problem with that, in regards to custom texture packs. It’s very limited. E.g. if you have 256 available spaces for textures. You’re limited to 256 custom textures. This might be enough to texture every single thing in the game. But if you want e.g several different rock types, more tree types, or more importantly create connected textures. This becomes a huge issue.

This is luckily easily fixed but splitting this texturemap into individual images. And then “baking” those images back into a texturemap. At this point, the game would allow for an unlimited amount of textures, and a lot more oppertunities opens up for creating amazing art for the game.

But a lot more can be done. Say for example Oort has 1 transparent block that you can walk through. That could be cobweb for instance. Now all your competitors does the same thing and it’s quite frustrating. They hardcode the name of this block into their game. So if someone wanted to create a texturepack, they would only have that 1 block available as a transparent block you could walk through. The artist might have a bunch of great ideas to add to the game, e.g. a basket, icicles, spears, flies, rope, hanging meat, hanging clothes etc. etc.

All those things would require a transparent background. But if only one spot for that is available, it greatly limits creativity.

So here is probably the biggest suggestion in the thread. Please, please, please don’t make this hardcoded.
Make a default folder setup and just iterate through all the images in this folder. And instead of looking for specific names, find each image, get their name. This allows us to have an unlimited amount of creativity, without the frustration of trying to find e.g. Cobweb:19 when you’re looking for icicles. Instead you can just place “icicles”.

This however poses a problem, that has a great solution.

How will the game know what type of block an icicle is?

Alright, so bear with me. Each image has a name of course. e.g. icicle.png.
Each texture should be accompanied by a setup file. Could be icicle.oort or icicle.txt or whatever makes it easiest for you.

This file would contain relevant information about the block.

It could look something like this:

core-block: false (If it’s a core block in the game (one that’s procedurally generated e.g. grass)
textures: icicle.png (the texture accompanied by this file)
transparant: true (this is needed for the engine to know, wether to render blocks next to it)
liquid: false (doesn’t act like water)
gravity: false (doesn’t fall down)
light: 0 (produces no light)
soft: 0 (reduces fall damage)
wrap: cross (goes from corner to corner, instead of wrapping around the block)
model: block (Choose model type, possibly faaar in the future allow custom 3d models)

This will give artists an unlimited amount of creativity, to create some truly amazing worlds. I spent about half an hour on this concept, so it’s not exactly perfected. But I hope you will allow in some way, shape or form, artists to change Oort into a truly personalized experience. And not just limit us to what textures and blocks the devs create. (While they are doing an amazing job, it’s impossible to code & create at the speed of an entire community)

Thanks for reading the wall of text, and I hope you will consider taking a more unconventional approach to allow for the most customisable experience in any voxel game today.

2 Likes
3

If the Devs feel like they need more textures I am sure they will add them.

4

This is about making it possible for the community to (at some point in the future) to create their own textures. Not the devs. Of course the devs will continue to expand their game with new blocks and textures.

1 Like
5

@claudiotolomei is the guy you want to talk to about this. He’s the guy responsible for our modeling and textures, if I recall correctly.

2 Likes
6

actually, I managed to find this post discussing how the textures are handled. Good reading!
https://forum.oortonline.com/t/announcing-102-really-beautiful-voxels-coming-soon/973

1 Like
7

I just discovered this game about 8 hours ago. And so far It’s doing so many things right. Where their competitors (other voxel games) have gone wrong (imo). And I really really want this game to provide an amazing personalized experience.

Thanks for the link.

2 Likes
8

There’s always a trade-off in large scale design between practicality and freedom, it’d be great if you could have endless numbers of block types completely customisable in any way… unfortunately that just isn’t practical (the disk space requirements for any encoding of such a world and performance requirements because of having such a slack description would be too great).

The same thing applies to having endless numbers of textures for given blocks. In Oort we already have many blocks that have more than a single texture (stone has 5), on-top of which there is not a single texture, but a colour map, a normal map, a specular map, an emissive map, but ultimately we’re limited by hardware (forgetting art resources) to how many textures the game can reasonably use before performance would be too bad even on the latest gpu’s.

That’s not to say we’re at that limit, but I don’t feel Oort really needs to have as many block ‘types’ as other voxel games do, because we also have the block colouring which means for a single stone block type there are hundreds of different colours of that stone block that can all be mixed together in a single world.

5 Likes
9

Thanks for the quick reply! And a good one.

I wasn’t aware of the hardware difficulties with doing this. So thank you so much for actually explaining why it’s not easily done, rather than just saying no or nothing at all!

But is there a chance you could elaborate a bit more. I’m really interested in this. About a year ago I attempted creating a voxel game myself, that incorporated this method. (The game was in really really early stages and didn’t use 4k textures or anything. Which probably makes the world of difference). But when you say it’ll be a performance issue, is that after about 50 extra blocks, or are you thinking thousands? Cause I don’t think anyone would make a texture pack with thousands of blocks. It would naturally stop when performance would become an issue.

Either way. Thank you so much for your reply!

In case the above just isn’t feasible for this project, is there any chance you would be allowing artists to change textures in biomes instead? So e.g. grass in a normal forest biome would look normal. But if someone ones they are available, has a personal server and wants to create a custom experience with drastically different biomes than the core game provides. Would we be able to change grass in e.g. a dessert biome to look completely different?

One quick question in regards to the same though. If complete freedom in textures won’t be possible, is there any chance that it would be considered to allow blocks to assume different textures in different biomes? (I get that we need to update all the maps for the texture as well, but there are plenty of people able to do this at a professional level)

Would that be a possibility instead? Since that shouldn’t cause an issue with someone trying to make a texture pack with too many new blocks. But it would still allow for some degree of customisability for the community.

As for Oort needing a ton of more blocks, I completely agree. It probably doesn’t. It’s nice that the colours can be changed. However the customisability that I’m hoping for, would be a lot more for themed things. E.g. If some one wants to do a futuristic server, steampunk world, a world after a nuclear war etc. etc. A lot of these themed worlds or servers would never has fitting blocks by default cause they are “niche” servers. But having the ability to customise the experience - at least for me, is what makes or breaks a game like this.

Either way, really appreciate the reply from an actual developer! Great job, keep it up.

10

We havn’t really got a concensus on this that i’m aware of, but in my opinion we would do that in one of two ways.

  1. Using different block types for totally different grass types that aren’t just a colour change.
  2. Allowing different textures for different ‘colours’ (we have 255 colours available, we could instead of having more block types of grass, assign different textures to colours 0-100 than 100-200 etc).

But my personal preference would be for 1) as it’s cleaner and clearer.

Regarding performance, we are using 256x256 texture sizes for blocks (a LOT bigger than say minecraft default) and with the range of hardware we want to support that limits us to around 256 textures I believe from memory before we have to start splitting up the meshes further (though that’s already a lot of memory). If say, on average blocks have 3 textures each, that is around 80 unique block types (this doesn’t include things like torches that aren’t physical blocks etc and props like chests).

As for having string named blocks (so that anyone can add any block they want etc), having a unique block id (< 256) is not a utility thing, but a performance/memory constraint as the data store for a chunk of the world is massively smaller, and all the runtime lookups of block -> data definition are much faster, especcialy for say, turning the data into rendering meshes at runtime.

2 Likes
11

ahh I see.

Yeah the engine where I tried it out on, the textures were only 32x32, with no extra maps.

Thank you so much for the reply!

Keep up the great work. :slight_smile: