Jump to content

Henri Beauchamp

Resident
  • Posts

    184
  • Joined

  • Last visited

Everything posted by Henri Beauchamp

  1. If you can compile a viewer yourself, a patched version would allow you to delete the offending folders. You may want to try the Cool VL Viewer which is easy to build and which code already contains an exception for OpenSim grids and the COF (allowing you to delete the latter in OS grids, since it is not mandatory there). The line to change to allow deleting the ”Current Look” folders is in linden/indra/llinventory/llfoldertype.cpp, line 142. Change that line to read: if (folder_type == FT_CURRENT_OUTFIT) (i.e. remove ” && sCanDeleteCOF” from it). Recompile the viewer, log in, delete the two offending folders. BEWARE however: DO NOT, under ANY PRETEXT, delete the ”Current Outfit” folder in SL (and if there are several folders named ”Current Outfit”, do NOT delete any of them, but let LL support deal with them): deleting the COF would cause bake failures, even after recreating it (I know first hand, because I deleted mine by mistake once during a viewer testing session): the reason is that its version (i.e. the number of times it got updated) is somehow kept in SL's servers and as long as its version is lesser than the one used for the last successful bake, you cannot rebake with it. I reported that bug (that I worked around for my account by rebaking for hours via scripted RLV @attach/@dettach actions until the new COF version got greater than the old deleted COF version), years ago, but I doubt LL fixed it...
  2. From what I understood, your baking issue is not the same as the server communications issues we have been seeing for the past 4 days or so. I bet your issue would be easily solved using a viewer able to erase the COF contents and rebake from scratch: there are probably stale links in there, preventing your avatar to bake...
  3. Well, I'm developing my viewer, so I log in and out many times a day (to test new code, etc), so I see any login issues happening before many people would, I guess... It may also depend on your country, since you'll hit different AWS servers based on it... In France, it was an awful SL week-end and problems extended from Friday to yesterday afternoon, and still seeing slow parcel info updates today, even if logins seem much more reliable... so far (morning here). EDIT: spoke too soon... Logins fail again today !
  4. SLers' level of patience and frustration ? 🤣 Can't be worst than what happened during the past 96 hours, can it ?... I mean, I never saw such an amount of issues with SL failing logins, TPs, inventory fetches, baking, etc, and of course, all of them happening while support was offline... 🙄
  5. Same for me: for now over 24 hours, I have had issues with SL servers not responding or only very slowly. It may start at ”logging in”, ”waiting for region handshake”, ”waiting for seed” or ”connecting to region” during login process, each of these steps denoting an issue with SL servers slow or failed replies. Sometimes, it takes me no less than 6 attempts to manage getting in SL when it had been flawless for years ! Sim seed and capabilities are also often failing to arrive on time after TPs, resulting in various issues (textures loading delayed, bake failing or incomplete, parcel information not arriving, etc). Finally, the inventory service seems impacted as well (especially when the AISv3 protocol is enabled), with slow or failing inventory fetches, failing bakes after outfit changes, etc... In the viewer log I can see a lot of ”out of order UDP packets” lines too, something that rarely ever happened before... All these seem related to the ”servers uplift” and how some services are still split over AWS and LL's servers... SL is really in a very bad shape right now: it would compare with the level of reliability (or lack thereof) of the 2006-2008 era !... Well, not quite, because a full grid down time is still to happen today, but at this rate I won't be surprised if it would happen ! 🙄 And of course, to top it off, support is offline when this happens !
  6. Support for the Cool VL Viewer is exclusively provided via the Cool VL Viewer forum (in-world requests, in whatever form, will NOT be replied). Also, do not listen to some people silly replies provided elsewhere, especially when they have been banned from my own forum for their wrong doings.
  7. Ditch every modern editor/IDE: keep using Nedit (or XNedit for people using UTF-8) ! 👴 I have been programing with it in all languages (C, C++, Forth, Perl, Tcl/Tk, JavaScript, Java, Python, PHP, bash, etc), for the past 26 years... And yes, I even made syntax highlighting ”recognition patterns” settings for LSL in Nedit... Seeing how much code I produced with this editor (that also can act more or less like an IDE since you can launch complex commands with it, including compilation), I can tell you it certainly does not harm my productivity. 🚅 And yes, the Cool VL Viewer is entirely coded using Nedit.
  8. Adaptive sync is like VSYNC, but at a variable rate: if you use it, you will NEVER get the maximum frame rate from your games, for the driver inserts pauses whenever the frame renders too soon to be displayed in sync with the next monitor frame. You CANNOT get the best performances in frame rates with adaptative sync of VSYNC. The Cool VL Viewer does not try to switch sync modes on/off, unlike some other viewers. As for tearing, I never saw any here while I have no sync scheme set for my driver: simply use triple buffering and you will be tear-free and with the best frame rates. You are free to use your driver settings the way you like, but then do not come and complain about low frame rates !!! This is my last message on this topic.
  9. And this is just now that you reveal you are using ”adaptive sync”... What happens when you turn it off ? Mind you, when in adaptive sync mode, the driver may purposely slow down the frame rate in order to better sync with the monitor... And like I explained, the default field of view in the Cool VL Viewer is NOT the same as in other viewers... You must edit the corresponding debug settings (CameraOffsetDefault for the Cool VL Viewer and CameraOffsetRearView for Firestorm) to get them to match exactly, or you will get a different amount of objects in the FOV, meaning a different load for the renderer.
  10. Look, I just made another test, in Aditi, in an empty sim so to avoid different surrounding avatars in different viewer sessions, but with some scenery so that it does tax the renderer. The sim is Moonberry Bay, at pos 117,181,21 (on the pier, looking SW towards the shore). All settings to the max (with specific settings in both viewers set so they are the same, i.e. mesh multiplier LoD factor set to 1.0 and Classic clouds off in Cool VL Viewer, Render LOD Factor limited to 3 and terrain details LoD to 2 in Firestorm), 512m draw distance, camera angle set the exact same way (this is super important since the default camera angle of view is different, the one in my viewer being behind the avatar (Z=0) while it is slightly above in other viewers, meaning you pick up and render more objects in the distance in my viewer while you render more floor/terrain in others !), all shadows and no SSAO/DoF blur when in ALM. Cool VL Viewer: WL, non-deferred (ND) rendering: 65fps WL, ALM: 55fps EE, ND: 43fps EE, ALM: 39fps Firestorm v6.3.9 (WL); ND: 26fps ALM: 22fps Firestorm 6.4.5 (EE): ND: 30 ALM: 26 This is an easy bench for everyone to reproduce... Amusingly, Firestorm 6.4.5 (EE) seems faster to render this scene than v6.3.9 (WL)... It might be an effect of the new alpha textures batching code in the EE renderer...
  11. Thing is, you are the only one to get these results... I could post mine here (that are in total contradiction, and on 4 different PCs, ranging from a super old Althon64 + Radeon 9700 to a brand new 9700K + GTX 1070 Ti), but this would be off-topic... Just like this post of yours. I told you on my forum that your system probably had an issue with the frequency or power governor and/or with the BIOS settings for the max package power and/or max socket current...
  12. Dead easy to prove you wrong here. Get the Cool VL Viewer, wait for every texture to load (switching renderers while some load might get them in the wrong texture channel), then switch on/off ”Extended environment shaders” in the graphics settings (not touching anything else), and observe the frame rate...
  13. I strive to stay on par with LL's latest (often not even yet released) changes, and every modification to the EE renderer gets backported in the Cool VL Viewer (and with weekly releases, the changes in LL's git appear only a few days later in the next Cool VL Viewer release); that's why you see different results in the EE renderer of my viewer when compared with other viewers with a slower release rate. This said, as I already wrote in this thread, EEP (P for ”project”, and it will stay as such (i.e. not of actual release quality) for a loooong time, I'm afraid) has been ”released” way too soon by LL. Not only does it break existing contents, but it is a performance killer (thus why I implemented the dual-renderer feature in my viewer: people not caring about pretty skies shall not suffer a 50% performances loss because of EEP !).
  14. LOL ! The Cool VL Viewer is probably the fastest viewer around (the main loop is about 50% faster than LL's viewer and 40% faster than Firestorm's)... Singularity may sometimes equal it, but all others are MUCH slower. If it is ”sluggish” for you, it is probably a problem with the settings. You can only compare viewers when using the exact same settings in the exact same conditions... Benchmarking is an art...
  15. I'm afraid such benchmarks are not very significant, unless you know for sure the sims are running on the same hardware (especially with the same CPU power) sharing the same load (number of sims per server, RAM usage to avoid swapping, etc), and (if applicable) using the same virtualization software/hypervisor... Too many unknown variables for us: only LL devels/admins can perform such benchmarks in a proper/deterministic way.
  16. My avatar was already wearing 80+ scripts... Adding more scripts of mine won't change things much, for my scripts are well optimized (especially in the memory usage (most important for sim crossing) and events processing departments) ! 😜 I'd need to add badly scripted stuff to my Aditi inventory... But feel free to use by yourself the same method as the one I described. 💭
  17. Yep, seems working just fine now. Did it flying (avatar fly only) with a ”mildly heavy” avatar (25 attachments, around 80 scripts capped at around 3Mb of RAM): But you should change the permissions of the gift it gives, because I also got: 😜 Here are the region crossing times I got from the viewer log: Personal test: 2020-07-28T15:13:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 435.148 ms 2020-07-28T15:13:34Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 393.159 ms 2020-07-28T15:13:59Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 439.247 ms 2020-07-28T15:14:11Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 391.723 ms 2020-07-28T15:14:28Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 450.473 ms 2020-07-28T15:14:44Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 457.707 ms 2020-07-28T15:15:01Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 438.855 ms 2020-07-28T15:15:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 451.317 ms 2020-07-28T15:15:35Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 394.944 ms 2020-07-28T15:15:39Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 423.022 ms 2020-07-28T15:16:02Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 394.764 ms 2020-07-28T15:16:05Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 401.468 ms 2020-07-28T15:16:06Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 403.55 ms 2020-07-28T15:16:10Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 446.477 ms 2020-07-28T15:16:14Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 368.816 ms 2020-07-28T15:16:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 382.727 ms 2020-07-28T15:16:22Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 446.515 ms 2020-07-28T15:16:25Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 371.96 ms 2020-07-28T15:16:27Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 448.023 ms 2020-07-28T15:16:29Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 388.299 ms 2020-07-28T15:16:32Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 445.138 ms 2020-07-28T15:16:34Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 430.341 ms 2020-07-28T15:16:36Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 442.932 ms 2020-07-28T15:16:38Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 413.238 ms 2020-07-28T15:16:40Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 447.037 ms 2020-07-28T15:16:43Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 388.694 ms 2020-07-28T15:16:46Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 425.852 ms 2020-07-28T15:16:51Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 386.307 ms 2020-07-28T15:16:55Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.2 ms 2020-07-28T15:16:58Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 444.341 ms 2020-07-28T15:17:16Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 445.237 ms 2020-07-28T15:17:22Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 437.963 ms Back sea challenge: 2020-07-28T15:20:42Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 419.862 ms 2020-07-28T15:20:58Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 356.679 ms 2020-07-28T15:21:14Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 369.125 ms 2020-07-28T15:21:30Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 419.841 ms 2020-07-28T15:21:47Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 363.55 ms 2020-07-28T15:22:03Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 422.33 ms 2020-07-28T15:22:19Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 385.414 ms 2020-07-28T15:22:35Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 411.964 ms 2020-07-28T15:22:51Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 435.624 ms 2020-07-28T15:23:07Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 448.512 ms 2020-07-28T15:23:28Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 381.7 ms 2020-07-28T15:23:44Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 390.958 ms 2020-07-28T15:24:00Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 387.146 ms 2020-07-28T15:24:10Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 427.114 ms 2020-07-28T15:24:26Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 391.214 ms 2020-07-28T15:24:42Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 371.007 ms 2020-07-28T15:24:59Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.141 ms 2020-07-28T15:25:16Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 445.889 ms 2020-07-28T15:25:28Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.793 ms 2020-07-28T15:25:42Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 401.7 ms 2020-07-28T15:25:58Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 389.019 ms 2020-07-28T15:26:14Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 398.36 ms 2020-07-28T15:26:31Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 387.909 ms 2020-07-28T15:26:44Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.128 ms 2020-07-28T15:27:01Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 392.492 ms 2020-07-28T15:27:17Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 442.12 ms 2020-07-28T15:27:38Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 390.326 ms 2020-07-28T15:27:52Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 385.123 ms 2020-07-28T15:28:06Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 398.123 ms 2020-07-28T15:28:22Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 390.206 ms 2020-07-28T15:28:36Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 446.418 ms 2020-07-28T15:28:52Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 398.019 ms 2020-07-28T15:29:08Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 383.912 ms 2020-07-28T15:29:23Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 386.911 ms 2020-07-28T15:29:39Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 443.062 ms 2020-07-28T15:29:55Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 396.678 ms 2020-07-28T15:30:01Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 447.504 ms 2020-07-28T15:30:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 391.238 ms 2020-07-28T15:30:27Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 394.383 ms 2020-07-28T15:30:36Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 385.006 ms 2020-07-28T15:30:55Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 395.23 ms 2020-07-28T15:31:06Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 441.859 ms 2020-07-28T15:31:22Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 450.933 ms 2020-07-28T15:31:40Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 442.411 ms 2020-07-28T15:31:56Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 391.386 ms As you can see (or rather cat | cut | sort, 'cause I'm lazy), the minimum was 357ms and the maximum 458ms. It should be noted that during my personal test, I tried hard to make crossings fail (for example by flying in circles at the frontier/corner of four regions, to enter and re-enter regions as fast as possible). So I'd say it's a very good start for the new region crossing server code !
  18. Greetings, I just discovered this new testing ground yesterday and gave it a try. While flying (avatar ”Fly”, i.e. not flying any scripted plane or such), most Blake* regions crossings were flawless (with at worst a split second ”hiccup” at crossing), but I did notice strange things, such as regions visible/active on map and invisible/inactive on mini-map and not accessible via crossing from other regions (while it was possible to TP into some). It was late in the night for me, however, so I did not take any note of time and region names. Today, I gave it another try and stumbled upon the same issue as yesterday, with one region in particular, inaccessible via borders crossing (excepted from one region: more on this later), but into which you can TP to. This region is ”Half Hitch” (debugging it might turn into a ”full itching” for you 😜). After I TPed into it, wearing a mildly scripted avatar (with 25 attachments containing around 80 well scripted/optimized scripts, consuming less than 3Mb or memory), I succeeded in crossing the South border to ”Turnbuckle”, but all other borders in the latter were uncrossable, so I headed back North to ”Half Hitch” and found myself ”stuck” just after the border, with the viewer disconnecting after timeout. When I re-logged to ”Last location”, I found myself back inside the region where I departed (”Kraken”) for my trip and before I TPed to ”Half Hitch”. Here is a zip file (too bad this forum refuses zip attachments...) with two logs (and a screen shot taken while ”stuck” and before timeout); the first log was from a session when I used a much lighter avatar with only a few attachments and scripts: I stopped in ”Kraken” to change for an ”heavier” outfit and since I got a ”Failed to rez attachment” message (not unusual in Aditi), I re-logged to avoid any possible issue with ”in flight” attachments data while crossing sims. The second log is the most interesting one, in particular with the warning message appearing here: 2020-07-26T13:51:07Z INFO: process_crossed_region: Crossing region boundary 2020-07-26T13:51:07Z WARNING: LLWorld::addRegion: Region exists, but old host 54.244.7.15:13006 does not match new host 0.0.0.0:0. Removing old region and creating a new one. 2020-07-26T13:51:07Z INFO: LLWorld::removeRegion: Removing region 290048:268800 2020-07-26T13:51:07Z INFO: LLViewerObjectList::killObjects: Removed 8282 objects for region Blake Sea - Half Hitch in 24.416ms It looks like a bogus IP (0.0.0.0) was transmitted to the viewer for the region it was entering !
  19. Thing is: we know strictly nothing about Apple's future custom GPUs (since they plan to do away with NVIDIA and AMD and to use their home-made silicon chips)... Open Source is far from being the characteristic of Apple's ecosystem, and nothing can give us a single clue wether their future GPU will have an open (as in at the very least *documented*) API or will need reverse-engineering to add Open Source Vulkan compatibility layers...
  20. It's going to be a close-to-impossible task... Unless Apple finally decides to adopt a Vulkan compatibility layer for their future ”Metal GPU”... LL has recently added a Vulkan detection feature to the statistics sent by the viewer to their server (i.e. the info whether your system got support for Vulkan or not is sent together with the stats the viewer reports to the SL severs). Obviously the preliminary evaluation for the feasibility of a Vulkan port. Transitioning from OpenGL to Vulkan would allow to make the viewer renderer multi-threaded and (at last) benefit from the many-cores modern CPUs, while retaining the compatibility with the current three platforms (Windows, Linux and x86-based macOS). Not sure it will be sufficient, however, to support ARM-based Macs if the latter cannot run Vulkan ! LL will also need to add support for ARM CPUs in the viewer code (i.e. providing Neon optimized maths for the viewer maths currently using SSE2). A lot of work for a small user base: much, much, much more work than supporting Linux, which LL already stopped (while trivial !), letting TPV developers do it in their place ! 🙄
  21. I don't see it ”canned” any time soon (and never in my viewer !)... You are probably confusing the possibility to disable ”basic shaders” (now removed from the EE renderer), but those would only affect pre-v2.1 OpenGL, and the WL renderer already could not render things correctly with basic shaders off. As for deferred rendering (AKA ALM), I personally dislike it a lot and pretty much never use it myself: it makes everything look blurry and gloomy while non-deferred rendering is crisp and vibrant. Not to mention a lowered FPS rate in ALM, which becomes even more critical with the EE renderer...
  22. Irrelevant quote... The only rule there is not to break shared contents for *others* (e.g. via things the viewer would transmit to the servers and that other viewers won't be able to render), not for changing how things look for yourself. 😝 In any case, your (I'm afraid, dictatorial) demand has already been rejected by LL, by design, since they always allowed custom environments, viewer side, be it with WL or EE... End of discussion for me.
  23. You can make up any rule, but you cannot impose what a user displays on their computer screen... It's called freedom. Sorry. Is that a menace ? 🤣
  24. It could easily have been added to the Windlight renderer/shaders at a much lower cost in frame rates (with 30-50% loss in EE when compared to WL).... Thing is, it was already possible with WL... And the syncing with each user's RL is not even what truly matters for many SL users, namely role-players: the rhythm of a role-play (especially between para-RPers) will never match or sync with any clock, be it the wall clock/ocal time (which is likely not even the same for each RPing partner), or the sim time (whatever its day length setting). ”Not home-made” programmer syndrome... Just because the feature existed in TPVs and not in LL's viewer, then you decide to break every ”standard” that LL did not define itself... Note that I am not advocating for one of ”my” standards here, since my viewer did not (natively) implement Firestorm's way of providing parcel customized environments (even if you could easily emulate it via Lua scripting in my viewer). I just find this approach (snagging TPV developers' work or ideas, and re-implementing or re-branding it as LL's without any request for comments or inputs from the original authors and, most important, from their user base), totally lame ! Sharing is a good motive... I suspect the ”selling” aspect was the main (and actual) motivation behind this feature... Not going to blame you for it since as a private company I do acknowledge that LL needs incomes... Especially to cover the total wastage of coding power and money that went into Sansar (RIP !). Too bad you pushed EEP to release status while it is was not even remotely ready for it ! I'm not opposed to progress and evolution (by far, as shows my early adoption of new features in my viewer), but I'm opposed to needless ”progress” that actually results in regressions. The huge loss in frame rates and the discrepancies in how things are rendered in EE viewer compared with WL will just make more people grumble, complain, or resist to the bitter end to that change.
  25. I'm very sorry to contradict you on that point, but I deny you (or anyone else) the right to control how environment is rendered on *my* monitor. You might find it cool to *impose* *your* view on others, but I don't find it cool *at all* that this could ruin *my* fun, *my* way to (and rhythm in) RP, or simply to make things not visible on my screen because you love super-dark environments while I try to preserve my (aging) eyes by keeping the luminosity (relatively to the room ambient light) as low as possible on my screen. The Cool VL Viewer, for one, will *always* provide the final user with full control on what they see on their screen (which includes opting for the Windlight renderer if they think 50% more frame rate matters more than ”prettiness” of the sky).
×
×
  • Create New...