Henri Beauchamp

December 8, 2020

44 minutes ago, steeljane42 said:

How? It's clearly not a grid wide issue, you'd see lots more posts on forums like every single time something breaks and less online numbers in-world. I, personally, had no issues with SL recently. So it sounds like either a regional or ISP issue to me, maybe certain routing from his place to AWS servers LL are using now. To find out the issue must be filled somewhere, jira or ticket at least.

I did work in ISP for a long time and using example from there. It's relatively easy to see a big issue that affects a lot of people, like a 100gbit fiber line cut or dead/dying hardware. Heavy traffic drops on graphs, bunch of fcs and other errors, etc. But if it's a problem on the ”last mile”, that affects 10 to 50 people at most, then until someone of those affected people will poke a tech support and they check manually, then there's no problem anywhere as far as ISP is concerned.

I have a 1Gbps (downlink)/700Mbps (uplink) FTTH connection to Internet, without any issue on it, and provided by a major ISP in France (Free/Illiad).

I have no issue whatsoever connecting to Amazon web services, outside of SL (all Amazon websites load super fast and without a glitch).

I also had no issue in SL before USA's Thanks Giving.

There are other affected people (see this thread, for example), that I assume do not use the same ISP and are most likely not living in the same region or even the same country.

Obviously, LL broke something just before the Holidays and no one cares ever since (they even went as far as shutting down entirely their support service that very week-end !).

As for the JIRA, I gave up on it a long time ago: posting an issue on it is like ”pisser dans un violon” like we say in France. I have detailed logs (Wireshark pcap and viewer) available to any Linden who will care contacting me.

December 7, 2020

And when are you going to fix the issue with super-slow or failing connections (login, seed replies, capabilities fetches, simulator features, AIS3 inventory, bakes) ?... After November the 26th everything got ruined for me in SL because of them: when the AWS servers take 30 seconds or more (!) to perform the cited connections, everything fails in SL !!!

And not even a word about this MAJOR issue on the grid status page !

December 4, 2020

9 minutes ago, Keishaa Meili said:

Promise i will spend my time on it: somehow I have to kill the wait until LL will intervene, and I could even be faster. Lets keep working...

If you got a Linux PC, I'd recommend building the viewer under it, since it's just a matter of typing a single command in a terminal pointed at the viewer sources !

Windows and macOS require installing IDEs (VS2017, XCode11), which is a more complex task than building the viewer itself once they are installed...

December 4, 2020

If you can compile a viewer yourself, a patched version would allow you to delete the offending folders. You may want to try the Cool VL Viewer which is easy to build and which code already contains an exception for OpenSim grids and the COF (allowing you to delete the latter in OS grids, since it is not mandatory there).

The line to change to allow deleting the ”Current Look” folders is in linden/indra/llinventory/llfoldertype.cpp, line 142. Change that line to read:

if (folder_type == FT_CURRENT_OUTFIT)

(i.e. remove ” && sCanDeleteCOF” from it).

Recompile the viewer, log in, delete the two offending folders.

BEWARE however: DO NOT, under ANY PRETEXT, delete the ”Current Outfit” folder in SL (and if there are several folders named ”Current Outfit”, do NOT delete any of them, but let LL support deal with them): deleting the COF would cause bake failures, even after recreating it (I know first hand, because I deleted mine by mistake once during a viewer testing session): the reason is that its version (i.e. the number of times it got updated) is somehow kept in SL's servers and as long as its version is lesser than the one used for the last successful bake, you cannot rebake with it. I reported that bug (that I worked around for my account by rebaking for hours via scripted RLV @attach/@dettach actions until the new COF version got greater than the old deleted COF version), years ago, but I doubt LL fixed it...

December 2, 2020

2 hours ago, Keishaa Meili said:

No, you aren't the only one, but LL seems nonchalant about it, anyway.

To me, its a week as a cloud. Just figure how i could feel.

