Understanding land texturing.

[animats]

Ref: https://wiki.secondlife.com/wiki/Creating_Terrain_Textures

Questions: 

Wiki: "Texture Elevation Ranges -- Texture elevation range values can be adjusted for each corner of the simulator and are labeled accordingly. The low and high values in each corner affect detail and base textures alike."

What are "base textures" and "detailed textures"? Is that an unimplemented feature? The rest of the documentation, and the texture edit window, only mentions one texture per elevation. Terrain textures just seem to be 21 repeats of the detailed texture per region. The wiki text reads as if terrain textures were composed of two layers at different scales, which would be nice because you could have large terrain details that didn't repeat plus fine detail for blades of grass and gravel that did repeat.

(Internally, in the UDP messages, there are slots for "base" and "detail" textures, and "base" does get filled in with some kind of UUID info. But as far as I can tell, those "base" UUIDs are not used in the viewer.)

[ChinRey]

4 hours ago, animats said:

Terrain textures just seem to be 21 repeats of the detailed texture per region.

The default for Firestorm is 21 1/3 - one repeat per 12 m but it can be adjusted to anything from 1 to 24 m/repeat:

I'm not sure but if I remember right, the LL viewer uses one repeat per 8 m and I don't think it can be changed.

 

4 hours ago, animats said:

(Internally, in the UDP messages, there are slots for "base" and "detail" textures, and "base" does get filled in with some kind of UUID info. But as far as I can tell, those "base" UUIDs are not used in the viewer.)

Look at the ground texture sets in the library folder. There are two versions of each texture there - a regular with 512x512 and a "Base" with 128x128 resolution. I suppose that's the explanation: the "base" textures were simply lowerresolution alternatives, probably for clients that couldn't handle 512s.

 

[ChinRey]

As you know, Animats, I've been working on and off on my own documentation of SL/opensim and some futile thoughts on how they can be improved. Here's what I've got about the current ground texture system. Corrections and other comments are very welcome:

The ground texture is a blend of four tiled (one repeat per 12 m) textures. The blending uses masks made from a preset perlin noise pattern and gradients between the four region corners.

The maximum elevation texture 1 is applied to and the minimum elevation for texture 4 can be set independently for each corner of the region. Those numbers are way off though; texture 1 extends considerably higher and texture 4 considerably lower.

To illustrate how bad this is: with max elevation for texture 1 set to 10 m and minimum elevation for texture 4 to 200 m, texture 1 is the dominating one up to c. 30 m and occurs up to c. 60 m while texture 4 is the dominating one down to c. 130 m and occurs down to c. 115 m.

The perlin noise mask is shared across the entire grid allowing for seamless texturing across region borders if, and only if, adjacent region corners are set to the same texture blend heights and adjacent regions share the same texture set.

Compared to SL, opensim uses a different - and less satisfactory perlin noise mask.

[ChinRey]

And just for the H*** of it, here are my thoughts on how it could be improved. I really need to improve this article too. There are a few points I forgot to include.

Second Life's and Opensim's current texture map is brilliant in its simplicity but it dates back to 2002 and is not really up to today's standards.

We have to be careful considering the various upgrades since some will increase the client side load significantly, others add several new parameters to edit. However, they will also provide a huge visual improvement and reduce the necessity for ground covering objects so they should all be well worth it.

• Precise elevation parameters
• Number of textures
• Perlin noise pattern
• Border blending
• Texture repeats and texel density
• Decals
• Synchronized corners

---

Precise elevation parameters

The elevations for the various textures are currently set with only eight user defined parameters, max. height for the lowest texture and min. height for the highest texture for each of the four region corners. This makes it very hard to control the blend. In particular it's impossible to keep a seabed texture to bleed onto the land and a land texture to bleed onto the seabed. To make matters worse, the specified values aren't even real, the highest texture extends way below it's min. height and the lowest way above its max. height.

Introducing user defined and precise min. and max heights for every texture will make the UI more complicated but it doesn't add to the lag and should be well worth it. It may however be a good idea to keep and alternative simple UI similar to the existing one.

 

---

Number of textures

This is currently fixed to four which is a bit too much for some regions and not enough for others. This is especially a problem with coastal regions since you really want at least one texture for the seabed and one for the shoreline/tidal zone which leaves you with only one or two textures for the land.

The solution is to increase the max. number of textures to at least six but also, to reduce the lag for regions that need simpler texturing, make it possible to disable unneeded texture layers.

 

