Henri Beauchamp
-
Posts
1,180 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Henri Beauchamp
-
-
5 minutes ago, Linnrenate Crosby said:
Now you do the same *****ing ting with PBR which i suspect one need a very powerful Pc/Mac to use, no doubt equipped with at least 64 gb memory and a graphics card that will cost a month's salary or more.
This is my opinion that you just ***** up sl and make it worse, when so high hardware requirements you will for sure see less new users joining SL. To me, well i think within the summer of 2024 i'm gone for good
I warned them that it would kill the experience for people with ”weak” hardware... To their defense, LL's developers did try hard to optimize the renderer, but this is totally insufficient for ”old” hardware, like I anticipated (they even had to turn off HPDi for macOS, so bad are the frame rates with it).
The good news is that, since my plea to preserve at least the forward renderer got ignored, I decided to implement a dual-renderer in the Cool VL Viewer (currently implemented in the v1.31.0 branch) :you can still use the EE renderer (in both forward and deferred (AKA ALM) modes) or the new PBR renderer, to your heart's contempt, and with just the ticking of a check box in the Graphics preferences (the switching happens in real time: no need to restart the viewer).
I intend to keep maintaining this dual-renderer for as long as the PBR renderer will not be fixed (many graphics glitches still exist in it despite the (hasted) push to the ”release” status) and made faster... Or until LL comes up with a Vulkan renderer (whichever will occur first).
This means you can keep enjoying SL for at least a little more time... 😉
-
This is Cloudflare's fault again (this thing is a total nuisance)... However it only repeats the check once for me, then allows redirection to the website.
Usual suspect for failures with Cloudflare are:
- Disabled Javascript in you browser.
- Disabled Cookies in you browser.
- Unknown ”User agent” sent/advertized by your browser to the site. This sadly also badly impacts many ”confidential” (rarely used) forks of common browsers.
-
3
-
1
-
8 hours ago, sarcmp said:
I get the same error message and I can log into SL with browser, get access to my account but not with any viewer, Firestorm or Second Life viewer. Also, I was able to create a new account and log in with firestorm without a problem. I submitted a trouble ticket and followed instructions but to no avail. It is just one account that is being blocked it seems.
6 hours ago, Monty Linden said:This and the rest point in the direction of an inventory issue. Keep working with support and supply the requested information. (E.g. The SecondLife.log from a bad session.)
@sarcmp You could also try and log in with the affected account using the Cool VL Viewer; its inventory code is much more robust to ”unsuspected” issues and won't bar you from logging in. After login you could then try and repair your inventory: from the ”Inventory” floater, ”Folders” menu, choose ”Consolidate/restore system folders”, then log out and retry a login with other viewers.
Note that the new inventory thumbnail code as implemented by LL (or more exactly the updates to the AISv3 inventory protocol that accompanied it) can result in this sort of issue as a missing system folder causing failures to log in (because they do not use any more the legacy UDP folder creation message that was synchronous and could solve missing folders issue by creating them in a ”fire and forget” way, instead of needing a callback after creation, callback that cannot be honoured during the login process).
-
-
25 minutes ago, Gavin Hird said:
Yet you keep plugging at it 😉
Can't help it: I'm of the ”plug and play” type... 😛
-
1
-
-
48 minutes ago, Gavin Hird said:
if you want to be on their platforms
Good news: I don't ! 😜
-
1
-
1
-
-
34 minutes ago, Gavin Hird said:
Apple ditched OpenGL because they don't want any dependency of Chronos in their hardware and software development
Another stupid stance by Apple... Not the first, sadly, and likely not the last such stupid stance either, dishearteningly...
-
1 hour ago, animats said:
I suspect it involves this CrossedRegion - CompleteAgentMovement sequence. That three way handshake between losing sim, gaining sim, and viewer seems to be on the critical path for some sim-side events.
Likely a race condition between the two regions you are crossing to when in a corner and moving to the opposite region on the diagonal. As I guess it, the race could be as follow when, e.g. you are in region A and you walk NE to region B that you want to reach, and there's region C, North of A and West of B: you cross the corner and shortly get into C and from there cross to B. Normally, you would get:
- CrossedRegion sent by departure region A with destination region C.
- Region A hands over to C (server to server messaging).
- CompleteAgentMovement sent by the viewer for region C.
- CrossedRegion sent by transit region C with destination region B.
- Region C hands over to B (server to server messaging).
- CompleteAgentMovement sent by the viewer for region B.
But, what may happen, due to variable region ”ping” time with servers and reactivity (depending on their load), and the moment they are when receiving the messages during their frame (start of frame: message taken into account immediately, middle of frame and message processing delayed to next frame), you could actually get:
- CrossedRegion sent by departure region A with destination region C.
- Region A hands over to C.
- CompleteAgentMovement sent by the viewer for region C.
- CrossedRegion sent by transit region C with destination region B.
- Region C busy re-serializing the agent data it just de-serialized but must still update before re-sending to next region, meaning likely a one frame delay.
- CompleteAgentMovement sent by the viewer for region B. Message rejected by region B, since no handover was received for this agent yet...
- Region C hands over to B (finally, but after the viewer sent its own message !).
- Region B confused: where's that agent ?... Why did not I get its CompleteAgentMovement ?
Of course, this is just a wild guess... But it could be fun to try and work around this guessed race condition to see if the hypothesis is correct. Viewer-side, we could try two things, when two region border crossings happen in a row:
- Delay the second CompleteAgentMovement a little bit (say, by 250ms, or a ”ping” delay + one region frame (20ms)).
- Send a second CompleteAgentMovement to B, if not ”hearing” from it after a couple seconds...
-
5 hours ago, Erik Kundiman said:
So much for the efforts to get a running native build, then.. 🥲
The effort is not vain, by far: even though Rosetta does a good job running x86_64 apps at decent speed, it cannot perform as good, when it translates x86_64 optimized code into aarch64 code, as what a proper optimizing compiler would obtain when compiling from sources into aarch64 binary...
For the SL viewers, however, and since they use OpenGL, and since the latter is implemented like sh*t by Apple, the bottleneck at the GPU level is what drives their performances, far more than the C++ code optimization level.
-
1
-
-
1 hour ago, Gavin Hird said:
OpenGL does not run as emulation.
It does, sort of, for Apple Mx, since those GPUs were only designed to run Metal, with an entirely different architecture as what a GPU designed for OpenGL can do. You end up with ”translated” OpenGL primitives into ones that can be implemented with Apple's custom GPU hardware architecture...
OpenGL has always been implemented like utter sh*t by Apple, resulting in extremely poor performances for OpenGL apps on Apple hardware, while the latter usually got quite capable CPUs and GPUs...
Beside, and AFAIK, there is not even a native aarch64 OpenGL driver for Mx... But I could be wrong here.
-
10 hours ago, Erik Kundiman said:
I happen to have got a friend with an M1 & 8GB, who has tested a native macOS arm64 build for me
I am curious about how he got a native macOS ARM build (and how truly ”native” too)... The viewer contains SSE source-level code that can only be ”translated”/adapted via specific libraries (such as sse2neon), and he would have had to rebuild for ARM64 all the third party libraries used by the viewer as well... This is totally doable, and a couple contributors to my viewer and myself did it (for Linux only, so far). But it is not trivial either.
However, AFAIK (but I am not a Mac specialist, by far: I do not even own a Mac and just toyed with Hackintosh x86_64 virtual machines, which cannot even run a viewer, but can still build it), there is no access to the OpenGL API for native ARM64 macOS builds, making it even more complex a task to compile a truly native SL viewer for macOS Silicon... So this gets me even more curious/perplex... 🤔
10 hours ago, Erik Kundiman said:The thing is, he said running the native one didn't feel any faster than running its x86-64 counterpart emulated.
This is because, under ARM64 macOS, the bottleneck will be at the OpenGL emulation level, not at the C++ code one (be it ran from native aarch64 binary, or ”translated” via Rosetta from x86_64 to aarch64).
Note also that Rosetta is not exactly an emulator: it is a dynamic binary code translator, taking a x86_64 piece of code it runs for the first time, translating it into its aarch64 (ARM64) counterpart, and then running the said translation for any further occurrence of that same piece of code: this is extremely efficient for speed (waaaaay less for memory consumption) after the first run (and you do not really care about the high inefficiency of the first translation run for pieces of code that will never be ran again). The same kind of translator exists under Linux (e.g. Box86 and Box64).
-
2
-
-
2 hours ago, gwynchisholm said:
I’m saying is installing from usb on this system is a pain.
Try installing from a DVD, then (it's usually what I do anyway).
-
16 minutes ago, gwynchisholm said:
when it comes to booting from usb
Wait... USB is just for installation/upgrading. Booting and running an OS from it is too slow (and prone to USB memory failures/corruptions: these prmitive and cheap NAND USB memory chips do not have a high endurance neither a ”clever” controller to spread writes over the whole memory and swap faulty blocks with reserved ones, like what happens on SSDs) !
Just install a dual (or triple: Linux +Win7 +Win1x) boot on your hard disk or SSD. Linux can do this just fine for you.
-
11 hours ago, gwynchisholm said:
Well I think you’re gonna have to just take my word on this in the short term. I’ve been fighting trying to install windows 10 on a pre uefi system with usb 2.0 for too long
Did you try Rufus ?
FYI, my oldest still running PC is based on a Core2 Quad Q6600 (OCed @3.4GHz) with 8GB RAM (and a purely BIOS, non-UEFI motherboard) and a GTX 460, and it does run Windoze 11 (in excess of Linux and Win7 which both run SL viewers much better and faster than Win11, with a blatant (+20% fps) advantage under Linux)...
-
Here you go: for its 16th birthday, official Cool VL Viewer ARM64 Linux builds.
Note: for such a build to properly run on an SBC, you will need proper Panfork support for your GPU (if it shows ”LLVMPIPE” in the About floater, you do not have it and it would be unusable since waaaay too slow).
-
2
-
1
-
-
4 hours ago, animats said:
No effect on 60 second delay.
I still suspect a timeout due to an unreplied server message, here... If I were you, I would log all server messages and see whether my viewer does reply all of them.
-
14 minutes ago, animats said:
Yes. Put that in last week. No effect.
My logs are very close to your logs in terms of what messages are sent. What's in the messages may be an issue somewhere.
Or of a missing reply to some other server message, causing the said server to ”pause” messaging to your viewer, waiting for it to reply before finally timing out on the latter and continuing with the rest of the queued messages...
14 minutes ago, animats said:I just noticed that I'm not sending AgentThrottle. It would make sense that the default throttle settings might be low. I'll implement that next. This might be some throttling mechanism left over from the assets over UDP era.
Yes, and it is still in use (even though all the asset and texture reserved bandwidth it accounts for should now be removed both viewer and server sides... A work for @Monty Linden ? 😜); this also means (and contrarily to an SL urban legend about supposed bad effects of a large UDP bandwidth setting) that you can now use a much larger bandwidth number (only part of it will be used for objects data, anims start/stop, etc, anyway). I personally use 32Mbps as a setting (I'm on an FTTH link) in the Cool VL Viewer (which defaults at 8Mbps).
-
1
-
-
What viewer are you using ?... Why is is so difficult for people to give proper clues for the problem they encounter ? 🤣
I suppose (wild guess, by lack of information), that you viewer is not PBR-enabled and did not recognize the new Materials folder as a ”valid” system folder.
Make sure you are using a PBR-enabled viewer if you want to test PBR/GLTF materials.
There are currently four of them (by order of appearance/availability):
- LL's PBR RC viewer.
- Alchemy beta viewer.
- Cool VL Viewer, experimental branch (v1.31.0).
- Firestorm PBR alpha viewer.
-
10 hours ago, animats said:
What am I doing differently
Just a wild guess, but are you replying to ”StartPingCheck” with ”CompletePingCheck” too ?...
-
Went there, all four regions come up and everything rezzes in less than 20s. Here is the relevant log info with milliseconds accurate time stamps and UDP messages debugging enabled (repeated, irrelevant messages removed for clarity); maybe you will find what is missing in your viewer/servers communications....
But you could learn a lot by yourself via the use of the Cool VL Viewer logging features (that's how I managed to make threaded object cache reads work flawlessly):
- Get the viewer, launch it, log in and go to the place you want in SL.
- Disable ”Advanced” -> ”Caches” -> ”Threaded object cache reads” (this way the viewer will behave like LL's and other TPVs and the threads delay won't risk polluting the messages sequence).
- Enable ”Advanced” -> ”Consoles” -> ”Precise timestamps in log file”.
- Use the mini-map to help setting the draw distance so that you can see only the four sims in the FOV cone (192m did it for me at the approximate position of your screen shot).
- Log off.
- Relaunch the viewer, and at the login screen use ”Advanced” -> ”Debug tags”, and in the floater that opens, scroll down and check ”Messaging” in the list; you may also enable ”EventPoll” if you are interested in those in excess of what is already normally logged at INFO level. Close the floater. (*)
- Log in, wait for everything to rez and your avatar to bake, then log off.
- The CoolVLViewer.log will contain all the detailed login and rezzing sequences, with detailed log messages.
(*) Note: this floater allows to enable/disable DEBUG level messages in real time; once logged in there is also an ”Advanced” -> ”Consoles” -> ”Allow DEBUG messages” option (automatically checked when you did enable a debug tag), to disable/re-enable at once all the debug messages corresponding to the configured tag(s) when you deem appropriate, so to avoid too much/irrelevant spam in the log file (and console).
-
1
-
4 hours ago, Kathrine Jansma said:
Thats slightly optimistic. Not even Linus Torvalds managed to do that. Basically it is usually true if you compile yourself, but once you start shipping binary packages, it becomes a mess.
That said, the mainstream distros usually work okay, when you stay away from very old or very new versions.
Library versions are not the only problem...
For example, a TPV I will not name by charity, decided that it was a good idea to rely on a systemd-specific library, meaning you cannot use that viewer at all on systemd-free Linux distros...
Other issues could arise from the usage of specific toolkits (e.g. a specific GTK or QT version, or xdg-desktop-portal for the file selector), here again, complicating things if you do not have the corresponding toolkit installed on your system...
For the Cool VL Viewer, I have been extra careful to avoid such silly dependencies, making it compatible with all (not too old) distros.
-
2 hours ago, Qie Niangao said:
The Firestorm PBR alpha viewer is an exception in that they're still working on the feature with some flexibility (or at least that was true when it first came out), but very often stuff is frozen long before any non-Linden viewer takes the code.
You should try the Cool VL Viewer more often... I lost the count of how many times I have been releasing experimental branches with LL's RC viewers (or even project viewers, i.e. before the RC stage) code backported (and debugged by me, meaning less bugs than in LL's viewer !)...
The current experimental branch implements PBR (while also still being able to render in ALM and forward modes, meaning I implemented a dual renderer), and even the stable branch can do Puppetry (something no other TPV can do, and LL put on hold)...
-
You do not give the version of macOS running on it, and this is the determining factor.
Newer viewer builds require macOS 10.13 (High Sierra) or better. Your iMac13,1 is apparently (from a quick web search) capable of running 10.15 (Catalina), so if you are running an older macOS, you should be able to upgrade and run SL viewers again.
-
A couple other places in SL (main grid, with heavy mesh and texture contents) I do visit for stress-testing sessions (with 256 and 512m draw distances):
And of course, crowded clubs are also great for testing.
I also use a lot YavaScript pod tours (base station, but there are many others: click a pod and get the ”Pod tour information” notecard for a full list), which are great for stress-testing the texture fetcher, the object cache, the mesh repository, etc (especially at 250% speed, but make sure to slow down on corner sim crossings 😛 !).
-
2
-
Facebook
Instagram
Twitter
YouTube
Flickr
Second Life Viewer 7.0.1.6894459864 - Lighting Issue?
in Second Life Viewer
Posted · Edited by Henri Beauchamp
Try setting ”RenderSkyAutoAdjustHDRScale” to 1.0 instead of 2.0...
Yup. Please see BUG-234564 and this post of mine about it.
For these reasons, I did not yet port the culprit commit/changes to the Cool VL Viewer...