From what I understood, your baking issue is not the same as the server communications issues we have been seeing for the past 4 days or so.

I bet your issue would be easily solved using a viewer able to erase the COF contents and rebake from scratch: there are probably stale links in there, preventing your avatar to bake...

December 2, 2020

29 minutes ago, steeljane42 said:

It would be interesting to hear from LL what actually happened. Because it's quite obvious that it wasn't grid wide. I spent at least 5 hours daily in SL from friday to tuesday (mostly during peak hours with >50k people online), to catch up on sales. And the only TP fail I had was when I was teleporting out from nearly dead (below 1% scripts run) region that was full non stop. Can't say I had a single issue with logins, baking or anything else either.

Well, I'm developing my viewer, so I log in and out many times a day (to test new code, etc), so I see any login issues happening before many people would, I guess...

It may also depend on your country, since you'll hit different AWS servers based on it... In France, it was an awful SL week-end and problems extended from Friday to yesterday afternoon, and still seeing slow parcel info updates today, ~~even if logins seem much more reliable~~... so far (morning here).

EDIT: spoke too soon... Logins fail again today !

December 2, 2020

7 hours ago, Lucia Nightfire said:

What are you testing in each of those versions? heh

SLers' level of patience and frustration ? 🤣

Can't be worst than what happened during the past 96 hours, can it ?... I mean, I never saw such an amount of issues with SL failing logins, TPs, inventory fetches, baking, etc, and of course, all of them happening while support was offline... 🙄

November 28, 2020

Same for me: for now over 24 hours, I have had issues with SL servers not responding or only very slowly. It may start at ”logging in”, ”waiting for region handshake”, ”waiting for seed” or ”connecting to region” during login process, each of these steps denoting an issue with SL servers slow or failed replies.

Sometimes, it takes me no less than 6 attempts to manage getting in SL when it had been flawless for years !

Sim seed and capabilities are also often failing to arrive on time after TPs, resulting in various issues (textures loading delayed, bake failing or incomplete, parcel information not arriving, etc).

Finally, the inventory service seems impacted as well (especially when the AISv3 protocol is enabled), with slow or failing inventory fetches, failing bakes after outfit changes, etc...

In the viewer log I can see a lot of ”out of order UDP packets” lines too, something that rarely ever happened before...

All these seem related to the ”servers uplift” and how some services are still split over AWS and LL's servers...

SL is really in a very bad shape right now: it would compare with the level of reliability (or lack thereof) of the 2006-2008 era !... Well, not quite, because a full grid down time is still to happen today, but at this rate I won't be surprised if it would happen ! 🙄

And of course, to top it off, support is offline when this happens !

October 25, 2020

Support for the Cool VL Viewer is exclusively provided via the Cool VL Viewer forum (in-world requests, in whatever form, will NOT be replied).

Also, do not listen to some people silly replies provided elsewhere, especially when they have been banned from my own forum for their wrong doings.

September 15, 2020

On 9/14/2020 at 10:46 AM, Profaitchikenz Haiku said:

Ditch Windows, use Geany or Gedit

Ditch every modern editor/IDE: keep using Nedit (or XNedit for people using UTF-8) ! 👴

I have been programing with it in all languages (C, C++, Forth, Perl, Tcl/Tk, JavaScript, Java, Python, PHP, bash, etc), for the past 26 years... And yes, I even made syntax highlighting ”recognition patterns” settings for LSL in Nedit...

Seeing how much code I produced with this editor (that also can act more or less like an IDE since you can launch complex commands with it, including compilation), I can tell you it certainly does not harm my productivity. 🚅

And yes, the Cool VL Viewer is entirely coded using Nedit.

August 24, 2020

1 hour ago, KjartanEno said:

@Henri BeauchampCurrent Mesa drivers on Linux support a tear and stutter free variable refresh rate for modern AMD GPUs when used with DisplayPort on adaptive sync monitors. It is what it is, and I've said all I had to say.