---

Perlin noise pattern

The perlin noise patter used by opensim is not ideal and can sometimes create annoying artifacts. Second Life does this better and it may be a good idea to look at which parameters it uses.
However, maybe it's an even better idea to allow parameters to be user configurable. The three most relevant ones are:

• Roughness
• Scale
• Seed

It may also be a good idea to add x and y offset.

Perlin noise blending is not always desirable so there should be an option to switch it off.

One downside to making the perlin pattern user configurable is that it causes problems along region borders so this is only really a good idea if the border blending function is also implemented.

 

---

Border blending

Currently textures blend seamlessly across region borders if, and only if the two regions use the same textures and matching values for the elevation parameters at both their shared corners. The obvious solution is to add blend zones along the borders where the textures from the neighbor regions are added an gradually faded out. The width of the blending zones can of course be set by the region owner, separately for each side, and the blending zones are deactivated where they aren't needed.

It will take a bit of work to figure out exactly how to do it, especially how to handle region corners and borders where both sides are set up with a blending zone, and it will make the baking of the ground texture more complicated and time consuming for the client software but it would be such a huge improvement it is well worth considering. For larger continents it's almost mandatory.

 

---

Texture repeats and texel density

The original SL setup developed back in 2002 seem to have been based on 128x128 ground textures with 1/8 repeats/m, giving a texel density of 16 pixels/m. Current ground textures tend to be 512x512 (64 pixels/m) or even 1024x1024 (128 pixels/m).

Today Firestorm at least uses a different repeat rate with 1/12 repeats/m which means there won't be a whole number of texture repeats across a region. With that repeat rate texel density is 42 2/3 pixel/m for a 512x512 texture and 85 1/3 for a 1024x1024.

All those current texel densities are actually a bit too high for most purposes since too high resolution for a texture repeated as much as the ground needs tends to induce too many artifacts. Even the original 16 pixels/m is actually higher than what many modern games use and it's very rare for the ground to need more than 32 pixels/m.

Most of the time we want to increase the texture resolution to reduce the repeat rate, not to increase the texel density. Not always though.

Adjustable repeat rates (set separately for each ground texture) would be a great improvement. The options should probably be kept to values that give a whole number of repeats across the region (1/4, 1/8, 1/16 and 1/32) but we may need to include opensim's existing 1/12 for legacy reasons.

This should not increase the lag significantly since people these days tend to (ab)use high resolution textures for the ground anyway. Allowing for adjustable texture repeats will only encourage region builders to use those textures more effectively.

Even so and independent of this, it may be a good idea to add a client side option to substitute lower resolution textures when performance is a critical issue.

 

---

Decals

You want a sandy beach? Or a mountain top with a different texture than the surrounding landscape? Or a bright green lawn around your house?

Today such features are done with mesh, sculpt or prim ground. Texture decals would be a much better solution since they would reduce the need for extra objects and are easier to blend into the surroundings.

The blending can either be done with blend zones (allowing for tiled and larger decal textures) or with alpha decal textures (allowing for irregular shapes). Ideally we want both options available.

 

---

Synchronized corners

Matching the elevation parameters at region corners can be rather cumbersome so a function to do this semi-automatically would be really useful.

The idea of the synchronize corner function is to give the region owner the option to select either of the (up to) four existing data sets for a corner, the average of them or enter new data to be applied to all four regions where they meet.

[animats]

On 9/9/2022 at 2:11 AM, ChinRey said:

Those numbers are way off though; texture 1 extends considerably higher and texture 4 considerably lower.

Yeah. Just discovered that.

Visit beautiful Calleta.

This is from Firestorm. The ground surface is at Z=20.88. Note the thin rectangular object I placed on the ground as an elevation reference. That's above "High" texture level for all 4 corners. So it should be showing Texture 4, grass. But instead, it's showing Texture 1, ocean bottom.

In my own viewer, I'm following the spec, and I get grass there. Which is probably what was intended by whomever laid out this region. But over in Babbage Palisade, I get cobblestones in what's supposed to be a big field of open grass. So following the documentation may not be sufficient. Any advice on exactly what "adjustments" need to be made to be bug-compatible?

On a somewhat related note, some very old regions, such as Natoma, have all zeros for the texture UUIDs. There are built-in textures used as defaults. Dirt, grass, rock, and ice. But I haven't found their UUIDs in the viewer yet.

