Terrain Texture Blending Consistency
Nexii Malthus
The problem is that terrain blending is currently inconsistent in Second Life causing a lot of grief and even some economic issues as people can't use landscaping products as they expected the land to look the same between viewers and operating systems.
Terrain textures in Second Life are historically blended by using a Perlin Noise Generator to create more interesting variation: https://github.com/secondlife/viewer/blob/develop/indra/newview/llvlcomposition.cpp#L535-L554
The Perlin Noise Generator is expected to source the random numbers from a static seed (42) for
repeatable noise for stable terrain textures
as per: https://github.com/secondlife/viewer/blob/develop/indra/newview/noise.h#L313-L314However, documented in another viewer source file it is mentioned that you should use a different random number generator if you want
stateful random numbers
as per: https://github.com/secondlife/viewer/blob/develop/indra/llcommon/llrand.h#L34-L37This is because the functions used "srand" and "rand" from the c++ standard library are implementation defined and can even change across compiler versions / operating systems, which is why terrain blending can look different even across TPVs even if all the relevant code is unchanged.
Therefore, I request that the viewer is updated to use a
stateful random number with a fixed seed
going forward as it is EXPECTED to work that way, as per the code's own comments left by developers in the past.Log In
JenniWindrider Resident
Going off on a tangent here:
It's on the backburner (or possibly shelved for good?), but there was a plan to allow custom terrain texturing, akin to how games do this e.g. for terrain paths and the like. That likely only helps sim owners, but IMO a fully static bake on mainland should help fix that issue.
Assuming that the terrain painting goes ahead someday, I'd expect some kind of server-side bake to come along with it. Depends on implementation.
Nexii Malthus
JenniWindrider Resident I saw a fair bit of code mentioning the feature actually, think it is called Paintmap, while I was going through all the code trying to look for the perlin noise generation. A quick search highlights this document: https://github.com/secondlife/viewer/blob/develop/doc/testplans/pbr_terrain_paintmap.md
RestrainedRaptor Resident
JenniWindrider Resident This one? https://feedback.secondlife.com/feature-requests/p/terrain-painting
Jenni Darkwatch
Nexii Malthus A different system. The comment you linked might have originated from that discussion though.
As far as I recall (it's been a while), the idea was to be able to use the four textures (or even more than four) arbitrarily with a blend modifier. The talks didn't get past the brainstorming stage and I can't find the original discussion (which I think happened on the SL Discord). Think of it the same way Unity and other game engines allow arbitrary terrain painting.
Jenni Darkwatch
RestrainedRaptor Resident Yes, like that. The discussion stalled at what kind of system to use to create/store the terrain map, as there's no industry standard way to do it - and then of course focus shifted to bugfixing/performance improvements.
RestrainedRaptor Resident
Jenni Darkwatch Well there are many ways it could easily be done. One of the simplest to use and draw, albeit not very efficient, would be a square bitmap, where black is texture 1, and varying amounts of RGB can represent the intensity of the other 3 textures. Kinda like heightmaps that are already supported by SL.
ChinRey Resident
I don't know how hard it would be to implement but the ideal solution would be server side baking. 64 textures for each region (each covering 32x32 m) mipmapped all the way up to 2048x2048 and with max resolution configurable in the viewer.
Save the baked textures on the assets servers and only update when it's actually needed. Terrain textures aren't usually changed every month, or even every year, so it's hard to see a reason why they have to be rebaked every time somebody enters a region.
TommyTheTerrible Resident
ChinRey Resident Nexii mentions you had an issue with the texture changing randomly for you. On what operating system and version did this happen?
ChinRey Resident
TommyTheTerrible Resident It only happened once and it's ten years ago now so I don't remember which viewer version it was but the OS I used was Windows 8.1. Or to be more precise, I only noticed it once when I was working on the terrain of my sim and got a flip just as drastic the one in Rogaman's illustration, only it was on the same computer from one day to the other.
I think Nexii solved that little mystery. When I said there was no software changes that caused it, I was only thinking about the SL software. It didn't occur to me that the texture blending could depend on the OS. My computer was still set up to automatically install OS updates back then and it may have been one of those that triggered it.
TommyTheTerrible Resident
We need to make our own rand function, copy one from a code base with a compatible license, use a rand function from a neutral library or argue about this for another 14 years.
I hope we choose wisely.
Nexii Malthus
TommyTheTerrible Resident I agree and the viewer code itself already mentions to use the random number generators from the boost library, so that seems easiest to switch to
TommyTheTerrible Resident
Nexii Malthus I just ran some quick tests on Windows and the seeded random always produces the same four numbers.
srand(42)
Rand test1: 175 test2: 400 test3: 17869 test4: 30056
We can just replace the four rand functions in the init function in noise.h with those numbers, which will make the noise the same across all platforms.
But this forces the Windows noise texture onto Linux and Mac.
Going to test it now to compare between Windows and Linux.
Edit: Added commit and screenshots from Windows and Linux
Linux is the snapshot with the water more transparent.
Nexii Malthus
TommyTheTerrible Resident ChinRey had reported: "I logged on one day and found the ground texturing completely changed from how it was the day before. I hadn't done anything to my computer in the meantime, it hadn't even been switched on, and there had been no changes to the sim."
Likewise the microsoft documentation mentions that rand/srand are tied to "global state affected by app/os separation": https://learn.microsoft.com/en-us/cpp/c-runtime-library/global-state?view=msvc-170
The srand documentation also mentions: "By default, this function's global state is scoped to the application. To change this behavior, see Global state in the CRT." -- https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/srand?view=msvc-170
Even on Windows alone it can be different between users if it's scoped to the application, in theory. At least in one instance per above with ChinRey it merely flipped between computer shutdown overnight with no other apparent changes on the same application.
rand also gets called like +1500 times at least, I can't imagine just writing down every number into the code being a good use of anyones time when pegging it to a reliable number generator like from the boost library would do the job.
However sticking it to the existing values of one platform or the other (I guess Windows is the majority here) is a good idea but I'm not sure how they would approach that. Would they really have to just simply generate multiple thousands of values that are hardcoded into the application?
TommyTheTerrible Resident
Nexii Malthus I think you're misunderstanding what the links are saying.
A seeded random function will always produce the same numbers for that seed. If it did not, it would not be useful and a large number of processes relying on that behavior would break.
The issue is that we are using two different seeded random functions, one for Windows and one for Linux/Mac, that are producing two different sets of numbers because they are using different methods to make those numbers from two different libraries.
The rand function is only seeded once (srand) in the entirety of the viewer code, inside of noise.h (seen in the commit above).
Including the noise.h, rand is only used 17 times, not 1500+ times like you say. Four of those times is in noise.h, and only those four times seeded.
I have not suggested replacing the rand in those other 13 instances, although the four instances in the Perlin noise for the clouds might be nice to be replaced with a parametric system to make the clouds look the same for everyone (OR MAKE BUNNIES), but that is outside the scope of this discussion.
Nexii Malthus
TommyTheTerrible Resident 1500+ times is in the loop for generating the terrain perlin noise, they are not just called 17
times
but are in the context of loops (which I roughly estimated), this is in context of your idea to replace the function with "four numbers" which would create a completely messed up and uniform/repeating perlin noise texture:> We can just replace the four rand functions in the init function in noise.h with those numbers, which will make the noise the same across all platforms.
Unless taking into account that there about +1500 numbers being pulled through in the loop, so it would have to be replaced in a different way that includes all those numbers. (lol this is getting a bit silly)
The thing that made me concerned or worried about the Windows implementation is because Second Life Official Viewer is not the only Viewer out there, there are many third party viewers such as Firestorm. So the srand function being pegged to the
App
rather than the OS, according to the documentation at least, what does that mean for other "applications", e.g. TPVs? I'm just not sure what the Windows implementation is actually doing here. The fact that it is sometimes the same seed across different applications makes the matter even more confusing, is it tied to the app or not? And I feel like that I might have experience terrain blends shape changing over time like with that Chin mentioned flipping overnight because I'd always felt that some sims didnt quite match with my memory but I could never exactly figure out why, but it has been over such a long period of time (two decades of SL), that it would be hard to try to nail down specifics, but now that I know that it is a possibility...TommyTheTerrible Resident
Nexii Malthus Alright.
In my haste to find a simple solution, I made too many assumptions.
I've removed the commit and look forward to whatever solution is decided.
Nexii Malthus
TommyTheTerrible Resident hardcoding in the current numbers is definitely an option still, but they'd have somehow make sure to cover all the numbers currently used so far and well... that's a lot... just to copy-paste it into a gigantic lookup table, with some fallback to use a stable number generator for numbers beyond the table on that specific seed.
It does seem like a ridiculous solution, but it's not completely wrong, as it has merit of (presumably) matching to what the biggest userbase might be seeing right now for the terrain.
Tornado Siren
I tested two different machines this evening for this issue and was not able to reproduce it across Firestorm 7.1.13 beta and Linden Lab release 7.1.13. Firestorm on a desktop PC running Arch Linux and the Linden Lab release running on a MacBook Air M1 with macOS 15.4.1.
From my perspective alone it appears that 2/3 platforms are currently in consensus on what is correct, and testing with another individual using Windows with an unspecified viewer version was the outlier.
There are resolution and sharpening differences between my two screenshots however the noise distribution is the same for two different viewers on two different machines.
Mirror Mondegreen
Tornado Siren I'm the individual who met with Tornado earlier: here's the same spot viewed on Windows:
Nexii Malthus
Tornado Siren I think that linux and mac are both compiled with gcc (likely same version as well) and windows with msvc instead, if I recall correctly but I might be wrong since it's forever that I did c++ / TPV dev. That might explain why both linux and mac generally agree with windows being different.
Tornado Siren
Nexii Malthus Apple's XCode uses Clang/LLVM and not GCC. Different compiler, and my visual results do not change on Linux when using LLVM rather than GCC. Microsoft's MSVC remains the odd-one-out among the three compilers involved.
TommyTheTerrible Resident
Tornado Siren They may be different compilers, but the libraries are obviously using the same method to create the seeded randoms to be compatible with one another.
As we discussed in the Builders Brewery group chat, a single method needs to be determined to make the noise texture consistent on all platforms. Since most of SL's users today are on Windows, it makes sense to just use the values that MSVC provides today.
By hard coding in those values, it would also help migrate the Windows building off using MSVC in the future, like some viewers have already done, and keeping the experience the same for those users.
Rogaman Resident
I am literally having to spend hours and so many extra prims now masking mesh to terrain joins across a whole region - now knowing that users on different OS could see rock texture where I see grass, for example.
By the looks, to do it proper and realistic as possible, I think this amounts to more than 1000 prims just to mask the issues this causes . Will I at least get credited these prims back for having to do this workaround?
For people like me and others on this thread, we are trying to build spaces that improve the whole experience for all.
If this was a free service, ofc, can accept issues - but we literally pay for this land and terrain tool.
This is clearly a bug, in any other payed for service tool for designers and creators, this would be very serious.
See again this picture below, clearly and obviously a huge issue / bug.
She is on windows. I am on Mac
If I can help in any way, very happy to.,ill Bring drinks for the devs.
Mirror Mondegreen
This would be an absolutely invaluable implementation! Thoroughly well-thought solution all round Nexii!
A huge part of the region design process is blending between mesh terrain pieces (rocks, cliffs, beaches, false land to connect the two or allow for believable hidden underground cave systems or structures) and Linden terrain. I've been designing regions for eighteen years now and the fact that the same environment current looks totally different depending on the Operating System and Viewer is a huge issue for using the inworld creation tools with any precision.
Here's an example of how an environment with blending can look: the part that comes up highlighted in teal is Linden terrain, the rest are rock and terrain meshes which have been designed specifically so the bottom of the texture blends neatly into the land
Mirror Mondegreen
Without this fix, the kind of discrepancy below occurs.
Grass: As made and intended
Dirt: Affected by this issue, viewed on a Mac