Using a sprite map for terrain splatting

Troubleshooting terramonkey
1

Hello. I tried the terramonkey extension and it works great. But the limitations in how many different terrain textures I can use worries me. I did a little research and came across this post here: opengl - Texture splatting more than 5 textures - Stack Overflow

The idea is to use the RGBA alpha map to encode 2D coordinates in the color and have a sprite texture with different terrain textures lookup according to the color coordinates.

If I have a 2k sprite map and 128 x 128 terrain textures then I can have 16 * 16 =2 56 different terrain textures. Or if I increase the size of the terrain textures to 256 x 256 then I can have 8 * 8 = 64 different terrain textures.

Some questions:

  • is that already implemented somewhere for JME3? If somebody has this already then there is no need for me to reinvent the wheel.
  • is that even possible? I don’t know about the limitations of graphics.
  • why isn’t it implemented already somewhere? It sounds way better than to have the current limitations of terramonkey of 16 textures. And with maximum of 11 diffuse textures for just 11 different terrain types.
  • can I enhance terramonkey for that? Is it enough to have a new material definition with the shaders?

Thank you.

2

im not sure about your idea.

trully IMO what you need i belive is TextureArray. the only problem with it is that it require same size and same format textures.

i suggest you look at shader i made based on Riccardo Parallax occlusion mapping

it base on TextureArray that can have much more textures stored.

it used normalmaps,albedomap,parallaxmap. it can be extended to support more textures easly, just need add more params like “uniform float m_Parallax_11;” and more #ifdef SLOT_11 and additional alphamap for more.

3

Thank you for your reply. I will look into it. Currently, I’m experimenting with multiple TerrainQuad that I stack on top of each other with alpha blend so that I can have more than 11 different terrain types.

But why doesn’t nobody done the idea from above? Nobody needs more than 11 different terrain types ever?

4

I thought I would eventually want more than 11 textures in the past, but the more i worked on designing my levels, the more i realized that too many textures on a single terrain starts to look sloppy - it becomes more difficult to stick to a single color pallete/theme for a specific environment.

In some of my large maps, I use many more than 11 textures - but not every terrain needs every texture, and the textures slowly change accross the map as the environment changes - for example, the textures I use for the Terrains on one side of the map in a coastal environment will mostly differ from the textures I use for the Terrains on the other side of the map where the environment changes to a high altitude mountainous region.

5

With every texture comes a performance hit. This is alleviated by using texture arrays, hence the information above. A texture array is just one big texture.

Alternatively you can use a texture atlas or a voxel style setup.

6

well, in JME you can do whatever you want. its very elastic. but it require knowledge, right.

The fact i used TextureArray was exactly that problem that i were unable to have a lot of textures(not just phong, but parallax / normal too).

So trully i done it. i have like 11 * 3 = 33 textures out there.

this 11 can be extended easly too. So you can just copy paste code i shared and add there more textures.

7

Thank you, I think TextureArray is the way to go. What I’m trying to do is a big map with lots of features and different terrain types per patch. Each terrain type is a different resource to use, and there is also different kind of grass, bushes, flowers, etc. A map is for example 64x64 patches. TerraMonkey is perfect for that, except for the limitation of 11 textures.

Currently I have zero knowledge. My background is C/C++ and Java programming, and little bit of Python for server management. I haven’t done anything in 3D programming.

I’m really preferring to use already created solutions and not programming something new. Simple because 3D programming is really old and there ought to be solutions for everything now. That’s why I love open source: I like to plug libraries together like lego bricks and create something bigger.

If there isn’t anything prepackaged in JME3 for a terrain that is using TextureArray I think I will implement it. I can bring it back to JME3 as an addition.

8

everything is up to what advenced game you want to do.

Its always easier to use ready solutions like TerraMonkey. But if you plan create big big game, you would always need do a lot of things yourself. Or extend existing solutions.

for example myself i have own Editor, because none of existing will support own ECS/grass/etc solutions.

If you start your journey with JME, most important is you to learn SceneGraph idea, how filter works, ECS(entity-component-system, there is Zay-ES to use), PBR material (because its modern material usage, metallic,etc), Blender 2.8 gltf export (also because its modern solution) - where in Blender 2.8 you can very easly create PBR material.

You also need to know(if you want create PBR or other good materials) what is:

  • albedo map - color map
  • height map - used in some shaders - like name say its black to white based on height
  • normalmap - its rgb map with calculated light directions (to simulate texture based shapes/holes/etc)
  • parallaxmap - more advanced than normalmap, it move pixels to make better effect.
  • glowmap - like name say, where light glow
  • metallicmap - where material is metallic (where it reflect environment)
  • roughenss map (where metallic color is “blurred”)
    and many more of other maps used in shaders.

For blender 2.8 here is one (outdated but show how it is easy) to create PBE material there:

you just paint it. cant be easier :slight_smile:

ECS is really important. For example you say about Bushes, but will player be able to collect for example “food” from this bushes? Here best solution come ECS, and this bush then should be as ECS entity, instead of just “grass part”.

Ofc easiest way to learn is to look at some good ready solutions. So you could search some better written open-source games in JME to see.

Everyone were learning once, so also feel free to ask question here on forum and also on Discord (i hope you are there) :slight_smile:

edit:

Also i think a lot of new members use Ant build using SDK, while everyone suggest using Gradle with ANY IDE. While for example you need to know jme-bullet package is wrapper while jme-jbullet(written in Java) or jme-native-bullet(Written in C) you need to choose one (native seems better because supported) or about jme-lwjgl and jme-lwjgl3, also use only one of this packages/libs.

In short, you choose what packages/libs you want to use in your game.

Some of this libs might be written in C so then they generate “lib” for platform where game start(if need). it is for example for lwjgl, where you start your game it create for user new lib depending on platform he use. So in fact JME is 50% C and 50% Java.