Henri Beauchamp
-
Posts
1,188 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Henri Beauchamp
-
-
27 minutes ago, Gabriele Graves said:
It's a testament to how crappy the LL viewer is. Imagine if every time a web browser failed to connect you had to restart the browser.
You obviously not have the slightest idea about how a web browser and a viewer are programmed...
For a start, the first is non-real-time (and will retry connections as need be: but you still can get 404 or 502 errors, and no way to view the web page, having no other choice than closing the tab), the second is real time and must exchange data with the server so that everyone sees the same thing in the sim.
It's like comparing apples and cucumbers... Sure, they are both of the vegetal kind and are both comestible... 🤣
And no, it's not the viewer fault: it's a problem with the TP protocol itself (which lacks a proper handshaking between the departure sim server, the viewer and the arrival sim server).
-
1 hour ago, Paul Hexem said:
”Technically” not a crash, but when the only possible option is the viewer shutting down... That's a crash.
No, that's a disconnection (and the first dialog is not even that: you can still retry a TP, preferably from another sim since the failure is likely a server to server communication issue); the viewer is still running (normally in the first case, disconnected in the second).
Sorry, but it you make up your own dictionary, changing the meaning of the words, don't be surprised if people find your stance nonsensical.
-
Since Havok is not Open Source, the Cool VL Viewer is using HACD (the oldest version from 2011, since the newer one does not perform as good): amusingly, the results are actually much better than Havok's despite the lack of a ”simplification” step...
-
4 hours ago, Sam1 Bellisserian said:
For that one person who doesn't like it the other 199 might so is it really fair to ask them to take it out?
There are already settings such as ”show in search” to preserve the privacy of people minding it: I do not see why LL won't be able to add a similar option for the displaying of the account type (since this info is transmitted by the servers, it is fully under LL's control, just like for ”show in search”). Then, people would be left a choice whether to opt out or not.
Since this info is totally irrelevant to how people use SL (unlike the ”Show in search” option which is yet already implemented), I do not see how it would hurt to offer every resident (not just the lifetime Premium Plus holders, but also Premium, Premium Plus, etc) a choice in what info about them is disclosed to other SLers.
-
3
-
-
One of the few ”features” I do not plan to backport to the Cool VL Viewer (just ”Payment info used” displayed in the profiles, but nothing about the account type).
At the very least, an option in your account web page (akin to the ”email settings” page) should allow you to opt out this ”feature”...
@Fionalein if I were you, I'd open a JIRA issue for this.
-
3
-
1
-
-
Apparently, they just reverted RC BlueSteel to the former version (my home region just got restarted)... Bug in new BlueSteel ?
-
9 hours ago, Jackson Redstar said:
If I remember correctly, in the old days there used to be a refresh scene/world on the viewer. Since most everything is server side now I wonder why there couldn't be a refresh/reload scene. But I am sure smarter people than me have thought of that and there are prob good reasons why it wouldn't work. Or even a right click on a avi and select a refetch/reload option to get the viewer to to re fetch the data for that avi. In most cases this is just an annoyance, but when filming the area with all these half baked avis, it becomes a real hassle
This exists in the Cool VL Viewer.
You can right click on an avatar and select in the pie menu ”More>” and ”Refresh” to get the viewer to force-reload all textures and rigged meshes for that avatar. However it won't help when a mesh or texture fails to download at all (e.g. with 404 error due to the corresponding asset gone missing on the CDN server), or for avatars which UDP appearance message packets are incomplete (usually due to a missing mandatory wearable, or something in that vein: this is logged by the viewer when it happens).
There is also the ”Refresh visibility of objects” (ALT SHIFT R) feature, to make objects failing to render pop back up into existence; this feature is also auto-triggered on login and on sim change, since these often cause such ”missing objects” due to a race condition between the server interest list updates, the viewer FOV updates (the interest list contents sent by the server depends on the FOV sent by the viewer), and the render pipeline spatial groups rebuilds.
In the same vein, you can force-reload all textures for an object by selecting it (right click or edit) and using CTRL SHIFT U: this may help with blurry or corrupted textures.
-
1
-
-
17 hours ago, NiranV Dean said:
Another issue is that crashing will often lose you your settings and changes (although technically it shouldn't since settings are immediately written periodically, often times even immediately on change... so why the Viewer reverts it (and how) is beyond me...)
For attachments, this is because any change to them is only committed to the inventory database when you either: detach them, TP away, cross a sim border, or logout cleanly.
Note that I won't complain the least about this state of affair, because it got the very nice corollary to permit ”undoing” any changes to your attachments when you edit them and badly mess-up; in this case, simply copy the attached item in your inventory and paste it (LL forbids copy of attachments in their own viewer, but AFAIK, all TPVs allow it): the pasted item will have all the changes ”reverted” (actually unsaved) and you can then detach and delete the crippled item, and wear the ”reverted” copy instead...
However, this means that in case of a real crash (and most often on spurious disconnections as well), your attachments state changes will be unsaved and you will find them back in the state they used to be on the last login, wearing, successful TP, or sim border crossing (whichever occurred last).
On spurious disconnection I however noticed that, on next login, you often find your avatar moved back to the last successful login/TP sim, instead of inside the sim where you got logged out: I would definitely consider this a bug in LL's avatar ”presence” management/tracking, and unlike the above ”attachment reversal bug/feature”, I find it an annoyance (especially if you changed your avatar's outfit in the mean time, and the latter does not match the maturity level of the sim where you get logged back in).
17 hours ago, NiranV Dean said:which just happened to result in an immediate crash due to illegal read/write attempts to now stale data.
Well, a viewer should never crash on bogus/stale data reading, even during a login after a spurious disconnection... Even in this case, you should understand why the crash happened and fix it (which is, of course, much harder than for crashes happening in a simple, reproducible way)...
Over the 16 years I thoroughly polished LL's code to make it ”mine”, I took great care, in my viewer, to sanitize every place where such a bogus data processing could lead to a crash. My principle is that a ”release quality” software should simply never, ever crash: if something unexpected happens, you must, as a programmer, still find a safe and sane path to handle the issue and minimize the consequences (e.g., for the viewer, a render glitch would be acceptable, as long as there is a suitable warning logged, so that this ”unexpected” issue can be further diagnosed and dealt with properly, and also as long as the viewer does not crash but keeps ”happily” chugging along). If you are curious enough, try this command line on my viewer sources:
grep -ri Paranoia linden/indra/* | wc -lThis will currently report 513 matching sites for the release branch, and 542 for the experimental (PBR+EE) branch... These sites are all the places where I added a check to avoid a crash and provided a suitable fallback path for ”unexpected” situations, and for which I added a ”// Paranoia” comment to them (but I did not always added a comment, especially 5+ years ago, before I started systematizing those)...
-
2
-
-
22 hours ago, Fionalein said:
Only thing you can do is walk over to Amazon and kick the server rack.
I'd rather kick some asses at Amazon... But it's just me. 😜
-
2
-
-
2 hours ago, Katherine Heartsong said:
And yet, this is what people who play immersive, realistic looking 3D games want and expect these days.
And I am not against this or denying it.
However, what I am saying is that, to achieve the AAA-games-like quality they expect, you just cannot use the same techniques as the ones used in those games, because of the specific constraints of SL (or rather lack thereof, since you can pretty much upload anything into SL and pile it in an infinite number of ways around the corners of a sim).
2 hours ago, Katherine Heartsong said:we can not keep getting further and further behind the curve on how SL looks if we want to attract and retain new users. The tech needs updating, but how?
One word: Vulkan.
Once the renderer converted to use Vulkan, many more things will be possible, especially related to parallel (threaded) rendering, like I suggested in my above post...
Apparently (from what I understood based on what we were told during the SL20B meetings), LL also started to implement some on-the-fly conversion techniques so to be able to render SL on mobiles: this could also benefit the ”standard” viewer. For example, I'd envision some on-the-fly mesh optimization, so that the viewers (mobile and desktop alike) could render simpler objects (which could then be used, at least when at far distance, in the desktop viewer)...
-
1 hour ago, Gabriele Graves said:
Yet these disconnections still happen. Here's the kicker. It has been a lot better in the past. I remember a time a few years ago when LL were working on region crossings that it seemed from my experience that TP disconnects were a thing of the past and were no longer happening. Gradually over time they've become more prevalent for me again.
I think it could be better. It has been better.
+1
Not sure it is actually related, but it looks to me like TPs were way more reliable before the migration to AWS servers...
-
5
-
-
3 hours ago, animats said:
This discussion is all about what to draw in the distance that won't slow things down much.
Depending on how your viewer is coded and whether it can do true multi-threaded rendering or not, instead of blurring distant objects or using 2D impostors, I'd push their rendering to a low frame rate rendering thread. It would be fine to render a far building, say, once every second, and reuse the result in the final, ”real time” render.
You could vary the threaded frame rates depending on how close objects are and how fast you are getting closer or farther to them as the camera moves around...
You could use several such threads too, e.g. one for 128m to 256m at 5fps (with fully textured objects), one for 256m to 512m at 2fps (with very low texture LOD) and one for 512m to 1024m (no texture, just a suitable ”averaged” color) at 1fps...
QuoteI've commented on GTA V's backgrounds.
IMHO, you are too much geared towards reproducing what AAA games are doing to solve their own issues within their own constraints.
You perfectly know that SL is not an AAA game with pre-calculated and pre-rendered assets, very limited camera ”paths”, limited environment settings, etc... The solutions for SL cannot be the ones used in AAA games, even if the latter can be inspiring to find more suitable algorithms.
What you suggest would imply that LL puts into place specific servers for pre-rendering impostors, backgrounds, etc: while it would be doable, I do not see LL doing such a thing, since it would cost a lot in term of server power (and here, we are speaking about servers capable to do 3D rendering, unlike what are SL's server right now): way too costly, especially now, with AWS as the servers host...
-
2
-
-
28 minutes ago, animats said:
If they look like High=2000, Lowest=2
Lowest = 2 is pretty much a ”requirement”, because it allows to lower dramatically the LI (and the upload cost with it)... I'd blame LL for a poor algorithm with mesh LI scaling.
This said, a mesh with three well designed higher LODs and a 2 triangles lowest LOD will still rez just fine at all but very far distances (where it will pretty much vanish): the lowest LOD is rarely ever seen rendered, especially seeing how much we must push the RenderLODFactor setting to get truly crappy meshes to render properly at all.
-
1 hour ago, animats said:
Good comments.
I'm writing this from the viewpoint of a third party viewer developer who has to deal with existing SL content.
First, looking down from that tower in New Babbage is one of the hardest cases in Second Life. There's a whole city down there, with much detail, and you can see most of it from the Albatross's docking tower. At street level, most objects are hidden (occluded) by buildings. So let's look at what current viewers can do.
LOD factor 3, NVidia 3070 with 8 GB, 32 GB RAM, gigabyte fiber networking. A good gamer PC, more than most SL users have. About US$2000.
Similar hardware here (Ryzen 7900X, RTX 3070), also fiber (but Babbage is definitely not a challenge for the network), graphics pushed to the max excepted no shadows and water reflections set to terrain and trees ”only”, with additional 2.0x multiplier on mesh LODs (i.e LOD=3 for all but mesh, LOD=6 for meshes) and I get 50+ fps at 1024m draw distance with the Cool VL Viewer (current release), and rezzed pretty fast: with a cleared cache (i.e. not ”cheating” and fetching everything from the network), half a minute for 256m, and needed barely two minutes more after increasing DD to 1024m...
But better than words, here is a video.
Frankly, Babbage is not a challenge to render...
Note: you will notice I took great care to use almost exactly the same FOV as yours, so that we render the same objects...
-
1 hour ago, Love Zhaoying said:
Conceptually, in RL you get a blur when things are far away.
You are confusing blur caused/introduced by optical defects/imperfections (such as the limited depth of field of a camera lens) with the eye resolution (the minium angle between two objects/points for the eye to distinguish them apart).
The resolution of the human eye allows to tell two objects 30cm apart at 1km. If you see them blurred, you need glasses (at my age, I alas do need them, but with them I see just as well in the distance as when I was 30 years younger).
In SL, we are speaking about 512m max draw distance... There should simply be no blur at all on rendered objects larger than 15cm. Period.
1 hour ago, Kathrine Jansma said:You may also get blur like effects due to air movements (e.g. heated air over asphalt roads), dust, fog and other particles in the air that cause light to bend.
This is a different (environmental) aspect, which is possible to simulate in SL already (via Extended Environment settings, particles, etc), but should not be ”hard-coded” in the renderer...
1 hour ago, Kathrine Jansma said:1) Speed of rezzing/loading the whole static scene.
After all, even with 256m draw distance, the viewer needs to ingest a huge amount of textures and meshes to render the full view. Thats okay if i am stationary and just want to gaze into the distance. But depending on network speeds (e.g. ”just” 100 MBit/s) it might take some time to flush all that data down the pipe for rendering, so some intelligent z-depth sorting and blur effect might help to get a nicer effect while loading happens.
An acceptable kind of ”blur” would be to use lower resolution textures for distant (>256m) objects (that kind of blur won't affect the least the contours of the objects, which play a big role in how ”sharp” an image appears to the eye). The viewer is already doing it via texture LODs, but maybe pushing down one lower LOD for far textures won't be too noticeable: then you would save some bandwidth, but only for objects you are not getting closer to (since those will need full LOD at some point anyway); I have some doubts about the benefits in term of bandwidth.
1 hour ago, Kathrine Jansma said:2) Speed of rezzing/loading while on the move
A huge draw distance is nice, but i am just fine with a few imposters in the distance if moving around faster.
The viewer had this kind of option in its code (it allowed to load slower higher LODs the faster the camera was moving): it was never used and, when enabled, it made things much worst in rezzing time terms for objects you were getting closer to as you were moving... It finally got removed.
1 hour ago, Kathrine Jansma said:3) FPS preserving bandaids
If the sheer amount of textures, meshes and other data overwhelms the viewer and/or the network, there should be some optimization to rescue a somewhat useable framerate.
The textures resolution does not impact the least the frame rates. On the other hand, using better optimized (or slightly simplified) meshes would definitely help (the well known mesh LODs issue in SL).
-
1
-
-
43 minutes ago, Love Zhaoying said:
not just ”illegal instructions” or whatever Henri wrote
QuoteA crash happens when the viewer executes an illegal instruction (e.g. accessing some data out of the allocated address space, or jumping/branching/”returning” to a faulty address containing junk/random memory, causing faulty opcodes to be executed).
And:
QuoteAgain, a crash is due to illegal code being executed by the CPU, due to a bug
Accessing an invalid address (including buffer overflows) or corrupting the program counter were parts of what I wrote.
You should learn to read...
57 minutes ago, Paul Hexem said:To be fair, for the layman, even if it it includes an error message it's a ”crash”.
Not when the error message is the result of a disconnection and the viewer just tells you that it cannot continue to render the 3D world, and instead lets you the choice to quit or continue reading your IMs, chat, then quits cleanly after you decide you had enough. There is no bug, no crash, just an impossibility to keep rendering after teh disconnection happened.
-
1
-
-
4 hours ago, animats said:
If you didn't have the other picture to compare with, would you notice?
YES ! IMMEDIATELY !
I hate blur !
In real life, when your eyes fall on any object in the distance, they automatically adjust to see with the best accuracy and you never see blur (unless you got both bad eyes and bad glasses).
The blur as rendered on a computer screen is an artificial reproduction of an optical defect that you would see through the lens of a camera, which, unlike the eye, does not (and cannot) auto-adapt instantly to what you are looking at in the picture.
For the blur to look real, it should only appear around the real-time computed spot your eyes are focusing on at the moment the frame is rendered: so far, there is no technology allowing to reproduce such an effect, and beside, you won't need that blur rendered anyway (your eyes simply see blurrier, the farther to the macula the pixels are projected on your cornea).
I hate artificial blur, flares and whatnot that some 3D game developers seem to ”enjoy” impairing us with.
The 3D render of a scene is supposed to reproduce a real scene, not its perception through an imperfect optical instrument. A real scene in real life is never blurry, does not have flares, bokhe or whatnot, only the perception of the scene via an optical instrument causes these.
QuoteThis is what I'm shooting for as a goal. See entire cities, a bit blurred in the distance.
I'm sorry, but what you are shooting for looks totally ugly to me...
-
2
-
-
58 minutes ago, Love Zhaoying said:
My reason for mentioning a ”crash” was: sometimes the disconnect message might be shown when it's ”more than just a disconnect”.
Sorry then, but your reasoning is flawed: if the viewer shows a message and then quits cleanly, it did not crash...
Again, a crash is due to illegal code being executed by the CPU, due to a bug; this is NOT the case here...
1 hour ago, Love Zhaoying said:My additional assumption is: any application can be written so as to restart; the viewer developers (not YOU!) never added a ”reconnect” feature because it's difficult to ensure everything is stable.
I have been developing the Cool VL Viewer for the past 16 years. It never came to my mind that implementing a reconnect (from login screen, since there is no other way to reconnect cleanly to SL) would be ”nice to have” and even less worth it !
The solution to failed TPs is NOT to implement a ”reconnect without relaunch” feature, but to implement a reliable TP protocol with proper handshaking between the departing sim, the arrival sim and the viewer.
1 hour ago, Love Zhaoying said:Reminder: I'm a C++ developer with more than 25 years experience.
Reminder: I'm an assembly, C and C++ developer with over 40 years of experience. 👴
-
1
-
-
2 hours ago, Love Zhaoying said:
I think the viewer developers were lazy, quite frankly. No matter how badly the viewers are coded, ”restarting an application” certainly should be possible. Even with a hard crash.
I'm afraid you are mixing things together...
A disconnection is not a crash. A crash happens when the viewer executes an illegal instruction (e.g. accessing some data out of the allocated address space, or jumping/branching/”returning” to a faulty address containing junk/random memory, causing faulty opcodes to be executed). In this case, the viewer will just ”vanish” or the OS will report a crash and close it. If this happens to you, you should report the crash to the viewer developers (with the necessary data, i.e. the stack trace or crash dump, and the logs), so that the crash can be fixed; I personally never crash any more on TP with my viewer (and the rare times I did in the past, I fixed the corresponding bugs).
On the other hand, a TP may fail because the viewer failed to connect to the arrival sim server; the said disconnection could be the result of a bad network (lost packets), or a race condition (messages arriving out of order or too late to allow a proper connection sequence), or a failed handover between servers (for the same kind of causes: network or race issues). In this case, the viewer does not have any server left to speak with (not even the departing sim, which has already disconnected), and it will report a failure and present you with a grey screen, indicating it is disconnected; at this point, the validity of the data it got cannot be guaranteed any more, and the viewer does not ”know” what was the reason for the disconnection. A reconnection is therefore impossible, and the best course of action is to ask the user to restart a fresh viewer session and reconnect. True, it would be theoretically possible for the viewer to clean up all its memory and propose a reconnection from the login screen (like if you had relaunched it), but it would be complex to implement for a rare occurrence, and the resulting second session would be handicapped by side effects of the previous one (such as virtual address space fragmentation); it is much cleaner and safer to quit and restart the viewer for good.
The TP protocol in SL is however way too fragile (I already made a few suggestions in the Server User Group meetings to strengthen it). The lack of a proper handshaking protocol, and the fact the departing sim does not wait for the TP to complete (i.e. for the arrival sim to take over after a successful connection with the viewer) cause these cases when the viewer is ”left in the blue”, with no server to speak to !
-
1
-
2
-
-
10 hours ago, animats said:
The same avatars show up broken on successive logins.
Either their mesh body cannot be downloaded (corrupted/missing file on a CDN server ?), in which case the viewer should log it as a warning, or they are simply not truly wearing the mesh (like I explained about people TPing away before their outfit has fully loaded and their avatar has fully baked).
-
3 hours ago, animats said:
What complicates this is how region servers tell the viewer about adjacent regions.
Not really an issue. Given IPv6 connections would be incompatible with old viewers, all LL needs is to add a new UDP message conveying the IPv6 address, sent in excess to the one containing the IPv4. The updated viewers will then pick up whatever works for the network they are connected to, while old viewers would still get the IPv4.
-
1
-
-
12 minutes ago, Love Zhaoying said:
Unpopular opinion: IPv6 is inevitable. So, any associated activities with a move to IPv6 (including foreseen and/or unforeseen costs) are inevitable.
Inevitable or not, popular or not, it is, for now, impossible to migrate to an IPv6 only service for any public facing Internet service: the end users are just not yet all able to deal with IPv6, and it would cause the said service to loose an enormous amount of users... Things will change when, say, 95% of end users will be able to do IPv6 (then the pressure on the remaining 5% will be so high that they won't have another choice than to migrate their hardware to IPv6).
Note that, in the mean time, and to avoid AWS IPv4 fees, LL could perfectly route all the AWS servers IPv6 traffic via their own, in-house router with IPv4 public facing interface. Then they could manage their own IPv4 block at lower costs.
Of course, it means adding a bottleneck for the sims traffic, but since the latter got lower over years (with migration to CDN servers for textures, meshes and inventory assets, which was a Good(TM) move, unlike the AWS one), this might not be too much of an issue... To mitigate this bottleneck, LL could also add IPv6 support to the viewer, and then users able to do IPv6 would directly connect to the AWS servers, while the rest would go through LL's ”private” IPv4 router.
-
1
-
1
-
-
34 minutes ago, Kathrine Jansma said:
- A different allocation of money, you do not need to sink a lot of money into operating a datacenter and estimate your growth for proper sizing.
.../...
- Commodity infrastructure options you could use to replace your aging home grown systems with
Drawbacks: loss of in-house competency, ”big bucks” paid for this, relative and short term, ”advantage”.
35 minutes ago, Kathrine Jansma said:- Flexibility to experiment with technologies, for example the new even regions
Can do exactly the same with an in-house infrastructure, with even more agility/reactivity... Not a valid argument, at all, I'm afraid.
36 minutes ago, Kathrine Jansma said:- Commodity infrastructure options you could use to replace your aging home grown systems with
Yes, and this is likely what LL considered as the biggest advantage... But it also comes at a cost, which is far from negligible and, on the long term, may be not that advantageous compared with an in-house solution... It may however help spreading the costs and avoid investments ”spikes” (but a competent manager could instead anticipate these by sparing money and placing it on a separate investment account).
42 minutes ago, Kathrine Jansma said:Theoretical options to geo-distribute your regions
All the more theoretical since LL is not even using it (not really suitable to run sim servers anyway)...
43 minutes ago, Kathrine Jansma said:Easier rampup / hiring of admins
As an entrepreneur, I'd prefer finding it ”hard” to hire good admins, but in exchange gain a strong team of very competent and dedicated admins, rather than have to deal with third party admins and explain them again and again that, no, SL is not just about HTTP, and no, its not a web service, and yes, it got very specific and even unique needs and requirements, and please, hurry up !...
Just my two cents (which is pretty cheap, compared with AWS rates)... 😛
-
1
-
8 hours ago, Love Zhaoying said:
These charges - and any future charges by AWS is a risk LL took when migrating to AWS from their own data centers. I didn't see anyone mention it yet, but ”obviously” LL ”should” be paying less overall with AWS, or they would not have made the migration (unless other tangible benefits like scalability make up for it).
+1 for the risks they took. Sadly, we also share those risks as users (costs are reflected in the fees we pay, technical risks in the service quality, plus the viability of SL itself).
As for the ”benefits” of the migration, I would bet they are regretting their decision now, and that it is not a benefit at all in terms of costs.
I personally think the AWS migration was a mistake: loss in autonomy, competences, infrastructure specification choices (agility and adaptation to future needs). But of course, it is just my opinion.
15 hours ago, Kathrine Jansma said:Sadly there are still stupid ISPs that only offer IPv4 access (mine for example 😞 ). So going IPv6 only is still not a good option for all cases.
My ISP offers IPv6; in fact, this is the other way around: they use IPv6 by default and offer IPv4 over IPv6, with also optional static IPv4 (at least for now). However I am still using IPv4 only on my local network and blocking IPv6 traffic, the reason being:
15 hours ago, Kathrine Jansma said:The tricky parts come in when you try to do dualstack IPv4/IPv6
Indeed quite tricky, especially when you want to secure properly your local network (not to mention I still have antediluvian computers on this network, that cannot even ”speak” IPv6).
15 hours ago, Kathrine Jansma said:But getting all user to IPv6 is more of a problem.
I would say it is Mission: impossible for now, and probably one or two more decades...
-
4
-
Facebook
Instagram
Twitter
YouTube
Flickr
20 years, still full crash on teleport
in General Second Life Tech Discussion
Posted
Just as crappy as closing your tab in your browser because the server returns a 404 or 502, or simply never finishes loading the page...
But I'm done with trying to explain to nonsensical persons... Have a nice day !