Adaptive sync is like VSYNC, but at a variable rate: if you use it, you will NEVER get the maximum frame rate from your games, for the driver inserts pauses whenever the frame renders too soon to be displayed in sync with the next monitor frame. You CANNOT get the best performances in frame rates with adaptative sync of VSYNC. The Cool VL Viewer does not try to switch sync modes on/off, unlike some other viewers. As for tearing, I never saw any here while I have no sync scheme set for my driver: simply use triple buffering and you will be tear-free and with the best frame rates.

You are free to use your driver settings the way you like, but then do not come and complain about low frame rates !!!

This is my last message on this topic.

August 24, 2020

1 hour ago, KjartanEno said:

My system is running Linux, kernel 5.5.12-desktop-1omv4001, Mesa 20.0.7. I have a Ryzen 1300x (4 cores) @ 3.575 GHz, MSI B450M motherboard, 16GB (2x8) DDR4 3200 RAM (@3200 in BIOS), Sapphire Nitro+ SE AMD RX 580 8GB. My monitor is 1920x1080 144Hz adaptive sync.

And this is just now that you reveal you are using ”adaptive sync”... What happens when you turn it off ? Mind you, when in adaptive sync mode, the driver may purposely slow down the frame rate in order to better sync with the monitor...

Quote

I press CTRL+9 for the default field of view.

And like I explained, the default field of view in the Cool VL Viewer is NOT the same as in other viewers... You must edit the corresponding debug settings (CameraOffsetDefault for the Cool VL Viewer and CameraOffsetRearView for Firestorm) to get them to match exactly, or you will get a different amount of objects in the FOV, meaning a different load for the renderer.

August 24, 2020

54 minutes ago, KjartanEno said:

Which apparently only affects the performance of Cool VL Viewer? Come on, Henri, I want to work with you on this. You're a smart person. This is a puzzle. I want to figure it out.

Look, I just made another test, in Aditi, in an empty sim so to avoid different surrounding avatars in different viewer sessions, but with some scenery so that it does tax the renderer. The sim is Moonberry Bay, at pos 117,181,21 (on the pier, looking SW towards the shore). All settings to the max (with specific settings in both viewers set so they are the same, i.e. mesh multiplier LoD factor set to 1.0 and Classic clouds off in Cool VL Viewer, Render LOD Factor limited to 3 and terrain details LoD to 2 in Firestorm), 512m draw distance, camera angle set the exact same way (this is super important since the default camera angle of view is different, the one in my viewer being behind the avatar (Z=0) while it is slightly above in other viewers, meaning you pick up and render more objects in the distance in my viewer while you render more floor/terrain in others !), all shadows and no SSAO/DoF blur when in ALM.

Cool VL Viewer:

WL, non-deferred (ND) rendering: 65fps

WL, ALM: 55fps

EE, ND: 43fps

EE, ALM: 39fps

Firestorm v6.3.9 (WL);

ND: 26fps

ALM: 22fps

Firestorm 6.4.5 (EE):

ND: 30

ALM: 26

This is an easy bench for everyone to reproduce... Amusingly, Firestorm 6.4.5 (EE) seems faster to render this scene than v6.3.9 (WL)... It might be an effect of the new alpha textures batching code in the EE renderer...

August 24, 2020

29 minutes ago, KjartanEno said:

Alrighty then, so we are comparing WL and EEP performance as they stand among the currently available viewers. I cannot provide any meaningful information from the official LL viewer on Linux, so here it goes. As I've said before, I use all of these viewers, some more than others, because they all do things that I like. I want to see things improve, but that takes meaningful discussion. It's easy to pick favorites and join teams. I'm not on any team. I just want the facts. All measurements were made in the exact same location, with the exact same avatar (fully mesh, HUDs and all), with as close to the exact same settings as possible: 128m, full ALM with ambient occlusion, shadows, anisotropic filtering, antialiasing, etc., in a skybox. Trust me that if I can run Linux for a decade and Second Life viewers since 2015, I'm not a newb at settings.