(Terrain really should be switched over to procedural texture shaders, programmed to generate endless non-repeated textures. Apparently that's already being done for water, from some comments at Creator User Group. If we had procedural dirt, grass, rock, and ice, vacant land would look much better. Custom textures are usually used for smaller areas, or for something such as cobblestones or concrete, for which repeats are tolerable. So a few built-in procedural textures would be enough.)

 

[ChinRey]

1 hour ago, animats said:

There are built-in textures used as defaults. Dirt, grass, rock, and ice. But I haven't found their UUIDs in the viewer yet.

• Dirt: 0bc58228-74a0-7e83-89bc-5c23464bcec5
• Grass: 63338ede-0037-c4fd-855b-015d77112fc8
• Rock: 53a2f406-4895-1d13-d541-d2e3b86bc19c
• Mountain (not Ice!): 303cd381-8560-7579-23f1-f0a880799740

Base textures should be (I'm only 99% sure about this):

• Dirt: b8d3965a-ad78-bf43-699b-bff8eca6c975
• Grass: abb783e6-3e93-26c0-248a-247666855da3
• Rock: beb169c7-11ea-fff2-efe5-0f24dc881df2
• Mountain: 179cdabd-398a-9b6b-1391-4dc333ba321f

These are the same textures as the Default Set ones in the library but different, presumably older, uploads so different UUIDs.

 

2 hours ago, animats said:

Terrain really should be switched over to procedural texture shaders, programmed to generate endless non-repeated textures.

Yes, that would be great but would it work with custom texture sets?

Maybe I shouldn't do this but...

It wouldn't be fair to compare SL's terrain functions with modern terrain generators of course so I won't. But here's a quick-and-dirty island I made with L3DT, a program as old as Second Life.

[ChinRey]

5 hours ago, animats said:

Visit beautiful Calleta.

This is from Firestorm. The ground surface is at Z=20.88. Note the thin rectangular object I placed on the ground as an elevation reference. That's above "High" texture level for all 4 corners. So it should be showing Texture 4, grass. But instead, it's showing Texture 1, ocean bottom.

It's even worse than you think since the texture blending is not consistent. Here's how the same scene looks with my copy of Firestorm:

As you see, it's Texture 2 that dominates here. I haven't made any changes to the settings that would affect the ground texture blend and I take it for granted that you haven't either so exactly the same software gives different results on different computers.

Switching to Singularity I get something in between, a relatively equal blend of Texture 1 and 2.

So, even if a sim designer/owner somehow manages to come up with a texture blend setting that looks OKish in their viewer, they still have no idea how others will see it.

 

5 hours ago, animats said:

In my own viewer, I'm following the spec, and I get grass there. Which is probably what was intended by whomever laid out this region. But over in Babbage Palisade, I get cobblestones in what's supposed to be a big field of open grass. So following the documentation may not be sufficient. Any advice on exactly what "adjustments" need to be made to be bug-compatible?

Ummm, this is a long shot but maybe file a JIRA and see if LL are willing and able to fix the bug? There's hardly any chance they'll bother but what else can you do? It's possible to adapt to a known bug of course but only if it's consistent. When the bug produces an arbitrary result all bets are off.

I think it could be useful to hear how other TPV developers del with this mess so I'm paging @Beq Janus and @Coffee Pancake.

Edited October 13, 2022 by ChinRey

[Beq Janus]

1 hour ago, ChinRey said:

I think it could be useful to hear how other TPV developers del with this mess so I'm paging @Beq Janus and @Coffee Pancake.

Nothing very useful to add on this. I tend to work by trial and error, I wrote my own Blender addon that uses an orthographic projection to create a height map from a model. That worked well enough for my needs (building a land that correlated to the scene I built for an FF region.) I probably then just messed with the sliders until I got what I wanted in the textures.

I've never looked in depth at the terrain code etc so any comments here are based on a cursory glance through.

The shaders seem to have nothing random in them, nor do they seem to have any FS specific changes, at least not in the last 7 or more years that I looked back through.

The surface patch code (which is responsible for generating the mesh for the terrain, does have FS (or at the very least TPV) specific changes as we deal with the nightmare of VarRegions on Opensim and the multitude of evils that fall from that. It is always possible that somewhere in history those changes have led to a variance in SL but I have nothing but conjecture on that.

Inside the surface patch creation code there is an element of noise being added. I've not looked close enough to find out where and why, but that could explain why there are small differences from machine to machine with the same code. That noise has been there since the start of the revision history (around 16 years).

(VarRegions for those that do not know about OpenSim, is a feature that allows OpenSim estates to have regions of varying sizes not just 256mx256m. A nice idea that adds layers of complexity into parts of the viewer)

8 hours ago, animats said:

This is from Firestorm. The ground surface is at Z=20.88. Note the thin rectangular object I placed on the ground as an elevation reference. That's above "High" texture level for all 4 corners. So it should be showing Texture 4, grass. But instead, it's showing Texture 1, ocean bottom.

I think the issue here is likely part of the fuzziness. high is the minimum possible start for texture 4, that doesn't mean it will be, though by the same measure texture 1 should be capped at 16, but depending on the granularity of the heightmap at that point I can well imagine that those might overlap in such a small sample range.

You mentioned "following the documentation" which (as I am sure you are well aware) is a very unreliable path to take in SL as documentation is at best vague notes on what might have been intended and at worst, a reverse engineered guess.

The code does not really support what is said about height levels. First it takes the 4 corner, min height values and does a bilinear interpolation, munges a few things and then gets an "exact height" to which it applies quite a large amount of noise (which would seem to support my assertion above about the narrow range of heights being the issue)

			//
			//  Choose material value by adding to the exact height a random value 
			//
			vec1[0] = vec[0]*(0.2222222222f);
			vec1[1] = vec[1]*(0.2222222222f);
			vec1[2] = vec[2]*(0.2222222222f);
			twiddle = noise2(vec1)*6.5f;					//  Low freq component for large divisions

			twiddle += turbulence2(vec, 2)*slope_squared;	//  High frequency component
			twiddle *= noise_magnitude;

			F32 scaled_noisy_height = (height + twiddle - start_height) * F32(NUM_TEXTURES) / height_range;

 

[ChinRey]

48 minutes ago, Beq Janus said:

I've never looked in depth at the terrain code

Maybe just as well; we do not want you to have a mental breakdown. Those are for paid developers only.

 

48 minutes ago, Beq Janus said:

Inside the surface patch creation code there is an element of noise being added. I've not looked close enough to find out where and why, but that could explain why there are small differences from machine to machine with the same code. That noise has been there since the start of the revision history (around 16 years).

I suppose that's the only plausible explanation.

 

48 minutes ago, Beq Janus said:

...

I can well imagine that those might overlap in such a small sample range.

I can confirm that the problem is worse the narrower the range is.

However, if you look at one of my previous post you'll find an example with the blend heights set to 10 and 200 m respectively. That's a very wide range and the texturing error was still a serious issue. (This was on opensim btw, I don't have any regions in SL anymore and I never will again.)

---

This reminds me of the first time I encountered the arbitrary texturing issue. It was back in 2013 and I had just bought a parcel of land in the Langdale sim. One day I logged on and found my lush lawn had transformed into gravel with a few clumps of grass scattered around. If you want to get an idea how dramatic the change was, check out the two different NW Coastal - Grass textures in the library.

In the end I simply covered the entire ground of Langdale, Buttermere and Coniston with mesh. Hardly an ideal solution of course but it was the only one that worked.

Edited October 13, 2022 by ChinRey

[Beq Janus]

6 hours ago, ChinRey said:

However, if you look at one of my previous post you'll find an example with the blend heights set to 10 and 200 m respectively. That's a very wide range and the texturing error was still a serious issue. (This was on opensim btw, I don't have any regions in SL anymore and I never will again.)

probably worth an OpenSim excursion one day to have a look at this. I'm focussed on some other things right now but that's intriguing as I don't see anything in the code that screams out for that kind of error range.

 

[ChinRey]

1 hour ago, Beq Janus said:

probably worth an OpenSim excursion one day to have a look at this. I'm focussed on some other things right now but that's intriguing as I don't see anything in the code that screams out for that kind of error range.

It may be hard to reproduce but we'll see.

I've been thinking a bit more about this:

8 hours ago, Beq Janus said:

Inside the surface patch creation code there is an element of noise being added. I've not looked close enough to find out where and why, but that could explain why there are small differences from machine to machine with the same code. That noise has been there since the start of the revision history (around 16 years).

As I said in an earlier post, there is at least one, probably three, perlin noise masks built into the system and those are essential parts of the texture blending but I suppose that's what you had in mind.

However, the added noise will still be perlin based and perlin noise is not random. As long as the seed and scale is the same, the output pattern will be the same and I can't see why those factors would be changed. It would mean adding complexity to the code to reduce the quality of the output and that doesn't seem to make any sense at all.

[animats]

21 hours ago, ChinRey said:

• Dirt: 0bc58228-74a0-7e83-89bc-5c23464bcec5
• Grass: 63338ede-0037-c4fd-855b-015d77112fc8
• Rock: 53a2f406-4895-1d13-d541-d2e3b86bc19c
• Mountain (not Ice!): 303cd381-8560-7579-23f1-f0a880799740

Thanks! Big help. Very old regions now display grass and dirt in my experimental viewer as appropriate. This seems to show up only for the original regions near Da Boom, so, probably, at one time, these were the only land textures. Ah, the joys of supporting legacy features in a new system.

[animats]

Thanks, everyone.

On a related topic, there have been some Linden mentions at Creator User Group about improving the land texture system. The sky was upgraded with EEP, and water is getting some attention as it is moved to deferred rendering. Land still doesn't look that great, because texture repeats are so visible.

Nice meadow of flowers, but the repeated pattern shows. Babbage Palisade

Hell, frozen over. Abandoned land in Corsica.

So that's the problem

Turns out there's been much research work on texture generation from exemplars. The texture you provide is an example of what you want, and an automated system generates more texture like it. So you can have huge areas of non-repeating texture from a small sample. This idea goes back about 20 years. There's a fancy version of it in Photoshop, in the content-aware background tool. That's the one you use to erase telephone poles in front of mountains and such. The program generates some fake mountain texture to  replace what you're erasing. It's like using the rubber-stamp tool, with some AI behind it.

So this has been around for a while, but until recently, it was too complicated to do in GPU shaders. That recently changed.

Original texture on left, larger generated texture on right.

Here's the research paper, with sample code, from which this came. There's a lot of math, but visually it's pretty simple. Short video which shows what's going on. It's breaking the image down into hexagonal tiles, making the edges match so they can be tiled, and then reassembling them randomly. If you look closely at the second image from the bottom, you'll see a little pattern of three rocks appear several times, at irregular intervals. But you have to look closely.

This trick can be applied to existing SL content. It would have to be turned on with a checkbox. This won't work for very regular textures, such as floor tiles, bricks, cobblestones, or wood planks. Works fine for dirt, rock, ice, snow, grass, etc. It could probably be turned on for mainland ground by default, because the standard mainland textures are all simple patterns.

Sample code is on Github.

[Wulfie Reanimator]

41 minutes ago, animats said:

Short video which shows what's going on.

That is so stupidly cool. 🤯

[ChinRey]

1 hour ago, animats said:

Turns out there's been much research work on texture generation from exemplars. The texture you provide is an example of what you want, and an automated system generates more texture like it. So you can have huge areas of non-repeating texture from a small sample.

That's absolutely brilliant.

Now, if LL actually is working on the ground texturing issue, maybe somebody can forward my outline of possible improvements too? I can't do it myself. I'm allergic to wasting time so I have to stay well away from both JIRAs and user group meetings.

Or if not the whole thing, at least sum up the most important points:

• Shared experience, that is a consistent blend pattern that looks the same to everybody.
• A way to set different textures under water and on dry ground and preferably one specifically for shorelines too
• A way to blend textures between regions with different texture sets

And maybe also:

• More precise control over transition elavations
• Adjutsable repeat rates (set as part of the simulator data, not as a user setting)

[Love Zhaoying]

17 minutes ago, ChinRey said:

I'm allergic to wasting time so I have to stay well away from both JIRAs and user group meetings.

You'd make a terrible Intelligentsia! 

..is joke!

[ChinRey]

7 hours ago, Love Zhaoying said:

You'd make a terrible Intelligentsia!

Thank you!

But seriously, I have to learn not to spend hours of boredom and frustration when there's nothing in it for me, not even a thank you. If somebody think those are good ideas, please feel free to go for it. If not, it's no skin off my nose.

[animats]

23 hours ago, animats said:

Thanks, everyone.

On a related topic, there have been some Linden mentions at Creator User Group about improving the land texture system. The sky was upgraded with EEP, and water is getting some attention as it is moved to deferred rendering. Land still doesn't look that great, because texture repeats are so visible.

Nice meadow of flowers, but the repeated pattern shows. Babbage Palisade

Hell, frozen over. Abandoned land in Corsica.

So that's the problem

Turns out there's been much research work on texture generation from exemplars. The texture you provide is an example of what you want, and an automated system generates more texture like it. So you can have huge areas of non-repeating texture from a small sample. This idea goes back about 20 years. There's a fancy version of it in Photoshop, in the content-aware background tool. That's the one you use to erase telephone poles in front of mountains and such. The program generates some fake mountain texture to  replace what you're erasing. It's like using the rubber-stamp tool, with some AI behind it.

So this has been around for a while, but until recently, it was too complicated to do in GPU shaders. That recently changed.

Original texture on left, larger generated texture on right.

Here's the research paper, with sample code, from which this came. There's a lot of math, but visually it's pretty simple. Short video which shows what's going on. It's breaking the image down into hexagonal tiles, making the edges match so they can be tiled, and then reassembling them randomly. If you look closely at the second image from the bottom, you'll see a little pattern of three rocks appear several times, at irregular intervals. But you have to look closely.

This trick can be applied to existing SL content. It would have to be turned on with a checkbox. This won't work for very regular textures, such as floor tiles, bricks, cobblestones, or wood planks. Works fine for dirt, rock, ice, snow, grass, etc. It could probably be turned on for mainland ground by default, because the standard mainland textures are all simple patterns.

Sample code is on Github.

Filed JIRA: https://jira.secondlife.com/browse/BUG-232769

[Chic Aeon]

On 9/8/2022 at 9:14 PM, animats said:

What are "base textures" and "detailed textures"? Is that an unimplemented feature?

I have been noticing on my sim with custom textures (1024s that a fairly blurry but good representation of the land texture comes on FIRST and then maybe a second or two later it becomes sharp so I am guessing that has something to do with your question. I don't remember seeing this before we went to the cloud but these days for me things are loading slower from the database almost consistently with mesh body parts floating in air. 

 

Textures are limited on my sims and my FPS on the ground is 128 so I don't think it is a region problem.   It would be very cool if we could have normal maps for terrain.  That would be a plus I think -- although that adds more to download LOL..  

More, more give me more!!!!!

 

 

[Beq Janus]

On 10/16/2022 at 1:13 AM, Chic Aeon said:

I have been noticing on my sim with custom textures (1024s that a fairly blurry but good representation of the land texture comes on FIRST and then maybe a second or two later it becomes sharp so I am guessing that has something to do with your question. I don't remember seeing this before we went to the cloud but these days for me things are loading slower from the database almost consistently with mesh body parts floating in air. 

Could just be the normal "incremental" loading, hard to say. My brief glance at the code (above) didn't highlight any obvious use of the base and detailed.

On 10/16/2022 at 1:13 AM, Chic Aeon said:

Textures are limited on my sims and my FPS on the ground is 128 so I don't think it is a region problem.   It would be very cool if we could have normal maps for terrain.  That would be a plus I think -- although that adds more to download LOL..  

normal maps would be good to a point. resolution becomes an issue but we know it works given how many of us resort to mesh terrain now to counteract the built in terrain sadness.

a displacement map would be even better (with the same resolution caveats) and given the current plans on PBR a couple of extra terrain maps is the least of my worries.

 

[ChinRey]

12 hours ago, Beq Janus said:

normal maps would be good to a point. resolution becomes an issue but we know it works given how many of us resort to mesh terrain now to counteract the built in terrain sadness.

One problem with normal maps on terrain is that with the simplistic lighting scheme the effect of a normal map is very angle dependent so we're likely to end up with exaggerated effects on steep slopes and barely visible ones on flat horizontal surfaces.

 

12 hours ago, Beq Janus said:

a displacement map would be even better (with the same resolution caveats) and given the current plans on PBR a couple of extra terrain maps is the least of my worries.

Displacement maps won't affect the physics model though and that may be an issue for walkable surfaces.

I stil think that the poor texture blending is the biggest shortcoming of SL's ground though, with the pitiful set of editing brushes being a good bad second. You're pretty much stuck with using the same texture set for adjacent regions since there is no way to create smooth transitions between them and as for separating underwater and dry land ground and creating beaches, just forget it. No matter how you tweak those transition height values you end up with grass under water and croal reefs way up on the hillsides.

 

13 hours ago, Beq Janus said:

...the built in terrain sadness.

I've already posted a picture of how SL terrain should have looked back in 2003. Today we should have expected a lot more of course.

I don't know if it's a coincidence or if YouTube's AI has learned how to read our minds but I logged on to reply to Beq's post, checked YT first and this old video came up on my recommended list. I'm not familiar with Godot but if I understand right, it's a kind of open source alternative to Unity. What we see here is not cutting edge landscape generation. It's a year old, the video is a simple introduction, not an advanced tutorial and Godot's terrain tools are obviously made for simplicity and user friendliness and don't have the advanced functions we expect from a dedicated terrain generator but it's still so much better than SL it almost makes me cry. Those brushes in particular, I WANT THOSE BRUSHES!!!

 

[Fluffy Sharkfin]

If LL added support for vertex colours and a very basic paint tool for terrain meshes then they could implement texture blending by vertex colour which would allow users to assign specific textures to any part of the terrain regardless of height and give more control over how textures are blended in specific areas.  It wouldn't be as neat as voxel terrain but it would at least be an improvement over the way in which land textures are currently assigned, especially if they increased the density of the terrain mesh to allow for more precision in terraforming/texturing.

[ChinRey]

51 minutes ago, Fluffy Sharkfin said:

If LL added support for vertex colours and a very basic paint tool for terrain meshes then they could implement texture blending by vertex colour which would allow users to assign specific textures to any part of the terrain regardless of height and give more control over how textures are blended in specific areas.

This seems to be how Godot does it. But the problem with SL's gradient+perlin noise based masking isn't the concept itself. That is actually very good, amazingly effective considering its simplicity. The problem is that it doesn't work as it's supposed to.

Keep this in mind:

On 10/13/2022 at 8:10 AM, animats said:

In my own viewer, I'm following the spec, and I get grass there. Which is probably what was intended by whomever laid out this region.

So, if SL's texture blending actually had followed the documentation it would have worked much better. Calleta is a fairly old region, launched as early as 2005, so it's possible the texture blending did work as advertised back then and only got messed up later. It would be really itneresting if we could find some old pictures of Heterocera regions and compare them to how they look today.

The reason the New Babbage region Animats mentioned looks even worse with his blending may be that it was created after the masking got messed up and the designer tweaked it to compensate.

[Fluffy Sharkfin]

19 minutes ago, ChinRey said:

This seems to be how Godot does it. But the problem with SL's gradient+perlin noise based masking isn't the concept itself. That is actually very good, amazingly effective considering its simplicity. The problem is that it doesn't work as it's supposed to.

Godot does seem to support vertex colours but from what I saw in the video you posted it uses them in a very literal way by allowing the user to tint the texture by changing the vertex colours as opposed to using the RGB values to determine how to blend various textures together.  I'm not sure I'd consider SLs current system "amazingly effective" (perhaps "surprisingly adequate" given how rudimentary it is), it's not bad at what it does but it lacks control and precision in comparison to assigning/blending textures by vertex colour.

[ChinRey]

1 hour ago, Fluffy Sharkfin said:

Godot does seem to support vertex colours but from what I saw in the video you posted it uses them in a very literal way by allowing the user to tint the texture by changing the vertex colours as opposed to using the RGB values to determine how to blend various textures together.

Yes, they seem to take the phrase "vertice colour" very literally. Still, it seems to work.

1 hour ago, Fluffy Sharkfin said:

I'm not sure I'd consider SLs current system "amazingly effective" (perhaps "surprisingly adequate" given how rudimentary it is), it's not bad at what it does but it lacks control and precision in comparison to assigning/blending textures by vertex colour.

Amazingly effective in the sense that it makes a lot out of very litte.

I don't really see any point in making the blend vertice dependent since the vertices of the mesh correspond directly with the pixels in the masks anyway so the best way to manually blend textures is probably the way Godot seems to do it, simply allow the user to edit the masks directly. This can easily be combined with SL's autogenerated gradient+perlin noise masks. Let the software generate the masks and then tweak any parts you're not happy with. That would give us the best of two worlds.

Add decals, adjustable repeat rates, water level awareness, crossregion blending, triplanar mapping for steep slopes, PBR (with server side baked alternative textures for lower spec clients), hex tiling, precise control over the blend elevations and maybe (just maybe) a variable number of texture layers. I can't think of anything else we can possibly need for the ultimate ground texturing system. (Well, actually I can think of two more things but they're probably not very important.)

Ground geometry is a different issue. There is a lot of room for impovement there too but I think we should leave it out for now.

Edited October 19, 2022 by ChinRey