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

JenniWindrider Resident This one? https://feedback.secondlife.com/feature-requests/p/terrain-painting

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.

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.

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 Nexii mentions you had an issue with the texture changing randomly for you. On what operating system and version did this happen?

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 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

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.

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?

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.

TommyTheTerrible Resident 1500+ times is in the loop for generating the terrain perlin noise, they are not just called 17 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 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...

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.

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.

Bumping Pixels I'm the individual who met with Tornado earlier: here's the same spot viewed on Windows:

Bumping Pixels 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.

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.

Bumping Pixels 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.

Without this fix, the kind of discrepancy below occurs.

Grass: As made and intended

Dirt: Affected by this issue, viewed on a Mac