Henri Beauchamp
-
Posts
1,179 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Henri Beauchamp
-
-
TPVs do not use the same cache folders neither the same settings files than SL's viewer: each TPV uses its own private folders for caches and when sharing the same settings folder as SL's viewer (this is the case for my viewer), they use different settings file names.
There should be no interaction whatsoever between different viewer ”brands” related to cache and/or settings !
-
1
-
-
Perhaps are you trying to a simulator which is down in Aditi.
Try and log in in Morris: type this sim name in the input line associated with the combo where you select ”My Home”/”My last location”.
If this fails, have a look at the viewer log to try and figure out what is going wrong (look for HTTP error messages, warnings, etc).
You could also try with a different viewer: sometimes, inventory issues can also cause this sort of failure. The Cool VL Viewer will get you logged in, even with a bad inventory, and once done you can, in the ”Inventory” floater use the ”Consolidate/restore system folders” feature in the ”Folder” menu to repair what is ”broken” (usually a missing system folder or on the contrary duplicate system folders). Then you should be able to log in again with your usual viewer.
If all these fail, file a support ticket.
-
I am sorry to say that your motherboard looks much too weak on the VRM side (1) to run a much more powerful CPU than the one you got... A 9600K(F) might do it, but that's about it.
If you are ready to make a big jump and have the money for it, then I'd recommend going for an AM5 platform (a Ryzen 7700X would be perfect), which you will be able to upgrade without changing the motherboard for at least 3 more full years. Of course, it means replacing your DRAM too for DDR5 modules (go straight for 32GB in 2x16GB modules: 6000MT/s modules will do just fine and are not too expensive). You will also need a good CPU cooler.
For SL, I recommend (for the present and the future alike), to aim, at the strict minimum, for 12 virtual/SMT cores or 8 full/non SMT cores CPU (with 16 SMT cores preferred), and to avoid hybrid core architectures (Intel's Performance/Economy mix), since the risk is to see the viewer running most of the time on the E cores, performing much worst as a result. While the SL viewers are currently using a single thread for their render pipeline, the modern OpenGL graphics drivers can use a few more threads on their own, which can result in up to 3 SMT cores or 2 full cores being used by the viewer+driver to render, to which you must add the many threads SL viewers can now use for other tasks (some TPVs such as mine can even use several times the amount of threads used by SL's official viewer and occupy all the available CPU cores during rezzing). Also, in the future (one or two years from now), we will eventually get a multi-threaded Vulkan renderer, making multi-cores performances more important than what it might look like right now...
As for the SSD, a SATA 3 one will do just fine: NVME ones are over-rated, heat up a lot and are fragile, with a low endurance, and you won't see a difference at all in SL viewer performances. Note that SL uses a cache, with lots and lots of cache writes: those are toxic for the SSDs, so you need one with a very good endurance (2), or you could use a RAM disk for your SL viewer cache...
(1) Voltage regulator rails: only 4 seen on the picture, and likely only 3 for the CPU cores themselves, the 4th likely being for the iGPU, which you would not even use... And no heat sink on this motherboard's VRMs... Definitely not a gaming motherboard.
(2) QLC (4 bits per cell) and PLC (5 bits per cell) drives are to avoid at all price: way too fragile !... Try and get a MLC (2 bits per cell) or a TLC (3 bits per cell) drive: beware, some brands such as Samsung pretend their drive are MLC ones when they are actually TLC ones: they use the fact ”MLC” was a term invented back when TLC did not yet exist and means ”Multi Level Cell”, which could indeed apply to anything but SLC (Single Level Cell) drives, but should now only be used for 2 bits per cell drives.
-
1 hour ago, AmeliaJ08 said:
They need to be putting up actual minimum specifications with specific hardware examples, their minimum requirement of OpenGL 4.6 is fulfilled by pretty much everything since the dark ages.
It depends on the architecture and ”computer”... When using an ARM64 Single Board Computer (Raspberry Pi & Co, on which the Cool VL Viewer Linux aarch64 releases can run), then you are stuck with OpenGL 3.x and even then, not even fully debugged: most SBCs won't be able to do deferred rendering, for example, due to bugs in the current Mali GPU drivers (so, forget about PBR and even ALM: it's forward mode or nothing)... 😛
But yes, for x86_64 platforms, the minimum requirements as listed by LL are totally outdated and even plain silly (32 bits for Linux ?... 🤪 Nope, not any more !!!).
-
3
-
-
If you really want to compare the rendering speeds, you must use equivalent (and actually equal, whenever possible) settings, else you compare pears with apples.
There is no reflection in the old renderer, so you must disable the latter in the new one (PBR reflections tax a lot the CPU when enabled, and cause a large decrease in frame rates): in the PBR viewer, un-tick ”Screen space reflections”, set ”Reflection detail” to ”Static only” and ”Reflection coverage” to ”None”. On the other hand, PBR does not have proper water reflections, so be sure to set the old viewer water reflections to ”None (transparent)” (or ”Minimal” for some TPVs).
In LL's viewers, be careful with LOD settings (IIRC, they increased the maximum value for the slider corresponding to the RenderVolumeLODFactor, in the PBR viewer): check/set them from the debug settings to be sure (type ”LOD” in the search line, and set all settings it finds to the same value between viewers).
Yes, there is something fishy with the PBR renderer (my (wild) guess is that it has something to do with occlusions during rezzing) and sometimes, after login, it renders at a lower rate a scene that it renders faster after a TP away/back in. I can see this too in the Cool VL Viewer (which can render in all three forward, ALM/deferred and PBR modes) by not even moving but just toggling PBR off and then back on (with CTRL ALT P), after which the fps rate significantly increases.
The PBR viewer got quite a few optimizations in the underlying code (code that exists in both viewers), such as with the vertex buffers (now cached when possible), the VBO pools (with a much more efficient management code), and the avatars' matrix palettes uploading to the shaders (with the legacy code, they used to be uploaded pointlessly, sometimes several times per frame, while already uploaded). The Cool VL Viewer got all these optimizations backported, so they benefit all three rendering modes (forward/ALM/PBR) alike; if you want to measure the impact of the PBR shaders and render pipeline alone, this is a better viewer to perform your tests (and this is where you see the actual impact on old hardware).
All in all, and with all settings at equal values (i.e. with reflections off for PBR, and water reflections off for ALM/forward), the PBR renderer is not slower than the ALM one, and sometimes even faster than the latter on modern hardware. However, if you want to benefit from all the new shinies (pun intended), such as reflections, you will see lower frame rates, even on modern hardware. There is always a trade-off for new features: no free lunch !
As for the stuttering you mention, this is likely due to the new way the PBR viewer manages the VRAM usage for textures (LL's algorithm causes the VRAM to fill up to the brim, with vertex buffers and GL textures spilling out to the RAM as a result as soon as you turn the camera around and get new stuff rezzed while VRAM is already full); the Cool VL Viewer does not use this new code (but instead the old texture discard bias method with a rewritten and refined algorithm) and won't suffer from this kind of stuttering/freezes.
-
1
-
1
-
-
3 hours ago, Qie Niangao said:
(It appears that the Cool VL Viewer can choose which materials system is being applied, but I haven't found a way to actually see the Blinn-Phong materials on the surface while working with them if there's a PBR material already applied. To be honest, I can't really use that viewer's UI effectively, so untold magic may lie within and I'd never find it.)
You can see diffuse texture and legacy material maps rendered on the face by simply toggling off the PBR renderer, e.g with CTRL ALT P. For legacy materials, also make sure Deferred rendering/ALM is on, the toggle being CTRL ALT D.
Render modes toggling happens instantly (provided you already toggled it once in a former session or the current one, and your graphics driver is properly configured to cache compiled shaders), so you can do this a gazillion of times during edits, if needed. 😉
Also, you can apply all three (and in whatever order suits you): diffuse texture (used in forward mode), diffuse + normal/specular (used in ALM) and PBR material, all to the same face: this way, it will render just fine and as you intend it to render, with any viewer.
Finally, you can remove materials from the edited face(s) (both ALM and PBR) via the ”Reset materials” button, which would leave you with just the diffuse texture on the edited faces.
-
1
-
1
-
-
3 hours ago, Flea Yatsenko said:
If you have too much blue in the environment, that can be fixed with the sky settings.
By basically destroying the said settings, yes... E.g. you currently need to turn the ”blue horizon” one into a... pink horizon !
The problem is that the current shaders are totally bogus and account way too much for blue horizon/blue haze, and anything shiny and not shielded from the sky by a reflection probe will render blue (which is totally unrealistic: I never ever saw this happening in RL, even under a cloud less sky at midday !).
LL needs to fix this, but the time they take to fix it, there will be plenty of ”workarounds” in use in SL, among which hacked/destroyed EE settings that will need to be changed again once the fix is implemented !
LL really messed it up BIG TIME by pushing PBR to release while it was not even of beta quality and still full of render ”glitches” (to say the least), such as non-working water reflections, ugly and toonish blue-sky water bodies, broken semi-transparent legacy faces, etc, etc... 🙀
-
3
-
-
1 hour ago, MagdalenaBeatifica said:
If I did overclock anything, I didn't mean to. I wouldn't even know how to overclock, or underclock anything even if I wanted to.
If the problem truly stems from my GPU or VRAM being ”overclocked”, how do I unclock it?
If you did not overclock it, then it might be the sign of overheating (cleanup your computer fans and heat-sinks), or of a hardware failure.
1 hour ago, MagdalenaBeatifica said:Also, why do the streaks appear if I use YouTube on Google Chrome, or Opera GX, or any browser besides Safari?
Some browsers will use hardware acceleration (the GPU), and others not... Safari might not be using it (or not be configured to use it)...
-
1
-
-
Did you overclock your GPU or VRAM ?... This is typically what you would see when pushing frequencies a bit too high, but not quite high enough to crash it.
The fact it won't appear when using the GPU for something else (Youtube uses the GPU video decoder) might be due to the fact that, in this case, the GPU would throttle its frequency...
Also try and stress your GPU/VRAM with some test software, such as Furmark & Co and see if it reproduces the problem.
-
1 hour ago, jasons805 said:
So is there a way to get my lighting settings to look similer or will it look off? this Cool VL Viewer it will let me turn on ALM and AS?
The Cool VL Viewer currently can render in all three Extended Environment (EE) forward (legacy) mode, EE Advanced Lighting Model (ALM) deferred mode, and Physically Based Rendering (PBR) mode.
You can switch instantly between the three rendering modes (CTRL ALT P to toggle PBR on/off, CTRL ALT D to toggle Deferred/ALM on/off when not in PBR mode) and use the one that suits you for your current activity: forward is by far the best for sailing, flying and outdoor scenes in main land, ALM is best for legacy contents rendering with materials, such as clubs with lots of shinnies and venues with lots of avatars using legacy material on their meshes that would otherwise appear blueish with PBR, and PBR is required to properly render new shinnies using it (even though, the Cool VL Viewer also offers a hack to allow rendering a coarse approximation of PBR-only contents in legacy modes: see the ”Advanced” -> ”Rendering” -> ”Deferred rendering” menu and the explanatory post on the support forum).
As for EE settings, it defaults, in PBR mode, to NOT auto-adjust legacy settings to HDR tone mapping: the toggle for the latter setting is in the ”World” -> ”Environment settings” menu. It also uses fixed ”Midday” settings with clouds that do look as they used to in WL viewers (i.e. with a proper clouds scale) and do properly scroll with the wind, instead of staying still like in LL's bogus viewer (I reported that bug to LL countless times, but they never fixed the typo in their code and the consequently wrong setting value in their Midday EE settings in their inventory database 🙄 ).
-
2
-
-
33 minutes ago, Persephone Emerald said:
Second Life is hard on graphics cards. Be sure to lower your draw distance to around 320 m or lower, your LOD to around 2.0, and avatar complexity of other people's avatars to around 120,000 or lower.
Actually, the lighter the rendering load, and the hotter the GPU will become when the viewer is left running without limiting the frame rate (which can then skyrocket and since the consumed energy, measured in joules, will be about the same for each frame in a given scene, increasing the number of frames per second just heats thing up proportionally). E.g., in a sky box (where there is almost nothing to render) on a modern desktop PC, my viewer can render at up to a ludicrous 1500fps, and then the fans roar, the GPU hitting its maximum power consumption.
The true solution is to use the frame rate limiter (most TPVs got one).
When the viewer does not provide one such limiter (e.g. for the official viewer), you may enable VSync (which will sadly degrade overall performances and cause frame rate stuttering, making SL feel much less ”smooth”).
-
4
-
2
-
-
12 minutes ago, Silent Mistwalker said:
Something does change when rebooting the modem/router and that is the reason for rebooting the pc at the time. Sometimes that is what it takes for the pc to pick up on the new IP.
This won't change a thing either about how your traffic is routed between your PC and SL servers... So no, this too is useless, unless your ISP-provided router/Internet-box is crashed.
-
5 hours ago, Guku Aabye said:
The Third-party viewer I use is The Cool VL Viewer.
Did you enable the ”Advanced” -> ”Network” -> ”TP race workaround” feature ?
It helps a lot avoiding this issue.
Note also that restarting your PC won't change a thing: it is a race condition between the server and the viewer: LL is aware of it and working on it. See this thread for all the gory details (warning: highly technical stuff ahead !).
Depending on the routers between your PC and SL servers, things can be ”better or worst than usual”...
-
I actually think every topic is fine, as long as it is exposed by the original poster in a levelheaded way.
You can have opinions (including strong ones) while respecting the opinion of others...
Of course, if your text is sententious or disrespectful, you will likely start a flame war, but this is true for any topic. I suppose even a ”cutest cats” topic could turn into a flame war, this way: my cat is cutest than yours would be a good start ! 🤣
-
3
-
-
4 hours ago, animats said:
The same thing happens with Firestorm. But there's a workaround, around line 493 of llviewerassetstorage.cpp, to get past that. If the needed cap isn't known yet, it just uses the one from the region where the agent is.
This is indeed a trick ”we” use a lot, and not only for this capability...
And yes, it is utterly fragile and hacky: at some point, I reused this capability caching for server side baking (to work around another server bug which causes attachments to be unparented (derezzed) as a consequence of the departure region sending such a bogus unparenting message for the agent's own attachments), and while it first worked fine, it finally broke later on (details explained here)...
-
6 hours ago, animats said:
Black Dragon uses larger values than most other viewers.
I think you meant Cool VL Viewer (as I explained in the above post)... You keep confusing the two viewers names (you already did in your Canny issue), which is strange... 🤪
-
CTRL ALT SHIFT H prints ”Hippos!” in chat with almost all viewers (not mine, since I reused that shortcut for something more useful)... 🤪
-
3
-
-
16 minutes ago, Bree Giffen said:
My current cover is that I live in New England with a labrador named Fluffy.
I myself live on Mars with a Buggalo named Beetlejuice. 🤣
-
1
-
-
19 hours ago, SpiritSparrow Skydancer said:
Isn’t it the MAC address you should be worried about?
The MAC address is not part of the data transmitted via IP packets. The MAC address is only relevant to neighbours (i.e. only the last router in the route to the the site you are connecting to would see its MAC address revealed to the computer serving that site), via the ARP mechanism (used to build routing tables from one router to its neighbours).
19 hours ago, SpiritSparrow Skydancer said:And if you have enabled network sharing?
If you mean Netbios windoze traffic, it would be blocked by the first router or firewall on the outbound route to Internet (this is for use on a local network only and is not a routable protocol, unless you purposely encapsulate it between two poles).
If you mean SMB, and even though it can use TCP/IP, here again most firewalls (the ones that are properly configured, at least) will block it.
In any case, it won't reveal your MAC address either beyond your immediate neighbouring router (which belongs to your ISP).
As for SL's usage of your MAC address, it is transmitted among the viewer stats by the viewer (over an HTTPS connection), but no one else than SL admins can see it either.
-
1
-
-
10 minutes ago, Aiyumei said:
Best they can get is the public IP address which nowadays is NOT the real IP address that connects directly to you but rather the one your ISP provides. A restart of your router or server maintenance from their side often leads to change.
See my post above: this is not always the case.
First, IPv6 IPs are normally, when provided by your ISP, ”life-time” ones (i.e. they stay affected to you for as long as you stay with this ISP); they usually come as a (very large) block of IPs so that every device on your local network can get one affected to it. Granted, IPv6 is not used by SL, but it may be used by the media servers which URL is transmitted by SL contents or scripts, so those servers can see your IPv6 when you have one.
Second, with some ISPs, you may ask for a static IPv4 (useful if your run your own server(s) at home). In this case, your IP is also always the same until you change your ISP.
-
1
-
-
Like for all viewers, via the ”MenuBar*BgColor” entries (there are several, the two of interest to normal users being ”MenuBarBgColor” for the main grid and ”MenuNonProductionBgColor” for the beta grid), in the colors.xml file (or colors_base.xml for v1 viewers) present in the folder for the skin you are using (e.g. skins/default/colors.xml for the default skin, in the viewer installation folder).
It is normally also possible to override that colors.xml file instead of modifying the one in the installation directory (which would get overwritten on viewer update), by copying it into the application local data directory and modifying it to your heart's comptempt, but the exact override file location depends on the viewer and OS (ask in Firestorm's support group)...
-
1 hour ago, Benson Gravois said:
I asked someone about this and they told me they knew how to take the “key” and find my address right to my doorstep? Is this all true?
This is total bullsh*t. There is no publicly available link whatsoever between the avatar key (which is a randomly generated UUID that got created when you registered the avatar) and your RL home location.
However: like any other service on Internet, people can try and grab your IP via various means. When they do not have access to the servers (which would be the case for anyone without admin privilege on SL servers), they can do so by tricking you into connecting with your computer to a server they own or have admin access to. In SL, this can be done via music streams and parcel or shared media; if they set an URL for those that point to their server, they can correlate your avatar arrival time on, and departure time from their parcel with the IP of people connecting to their server, via the server logs. To defeat such attempts, you can use a viewer with a proper ”media filter” feature: those viewers will present you with a permission dialog every time they get a request to connect to a media server (music streams, parcel and shared media alike) and you would then be in the position to make an informed choice about whether or not you grant permission to connect... Another trick would be to send an URL in IM to you (this could be sent by one of their scripts too) to a server they own/have access to, and then see what IP is connecting on the said server.
Also: Be careful about what info you give up in your profile. It might sound obvious, but some people can give up a lot of details that are even more significant than their IP to try and spot their RL location. Of course, giving an URL to a server you are running at home (on your own server) in your profile would instantly give up your IP too...
As for correlating your IP to your RL home location, it is not even possible in many cases: you can perfectly disable IPv6 on your computer to avoid connecting to music streams, and parcel or shared media servers via IPv6 (when your ISP provides one, it is normally attributed to you for as long as you keep using this ISP services). It then usually makes things much more difficult for people trying to track you, because most of the time your IPv4 IP is attributed randomly (and each time you restart your ISP box/router at home) from a pool your ISP owns and uses for all its customers, the said IPs not pointing to anyone's address in particular, but just to a town where your ISP got its Internet-facing router. Even with static IPv4s (some ISPs still can provide those to you on your demand, for free or as a paying option), and given ISPs are all migrating to IPv6, it is likely that your static IP (v4) will actually be one of those old pools of dynamically-allocated IPs, and routed (via IPv6-encapsulated IPv4 traffic) to, here again, a public facing router that is not even in your own town/city, but simply where your ISP got all its routers...
-
4
-
-
3 hours ago, Qie Niangao said:
I don't know if we should expect these ever to get repaired
The problem is that, for now, LL did not repair legacy contents rendering, at the PBR viewer level, and instead created some hacked ”mid day” setting you can set in the viewer, meaning any legacy contents rendered with any other existing EE setting (which includes main land, but also all other current settings applied to all other type of lands) looks broken, with an ugly blueish hue.
We need to petition LL to fix the renderer, and have it render legacy contents with legacy EE settings !
-
38 minutes ago, animats said:
SL's real asset is its user base
And its existing contents, created by the said user base. The amount of assets in SL is enormous (even if half of it is crap), and no other virtual world can compete with that any more...
The drawback is that each time LL wants to improve SL, they must take into account legacy contents to avoid breaking it at all price (and I wish they had been more careful with PBR before pushing the latter to release: it still does not render legacy contents properly, for now). This of course ”holds back” SL quite a bit and causes added complexity to the render engine, database, scripting engine, etc...
But like you said, starting from scratch with state of the art renderer and contents, like LL tried to do with Sansar, is bound to failure: it would be a bottomless money sink for the company before it would even reach a tenth of what SL is today.
-
2
-
Facebook
Instagram
Twitter
YouTube
Flickr
Second Life Beta not working?
in Second Life Server
Posted
The limit for SL passwords is 16 characters, not 12. If you change your password, there will be a delay (up to 24 hours, IIRC) before it gets propagated to the SL beta grid (Aditi), so you won't be able to log in to Aditi with the new password before the change has propagated there...