Jump to content

Henri Beauchamp

  • Posts

  • Joined

  • Last visited

Everything posted by Henri Beauchamp

  1. Not a surprise... As I explained in my above message, all CEF versions between 77 and 89 are affected by those random crashes. The current CEF releases (90 and newer) got it fixed.
  2. This sounds way too long to me... A few seconds should suffice to backup 4 GB or data to your SSD...And yes, a 2GB cache would be plenty enough to store the data for at least 4 of your preferred/most visited places: increasing the size is hardly bringing any benefit (if you travel a lot in main land, the cached files will get evicted from the cache at some point anyway, whatever its size). I do not know what RAM-disk software (or script) you are using, but it looks like (by the time it takes) it uses compression: just disable the latter and store the data uncompressed, and if possible, as a single file (as a 'tar' file under Linux or an equivalent for other OSes: zip can do it with the ”do not compress” '-0' option, for example). Things such as the inventory list cache takes time to load, even with a fast Internet link, and without a loaded inventory, your avatar will stay a cloud: you might want to at least save and restore the inventory cache files...
  3. Under Linux for an ext4 file system, you use the ”noatime” option (at the minimum; I use personally lazytime,noatime,nobarrier,delalloc,discard) to prevent ”last accessed” time stamp update, when using a SSD. So the cache defeats that mechanism... Not to mention this is not even the ”last access time” data which is updated on reads in the ”simple cache”, but the ”last write time” (because you need to make sure this time stamp is indeed the result of a cache code access, and not of some random read from the file explorer, wsearch daemon or whatnot). Even with the old VFS-based cache (a single large cache file holding a virtual file system), that ”last used” info had to be stored as bytes inside the VFS file... There are several separate caches in use by the viewer: The textures cache. The assets cache (animations are among them, but meshes are by far the largest stored assets in it) or VFS. The objects cache (per-sim files). The inventory list cache. Some other minor cache files (names cache, mute list, decoded sound files, etc). You could eventually separate the textures, assets and objects caches from the rest, but I do not really see any benefit in doing it...
  4. Even for reads, the cached files need to have their last access time updated, so that the cache code knows what files to evict first when it needs to make room for new files (it of course first evicts the files that have not been accessed in the longest time). On HDs, this is not an issue, but on SSDs, where writes are done at a block granularity (i.e. you cannot just write a couple of bytes in the Flash memory: you must erase and rewrite an entire block with the few updated bytes), it can cause an excessive wear. While MLC and multi-layer TLC Flash is usually endurant enough, I won't use any single-layer TLC or multi-layer QLC for a cache (not to mention TLC and QLC writes are slow and/or cause an excessive ”write amplification”, due to the fact that each block is first written in an area used as a pseudo SLC flash, for speed, and rewritten later in the TLC/QLC ”standard” area) ! It is just simpler (and faster, at least under Linux and macOS; Windows is another story, especially just after a reboot, when the OS does not yet have a cached directory tree in RAM). It however does not solve SSD wearing (even though it attempts to mitigate it by not writing the access time at every read if the last read timestamp is recent enough). A proper RAM-disk saves its contents on disk on OS shut down and restores it on reboot... Not at all. Here (under Linux), it takes just a couple of seconds to save a 2GB RAM-disk and even less to restore it: I do not even bother compressing the RAM-disk data (which would take more time): I just 'tar' it to the SSD and voilà.
  5. If you have a sufficient amount of RAM (16GB and preferably more), your best bet is to use a RAM-disk for the viewer cache: it is the fastest, by several orders of magnitude, and will prevent to wear out SSDs and HDs. A 2GB RAM-disk is enough, at least for one viewer (be aware that different viewers normally use different cache directories, so their cache size would add up in your RAM-disk).
  6. The release notes page for the RC server is missing: This XML file does not appear to have any style information associated with it. The document tree is shown below. <Error> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>V3536Y6VV3TTPEP1</RequestId> <HostId>ZMSq1zpADnS9k59CP12ByneuInAk8B/mFGFYbM9IokBFgR/x6H9OVm4l9sMrnFvUcAWmY27uMiQ=</HostId> </Error>
  7. The CPU is indeed only part of the problem, and neglecting the GPU might give you entirely false render cost figures on systems where the GPU is the actual bottleneck (*)... It would be great to get figures with CPU + GPU render time for each avatar. Not sure it is at all feasible however (perhaps by rendering only a given avatar and nothing else for a few frames in order to get its render cost). (*) Typically, systems using iGPUs, since those are especially weak; with a discrete GPU, even as old as a GTX 660, the CPU becomes the bottleneck in SL.
  8. There is no risk to ”fry your computer”. At worst, your CPU or GPU would throttle down their frequency to avoid overshooting their max rated operating temperature (itself a few Celcius degrees below the absolute max temperature). Typically, a CPU that would fry above 105°C will throttle down its frequency to maintain 95°C or below, and should it reach 105°C regardless (e.g. because you'd remove the cooler), it would perform a safety shutdown to avoid burning... There have been examples of ”frying laptops” in the past, but they all were due to battery failures (and only because of a bad design of the latter).
  9. Wrong again... The Cool VL Viewer can render EE settings in WL rendering mode or WL settings in EE rendering mode (the settings are translated automatically). This includes altitude-based environment settings. Of course, some EE-only parameters (e.g. non-standard Moon orbits, or Sun and Moon non-standard textures) cannot be rendered in WL mode, but it won't totally break your personal experience, and won't affect at all the ”shared experience” as seen by other users around your avatar. You still did not get what the rule about not ”altering the shared experience of the virtual world” means: it does not imply that you should have the exact same rendering of a scene in all viewers in a given place, but just that by its mere usage, one viewer won't break the experience as seen by other users around (as it has been the case in the past with non-standard attachment points, which in turn prompted the implementation of that rule).
  10. Wrong ! Once more, the ”shared experience” rule (chapter 2k of the TPVP (*)) is only here to avoid breaking things (how they render or work) in others' viewers than in the one breaking that rule. This has been the case, in a distant past, when a TPV implemented secondary attachment points (back in that time there were much less such points and each point could only have one object attached to it) that caused those supplementary attachments to appear floating around the avatar (or attached in their butt, which could look rather funny) in other viewers not supporting that non-standard feature. This is the very and only reason why this rule got implemented. On the other hand, LL cannot care less about what you render in your own viewer (as long as you do not come back to them to complain about a ”bug” when this is just an unusual feature their official viewer does not implement). If you wish to render with DoF or without, with shadows or without, with ALM or without, with a fixed, custom or a parcel environment, with an EE or WL renderer, you can do it without any issue whatsoever. About EE and WL, the Cool VL Viewer offers you the choice between both sets of shaders (and their matching renderer), and this does not break the ”shared experience” of other avatars around yours, since this is exclusively a viewer-side feature that does not have any impact outside your own screen. And if you want an example of such a viewer-side, non-”rule-2k-breaking” feature with Firestorm, there's the parcel Windlight settings based on a string in the parcel description (which LL elaborated as the Extended Environment); this feature was not supported by LL's viewer, and yet LL never invoked rule 2k.. (*) ”2k. You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer.” (emphasis mine).
  11. Problems would have to be solved first for the ”capturing and logging the traffic required for rendering” step: you must understand that the viewer does not grab (neither get sent) everything around your avatar, but only what it needs to render the scene; it depends on your avatar position, the configured draw distance and the camera angle and focus point; it means that your wish to allow camera movements on replay is not really feasible ”as is” (though, one could imagine rotating continuously the camera around in capture mode to trigger ”interest list” updates covering all surrounding objects, obtaining a 360° field of view). You would also need to store permanently (as part of the captured data) all the textures, meshes, animations data, but also particle systems parameters, environment data changes, etc. I'm not sure how this would be considered, on a legal point of view, but it might be perceived as a form of contents ripping/copy-botting (and could certainly be abused in such a way)... I'm skeptical on the feasibility of such a project (and not so much on the strictly technical aspect than on the legal one). As for the benefits in ”lag” terms on replay, you might get disappointed in the end, for the replay viewer would still need to decode textures, meshes and objects data at the proper LOD, run animations, etc, meaning the main loop won't be any faster than what happens after you got everything downloaded and in caches with a normal viewer (at which point, the exact same amount of time would be spent in your replay viewer and in a normal viewer, to render the scene)...
  12. It depends on the viewer... Normally somewhere in the Advanced menu (”Advanced” -> ”Consoles” -> ”Texture console” for the Cool VL Viewer). The keyboard shortcut for the toggle is usually CTRL SHIFT 3. Which would indeed advocate for a lower LOD selection, maybe because of the discard BIAS. Reloading the texture or editing the face causes the best LOD to be forced, regardless of the bias... As soon as the Edit floater is closed or the importance to the camera reevaluated (as a result of a camera zoom change, for example), another LOD may get selected... You may also use the ”LOD info” debug feature (”Advanced” -> ”Rendering” -> ”Info displays” -> ”LOD info” for my viewer) to see what is the LOD the textures are rendered at; beware, it's ”spammy”, and you'll likely have to remove all attachments you are wearing but the one you want to test to see the proper hover text without zooming (zooming would affect the LOD, see below). A possible explanation would be that you changed your default camera settings (the farther zoomed on your avatar, the lower the selected texture LOD)...
  13. You got me curious... Vulkan renderer ?... I'd love to try and adapt it to my viewer, which you would likely classify as ”hyper aggressive”, since I regularly see it suck up assets (meshes and textures, mostly) at over 250Mbps (true TCP/IP observed bandwidth) on a 1Gbps (ATM bandwidth) FTTH link after TPs in un-cached region...
  14. It is possible that your viewer is badly configured, or that it got too little memory to rez textures at the proper level of detail. Watch the ”discard bias” number in the texture console. Ideally (when properly configured and with enough available memory), it should be 0. A higher BIAS means lower texture LODs (i.e. blurry textures) on rezzed objects. This said, have a try with the Cool VL Viewer, and see how it fares...
  15. The Cool VL Viewer is (and has always been) primarily a Linux viewer, since 2007. It can do everything the official SL Windows viewer can do (and more, such as Lua viewer-side scripting), with the exception of the ”path finding capsule” visualization (because there is no Open Source alternative for the closed source Havok code it uses), including uploading meshes with Physics decompositions (based on HACD, which replaces Havok for this task).
  16. If you are using the Cool VL Viewer, you do not need to worry at all about cache locations and file names when logging in in different grids... File names that do risk to collide (such as for the regions objects cache, the inventory caches, etc) have a grid suffix appended for non-SL grids (also, the Cool VL Viewer uses a different cache location or cache file names than any other viewer, where appropriate, so you may use it along other TPVs without any risk). Assets and textures caches are shared, but the collision risk (i.e. encountering two different assets or textures with the same UUID on two different grids) is totally negligible (just as probable as getting a duplicate UUID generated for a new asset/texture uploaded in SL). The only exception is fo UI sounds (which have a fixed UUID but different actual sounds in SL and OpenSim), but even for those, the Cool VL Viewer offers a way to cache UI sounds and make them ”static”, to avoid mix-up when you log in both SL and OpenSim grids...
  17. Well known issue, usually caused by a badly designed product causing a low texture LOD to be used. To work around it, I implemented (years ago) a ”Boost attachment textures LOD” in the Cool VL Viewer... While it works for all rezzed avatars, it of course only works (on their screen) for people using this viewer.
  18. I find it rather funny (and quite silly) that LL did not even properly change the code of their own viewer to prevent UDP fetching of textures after they shut down the service... Got a ”mCanUseNET = !gIsInSecondLife && mUrl.empty();” line in my viewer to implement this trivial limitation (which would translate to ”mCanUseNET = false;” for LL's viewer, since it won't log in OpenSim grids)...
  19. Strange, really... Perhaps the UDP service got accidentally re-enabled in the sim servers during the AWS migration... As for viewers, the Cool VL Viewer is still able to fetch textures via UDP (as a fallback to HTTP), but, after LL shut down UDP texture serving (which happened quite some time ago) only on OpenSim grids (i.e. the UDP fetch retry code is disabled while logged in SL). However, if someone found a really old release of my viewer, they might be able to try and fetch textures with UDP (there was even a switch to disable HTTP fetching in even older releases, dating back from the time when HTTP fetching was still experimental). The same is true of other TPVs that do not have a kill-switch (no forced update & Co), so I suppose it is possible to still find a viewer nowadays that could do that (but at the cost of a sh*tload of missing features, of course).
  20. Mindful scripters will limit the usable memory for their scripts to what those scripts do need: this will also prevent those scripts from appearing as always using the max allotment memory (64KB) when they actually only use a fraction of that allotment. But as noted in above posts, nowadays, and given the amount of equipped memory per server, I very much doubt memory usage is a problem any more... Regarding the server-side load, the one and only relevant info for scripts is the amount of time they consume per frame (which is the OBJECT_SCRIPT_TIME figure as returned for each object by llGetObjectDetails()), i.e. how much time the server consumes to process events in the script at each server-side ”frame” (loop). And even then, you must account for the fact that this number is averaged over 30 minutes or so: it is maximal when you arrive in a region (because the script state de-serializing and resuming time is taken into account), and that's why you sometimes see a ”lag spike” when a heavily scripted avatar enters the region where your avatar is present). So, the micro-seconds per frame figure is only getting truly relevant 30 minutes or so after the avatar arrived in the region. As a conclusion: that floater is of little to no use (a scripted load monitor can do the exact same job) and rather irrelevant most of the time anyway... That's why I never bothered implementing it in the Cool VL Viewer.
  21. There could be, and very easily: the viewers derive an unique computer ID out of your computer hardware. This ID is used during login and allows LL to track griefers, for example. It would be dead easy to add some code to the viewer in order to transfer that ID together with the avatar name to a third party website so to register them into a database and then find out what avatars pertain to the same person (or, at least, are used on the same computer, since a family could be using several accounts on it, with several avatars). My advice is to never trust any viewer build that is not provided by the developer/team maintaining that viewer, together with the sources (and only via their official web site or channel). This is true of any Open Source software !
  22. Either you report properly, on the support forum, or I will not even bother trying to understand your issue. Beware: I won't take abuse from stubborn people... I share my work on my viewer as a free service for other like-minded people; don't make me regret it ! This is my last message here, on this topic.
  23. It's in no way ”broken”, and the script does report to you what it finds missing on your system... Here, it will complain about a missing binfmt_misc module and ask you to fix that issue before retrying. Yes, please, this forum is not the place for this... The call to ”wine” shall be done by the kernel, via binfmt_misc... That's how all modern distros I tested (and I tested many, believe me) do work. That's also what TPVs allowing to run SLVoice.exe from Linux (e.g. Firestorm) expect to happen: they never launch ”wine” (or wine32, or wine64, or whatever it is called in your distribution, which the viewer cannot guess) directly, but delegate to the Linux kernel the care to find the right launcher for the SLVoice.exe binary (which is the binfmt_misc module's very task and only purpose)... I could of course arrange something else for exotic or badly configured Linux systems (via a wrapper script to launch SLVoice.exe, for example)... Post all the gory details about your system configuration and what messages you get from the installer script on the viewer support forum and I will see what can be done...
  24. /proc/sys/fs/binfmt_misc/* files are checked by the script to verify that the binfmt module (which is responsible for launching non-ELF binaries, such as Windows ones) is indeed installed and active on your system, and that a proper Wine entry is configured (so that binfmt knows that it needs to use 'wine' to launch binaries matching Windows' executable format). This should pose no problem whatsoever, unless your distribution is using non-standard kernels patched with a different /proc layout... If this is the case, please provide details on the Cool VL Viewer support forum.
  25. Well, it should... Please, report any issue you find when using the Cool VL Viewer on its support forum. Give all relevant details (at the minimum, what Linux distribution and version you are using); 'which wine' output would help there, or the list of the files (especially, the wine executable) in your Linux distro's package.
  • Create New...