Firestorm 6.3.9 WL                  108 fps official download
Firestorm 6.4.8 EEP                   86      self compiled in Ubuntu 16.04 -O3 -AVX2
Kokua 6.4.6 EEP                         89     official download
Singularity 1.8.7.8193 WL      125    official download
Cool VL Viewer 1.28.0.6 WL     85       self compiled in Ubuntu 16.04 -O3 -AVX2
Cool VL Viewer 1.28.0.6 EEP   70        self compiled in Ubuntu 16.04 -O3 -AVX2 RenderWaterCull=1 (EE&ALM only)
Cool VL Viewer 1.28.0.6 WL     83       official download
Cool VL Viewer 1.28.0.6 EEP   69        official download RenderWaterCull=1 (EE&ALM only)

Perhaps my Ryzen system doesn't like Henri's official release being compiled -O3 for his own Intel CPUs, which could include all his precompiled libraries?

Thing is, you are the only one to get these results... I could post mine here (that are in total contradiction, and on 4 different PCs, ranging from a super old Althon64 + Radeon 9700 to a brand new 9700K + GTX 1070 Ti), but this would be off-topic... Just like this post of yours.

I told you on my forum that your system probably had an issue with the frequency or power governor and/or with the BIOS settings for the max package power and/or max socket current...

August 24, 2020

1 hour ago, Stevie Davros said:

From what I have seen in the past few weeks the performance hit is not that drastic for EEP over Windlight.

Dead easy to prove you wrong here. Get the Cool VL Viewer, wait for every texture to load (switching renderers while some load might get them in the wrong texture channel), then switch on/off ”Extended environment shaders” in the graphics settings (not touching anything else), and observe the frame rate...

August 24, 2020

1 hour ago, arabellajones said:

One of the EEP problems is that there are a lot of problems which have been accepted as bugs, and are in a process of being fixed.

I feel I can trust you to keep up with those changes.

Some TPV developers feel over-secretive on this. The moving target for EEP doesn't help anyone, I am probably going to change every material I have set up to look ”right” in EEP (and I am not sure, reading reports upthread, if I have even started with useful EEP environment settings: what can I trust?).

I strive to stay on par with LL's latest (often not even yet released) changes, and every modification to the EE renderer gets backported in the Cool VL Viewer (and with weekly releases, the changes in LL's git appear only a few days later in the next Cool VL Viewer release); that's why you see different results in the EE renderer of my viewer when compared with other viewers with a slower release rate.

This said, as I already wrote in this thread, EEP (P for ”project”, and it will stay as such (i.e. not of actual release quality) for a loooong time, I'm afraid) has been ”released” way too soon by LL. Not only does it break existing contents, but it is a performance killer (thus why I implemented the dual-renderer feature in my viewer: people not caring about pretty skies shall not suffer a 50% performances loss because of EEP !).

August 21, 2020

On 8/20/2020 at 6:06 AM, KjartanEno said:

As sluggish as Cool VL Viewer is on my system compared to Firestorm (sorry Henri, but it's true)

LOL !

The Cool VL Viewer is probably the fastest viewer around (the main loop is about 50% faster than LL's viewer and 40% faster than Firestorm's)... Singularity may sometimes equal it, but all others are MUCH slower.

If it is ”sluggish” for you, it is probably a problem with the settings. You can only compare viewers when using the exact same settings in the exact same conditions... Benchmarking is an art...

July 30, 2020

1 hour ago, JoyofRLC Acker said:

Good work, and interesting.

Is there a hypothesis as to the reason? Has this been repeated yet, or is it just a one off?

I'm afraid such benchmarks are not very significant, unless you know for sure the sims are running on the same hardware (especially with the same CPU power) sharing the same load (number of sims per server, RAM usage to avoid swapping, etc), and (if applicable) using the same virtualization software/hypervisor... Too many unknown variables for us: only LL devels/admins can perform such benchmarks in a proper/deterministic way.

July 30, 2020

On 7/29/2020 at 11:48 AM, Wulfie Reanimator said:

Now add 100-200 Mono scripts to yourself.

My avatar was already wearing 80+ scripts... Adding more scripts of mine won't change things much, for my scripts are well optimized (especially in the memory usage (most important for sim crossing) and events processing departments) ! 😜

I'd need to add badly scripted stuff to my Aditi inventory... But feel free to use by yourself the same method as the one I described. 💭

July 28, 2020

21 hours ago, Simon Linden said:

We just did some updates this morning (Monday July 27th) that fixes a bunch of the region connectivity issues. I just did a tour and didn't hit any invisible walls.

Yep, seems working just fine now.

Quote

Along those lines, I made a quick ”Blake Sea Challenge” Go to secondlife://Aditi/secondlife/Morris/200/207/34 on the BETA aditi grid, and click on the red egg-shaped thing to try it out. It will give you the ”Blake Sea Challenge” ... wear it and touch, and it'll get you going. Follow the instructions to sail / fly / motor around 46 regions without doubling back and see if you make it. Have fun and keep letting us know how it goes!

Did it flying (avatar fly only) with a ”mildly heavy” avatar (25 attachments, around 80 scripts capped at around 3Mb of RAM):

Quote

Blake Sea Challenge: Yay all done!! It took 11 minutes and you never got lost!

But you should change the permissions of the gift it gives, because I also got:

Quote

Blake Sea Challenge: Cannot give no-copy objects from an attached object.

😜

Here are the region crossing times I got from the viewer log:

Personal test:
2020-07-28T15:13:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 435.148 ms 
2020-07-28T15:13:34Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 393.159 ms 
2020-07-28T15:13:59Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 439.247 ms 
2020-07-28T15:14:11Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 391.723 ms 
2020-07-28T15:14:28Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 450.473 ms 
2020-07-28T15:14:44Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 457.707 ms 
2020-07-28T15:15:01Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 438.855 ms 
2020-07-28T15:15:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 451.317 ms 
2020-07-28T15:15:35Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 394.944 ms 
2020-07-28T15:15:39Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 423.022 ms 
2020-07-28T15:16:02Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 394.764 ms 
2020-07-28T15:16:05Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 401.468 ms 
2020-07-28T15:16:06Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 403.55 ms 
2020-07-28T15:16:10Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 446.477 ms 
2020-07-28T15:16:14Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 368.816 ms 
2020-07-28T15:16:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 382.727 ms 
2020-07-28T15:16:22Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 446.515 ms 
2020-07-28T15:16:25Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 371.96 ms 
2020-07-28T15:16:27Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 448.023 ms 
2020-07-28T15:16:29Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 388.299 ms 
2020-07-28T15:16:32Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 445.138 ms 
2020-07-28T15:16:34Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 430.341 ms 
2020-07-28T15:16:36Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 442.932 ms 
2020-07-28T15:16:38Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 413.238 ms 
2020-07-28T15:16:40Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 447.037 ms 
2020-07-28T15:16:43Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 388.694 ms 
2020-07-28T15:16:46Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 425.852 ms 
2020-07-28T15:16:51Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 386.307 ms 
2020-07-28T15:16:55Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.2 ms 
2020-07-28T15:16:58Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 444.341 ms 
2020-07-28T15:17:16Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 445.237 ms 
2020-07-28T15:17:22Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 437.963 ms 
Back sea challenge:
2020-07-28T15:20:42Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 419.862 ms 
2020-07-28T15:20:58Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 356.679 ms 
2020-07-28T15:21:14Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 369.125 ms 
2020-07-28T15:21:30Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 419.841 ms 
2020-07-28T15:21:47Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 363.55 ms 
2020-07-28T15:22:03Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 422.33 ms 
2020-07-28T15:22:19Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 385.414 ms 
2020-07-28T15:22:35Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 411.964 ms 
2020-07-28T15:22:51Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 435.624 ms 
2020-07-28T15:23:07Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 448.512 ms 
2020-07-28T15:23:28Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 381.7 ms 
2020-07-28T15:23:44Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 390.958 ms 
2020-07-28T15:24:00Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 387.146 ms 
2020-07-28T15:24:10Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 427.114 ms 
2020-07-28T15:24:26Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 391.214 ms 
2020-07-28T15:24:42Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 371.007 ms 
2020-07-28T15:24:59Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.141 ms 
2020-07-28T15:25:16Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 445.889 ms 
2020-07-28T15:25:28Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.793 ms 
2020-07-28T15:25:42Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 401.7 ms 
2020-07-28T15:25:58Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 389.019 ms 
2020-07-28T15:26:14Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 398.36 ms 
2020-07-28T15:26:31Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 387.909 ms 
2020-07-28T15:26:44Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.128 ms 
2020-07-28T15:27:01Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 392.492 ms 
2020-07-28T15:27:17Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 442.12 ms 
2020-07-28T15:27:38Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 390.326 ms 
2020-07-28T15:27:52Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 385.123 ms 
2020-07-28T15:28:06Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 398.123 ms 
2020-07-28T15:28:22Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 390.206 ms 
2020-07-28T15:28:36Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 446.418 ms 
2020-07-28T15:28:52Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 398.019 ms 
2020-07-28T15:29:08Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 383.912 ms 
2020-07-28T15:29:23Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 386.911 ms 
2020-07-28T15:29:39Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 443.062 ms 
2020-07-28T15:29:55Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 396.678 ms 
2020-07-28T15:30:01Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 447.504 ms 
2020-07-28T15:30:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 391.238 ms 
2020-07-28T15:30:27Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 394.383 ms 
2020-07-28T15:30:36Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 385.006 ms 
2020-07-28T15:30:55Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.23 ms 
2020-07-28T15:31:06Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 441.859 ms 
2020-07-28T15:31:22Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 450.933 ms 
2020-07-28T15:31:40Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 442.411 ms 
2020-07-28T15:31:56Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 391.386 ms

As you can see (or rather cat | cut | sort, 'cause I'm lazy), the minimum was 357ms and the maximum 458ms.

It should be noted that during my personal test, I tried hard to make crossings fail (for example by flying in circles at the frontier/corner of four regions, to enter and re-enter regions as fast as possible).

So I'd say it's a very good start for the new region crossing server code !

July 26, 2020

Greetings,

I just discovered this new testing ground yesterday and gave it a try. While flying (avatar ”Fly”, i.e. not flying any scripted plane or such), most Blake* regions crossings were flawless (with at worst a split second ”hiccup” at crossing), but I did notice strange things, such as regions visible/active on map and invisible/inactive on mini-map and not accessible via crossing from other regions (while it was possible to TP into some). It was late in the night for me, however, so I did not take any note of time and region names.

Today, I gave it another try and stumbled upon the same issue as yesterday, with one region in particular, inaccessible via borders crossing (excepted from one region: more on this later), but into which you can TP to. This region is ”Half Hitch” (debugging it might turn into a ”full itching” for you 😜). After I TPed into it, wearing a mildly scripted avatar (with 25 attachments containing around 80 well scripted/optimized scripts, consuming less than 3Mb or memory), I succeeded in crossing the South border to ”Turnbuckle”, but all other borders in the latter were uncrossable, so I headed back North to ”Half Hitch” and found myself ”stuck” just after the border, with the viewer disconnecting after timeout. When I re-logged to ”Last location”, I found myself back inside the region where I departed (”Kraken”) for my trip and before I TPed to ”Half Hitch”.

Here is a zip file (too bad this forum refuses zip attachments...) with two logs (and a screen shot taken while ”stuck” and before timeout); the first log was from a session when I used a much lighter avatar with only a few attachments and scripts: I stopped in ”Kraken” to change for an ”heavier” outfit and since I got a ”Failed to rez attachment” message (not unusual in Aditi), I re-logged to avoid any possible issue with ”in flight” attachments data while crossing sims. The second log is the most interesting one, in particular with the warning message appearing here:

2020-07-26T13:51:07Z INFO: process_crossed_region: Crossing region boundary
2020-07-26T13:51:07Z WARNING: LLWorld::addRegion: Region exists, but old host 54.244.7.15:13006 does not match new host 0.0.0.0:0. Removing old region and creating a new one.
2020-07-26T13:51:07Z INFO: LLWorld::removeRegion: Removing region 290048:268800
2020-07-26T13:51:07Z INFO: LLViewerObjectList::killObjects: Removed 8282 objects for region Blake Sea - Half Hitch in 24.416ms

It looks like a bogus IP (0.0.0.0) was transmitted to the viewer for the region it was entering !

July 20, 2020

14 hours ago, animats said:

There's an open-source library for running Vulkan on Macs.

Thing is: we know strictly nothing about Apple's future custom GPUs (since they plan to do away with NVIDIA and AMD and to use their home-made silicon chips)... Open Source is far from being the characteristic of Apple's ecosystem, and nothing can give us a single clue wether their future GPU will have an open (as in at the very least *documented*) API or will need reverse-engineering to add Open Source Vulkan compatibility layers...

July 19, 2020

On 7/11/2020 at 10:43 PM, DilliDallagio said:

Just a follow-up on current and future macOS support...

Per Inara Pey's blog LL still plans on supporting macOS. They need to evaluate how to transition the viewer from OpenGL given that Apple made announcements about deprecating OpenGL and making the move to power Macs with their own custom silicon.

It's going to be a close-to-impossible task... Unless Apple finally decides to adopt a Vulkan compatibility layer for their future ”Metal GPU”...

LL has recently added a Vulkan detection feature to the statistics sent by the viewer to their server (i.e. the info whether your system got support for Vulkan or not is sent together with the stats the viewer reports to the SL severs). Obviously the preliminary evaluation for the feasibility of a Vulkan port.

Transitioning from OpenGL to Vulkan would allow to make the viewer renderer multi-threaded and (at last) benefit from the many-cores modern CPUs, while retaining the compatibility with the current three platforms (Windows, Linux and x86-based macOS). Not sure it will be sufficient, however, to support ARM-based Macs if the latter cannot run Vulkan !

LL will also need to add support for ARM CPUs in the viewer code (i.e. providing Neon optimized maths for the viewer maths currently using SSE2). A lot of work for a small user base: much, much, much more work than supporting Linux, which LL already stopped (while trivial !), letting TPV developers do it in their place ! 🙄

July 15, 2020

6 hours ago, Kyrah Abattoir said:

Non-ALM rendering is getting canned in a near future last time I checked, and so is non-EEP lighting.

I don't see it ”canned” any time soon (and never in my viewer !)... You are probably confusing the possibility to disable ”basic shaders” (now removed from the EE renderer), but those would only affect pre-v2.1 OpenGL, and the WL renderer already could not render things correctly with basic shaders off.

As for deferred rendering (AKA ALM), I personally dislike it a lot and pretty much never use it myself: it makes everything look blurry and gloomy while non-deferred rendering is crisp and vibrant. Not to mention a lowered FPS rate in ALM, which becomes even more critical with the EE renderer...

July 12, 2020

14 minutes ago, Kyrah Abattoir said:

Policy on 3rd party viewers https://secondlife.com/corporate/tpv.php

Irrelevant quote... The only rule there is not to break shared contents for *others* (e.g. via things the viewer would transmit to the servers and that other viewers won't be able to render), not for changing how things look for yourself. 😝

In any case, your (I'm afraid, dictatorial) demand has already been rejected by LL, by design, since they always allowed custom environments, viewer side, be it with WL or EE...

End of discussion for me.

Forums

Blogs

Knowledge Base

Posts posted by Henri Beauchamp

Linden Lab

Tilia

Second Life

Connect With Us

Partner With Us