Henri Beauchamp

Ah, if you speak about the PBR viewer with legacy material vs legacy viewer with legacy material, then yes, the PBR viewer renders it much more like latex, but it renders the PBR material properly, like leather... This is indeed the thing that annoys me most, for now, with the PBR renderer: it renders very badly legacy contents ! See: BUG-234816 It also recently broke shadows: BUG-234564 And finally renders water bodies like sh*t (artifacts when enabling water reflections, water is ”sky blue”, waves are not as pretty as with WL/EE, etc)... But hopefully, these bad rendering discrepancies will get fixed over time... I just wish LL had kept the PBR viewer longer as a RC, until these bad issues would have been properly fixed.

It depends if you prefer latex (the legacy render looks like it) over leather (the PBR one), I guess... 😛 But what would be interesting to know is whether this piece of furniture is supposed to be made out of one or another (or none of them, which would be rather embarrassing 🤣 )...

Oh, you mean that crash with the version checker ? Yes, it always crashed for me under Wine... But, you can simply delete SLVersionChecker.exe (or whatever they call it exactly), and the viewer will then start just fine: it will complain that it can't start the version checker, but will keep running nonetheless. As for the CEF plugin, it should work... It does for me.

Only 200 fps ?... I can reach 1500 fps (in forward rendering mode) ! 🤪 More seriously (and usefully), do make use of the smart frame rate limiter: it will keep your PC cool and quiet and will even allow you to rez faster (thanks to the ”smart” part) ! ”Preferences” floater -> ”Cool features” tab -> ”Misc.” sub-tab, ”Frame rate limit” spinner.

IIRC, the systematic crashes were seen with v7.1.1.something...

I warned @Vir Linden about this crash fest under Wine, at the last Open Source development meeting. I suggested him to check what MSVC version was in use to build the viewer on github: MSVC1937 is the culprit for systematic crashes I myself saw happening with my own viewer (and I had to do an emergency update with a build done after I reverted my build system to MSVC1936, which Micro$oft exceptionally allowed in the VS installer, demonstrating they knew their 1937 version was bogus). MSVC1938 has since been released and does not cause crashes any more... This is not to say that the crashes you are seeing are indeed due to this (potential) issue, since this could just as well be some code in LL's viewer triggering a Wine bug (it won't be the first time), but I now can run the latest official viewer I downloaded (v7.1.2.7215179142) without seeing it crashing every few seconds under Wine, so either LL updated from MSVC1937 to MSVC1938 on github, or the new viewer version is not triggering any more a Wine bug...

Default diffuse = plywood texture, which I also extended to default blank texture (since I saw many such blank textures on PBR objects in Aditi Rumpus Room sims). When replacing default diffuse is selected and the viewer renders in ALM or forward modes (i.e. not in PBR mode) and notices that there is a PBR material with a base color map (texture), and that the diffuse texture is a ”default” one, then it picks up the base color map (and its color, scales, offsets) to render instead of the diffuse texture. When always replacing diffuse is selected and in ALM or forward render modes, and the face got a PBR material with a base color map, then the viewer systematically uses that base color map to replace the diffuse texture, even if the maker of the object did provide one as a fallback: you can see in this post why I added this mode/feature (which would be useless if only the fallback diffuse texture (and color) was always properly synced with the GLTF material, but such a thing is sadly not guaranteed to happen especially because of BUG-234896, which will make it hard for creators to keep things in sync when they update or modify their builds).

For ARMv8-A Chromebooks, and provided you run Linux on them, you might actually be able to run the Cool VL Viewer aarch64 Linux build (which is designed to run on ARMv8-A SBCs)...

As usual, as long as proper credit is given, any viewer can (and is welcome to) reuse my code in theirs (this includes my permission to re-license my code as LGPL when needed). Be warned however that this hack supposes your viewer already implements GLTF material support (i.e. it can fetch the said materials from servers), which is not the case of current non-PBR viewers...

See this post and the Cool VL Viewer v1.32.0.4, published today.

Because you would not accept to be forced to go to a racetrack with a 1995 Toyota Corolla when you do not want to go to that race track in the first place ?... 😮 Not everyone can afford buying a new computer every 5 years, you know...

They would still see it in the texture control, in the edit floater. it's a bug. Period.

Yes, viewers can run with Intel iGPUs, but they will render dead slow with them, slower than with your AMD GPU. This is why, on a desktop system (which does not need to save power on batteries) equipped with a discrete GPU (a graphics card), it is best to disable entirely the iGPU from the BIOS/EFI: this way, you do not risk to see a software picking up the wrong GPU to render and end up being too slow; it also lowers a bit the heating in the CPU (the iGPU transistors being powered off) and allows for a slightly better boost frequency. Hitman is using DirectX, not OpenGL like the viewer needs... The fact you installed a very new driver on a very old card (2015 !) is likely the cause of your issue: try and roll back your driver to one published a couple years ago, or even 5 years ago, and see how it fares. The card can display the 2D desktop, even without a 3D driver: what you need to run the viewer is a proper OpenGL driver for your card.

Because the PBR rendering engine (shaders and render pipeline) is different from the previous one. To preserve all options in the Cool VL Viewer and make the transition easier for people with ”weak” hardware or hardware/driver not capable of rendering PBR at all, I implemented a dual renderer in it (with two sets of shaders (EE and PBR) and branching in the render pipeline), and you can switch between all three modes (PBR, ALM, forward rendering) in real time.

If you got a desktop PC (which the mention of a monitor would strongly hint for), then you might want to disable the Intel iGPU from the BIOS/EFI, so that it won't wrongly be picked up for rendering 3D games/applications (and then you can also uninstall the Intel graphics driver under Windows). As for the AMD card and the viewer message about its driver (should you still get it after disabling the iGPU), it might be the result of the new (reinstalled) driver not providing a valid OpenGL version any more for this old GPU... You would have to find the same driver version as the one that got spuriously uninstalled to fix the issue. Alternatively, try another TPV (the Cool VL Viewer should still work with any OpenGL v2.1 and better graphics cards, but some v2.1 drivers may still lack necessary features and might not pass either).

Thanks for the trick; so it is at least possible, even if quite convoluted... In contrast, my viewer offers a ”Reset material” button (which works both for ALM or PBR materials) in the ”Texture” tab of the Build floater)...

Which is a bug, like I reported in BUG-234896: how can you change the diffuse texture or its color after applying a PBR material to a face ? Well, you can't, short of removing the PBR material (which I don't even think is possible in LL's viewer, but is at least possible with mine) ! This is going to lead to a lot of PBR contents without proper diffuse textures, or with colors not matching between non-PBR and PBR viewers, just because the creator will be incapable to resync them after creation and modifications. This can already be seen in Aditi (Rumpus Room 2, IIRC); see this example (*), where the walls and ceiling of the house got different colors despite the fact they bear both a diffuse texture and a PBR material. Please, LL, fix this bug ! --- (*) Yup, tomorrow's Cool VL Viewer release will have this new hack to display base color textures instead of diffuse ones (for missing (plywood/blank) diffuses only, or always, at user's whim) in non-PBR rendering modes (**). (**) Reminder: the Cool VL Viewer can render both with PBR and without (and in either ALM or forward modes in the second scenario); @Quartz Mole this should make it even easier for you to test rendering of what you, ”Cool Moles” (no, I won't claim the trade mark on this one ! 🤣) are building: no need to launch two viewers in a raw any more... And for tomorrow's release, I even added a keyboard shortcut for toggling PBR, with CTRL ALT P, which adds to the existing CTRL ALT D shortcut for toggling ALM (with 'D' for deferred) too. 😜

Excuse accepted. 1.- It is not condescending to state verifiable facts and share a (long) experience (you know, the ”been there, done that, and no, not working” kind). 2.- I never used, and will never use, the nationality, the culture, the supposed level of instruction, or whatever characteristic of a person to make assumption about their competency, like you just did. THIS is highly condescending, unrespectful, and a totally unacceptable behaviour, as far as I am concerned, and against all my principles. In the tread you mention, when you disregarded the experience I shared with you, I simply gave up and you already replied in a very condescending and unrespectful way. You also did the same kind of unrespectful replies in other threads towards other members of this forum who did not deserve such a thing (e.g. towards Coffee Pancake, criticizing ”experts” when no one, ever called themselves an ”expert” in the first place). 'nuff said.

I do not appreciate your condescending tone ! Not to mention I do not see what philosophy (*) got to do in the ”picture” (pun intended). I will therefore not bother replying (and loosing time) all your blah blah. You are just making publicly a fool of yourself, I'm afraid... Case closed, as far as I am concerned. ----- (*) And if you want French philosophy, try Descartes, with Catésianisme and Rationalisme : they will be of a great help for you.

It's not my opinion, but my experience: 17+ years of SLing, 16+ years of viewer testing, benchmarking, profiling, and code development, fine tuning, optimization, and the feedback from quite a few users of my viewer. You can try and make up reasons, but the facts are contradicting your initial claims: fact is that texture compression is causing fps hiccups (because the compression is done by the OpenGL driver, which cannot use a texture while it compresses it). Another fact is that texture compression is lossy and causes texture artifacts and blurriness. The reason why my viewer consumes less memory stems to the many optimizations I brought to its code, with a full rewrite of some parts of LL's code. In particular, the texture discard bias algorithm has been revamped and made ”smarter” (it can anticipate VRAM memory overshoots and it better settles to the right discard bias value for the rendered scene, avoiding ”texture trashing” often seen in other viewers). This said, with the right parameters (i.e. reducing the ”texture memory” to a reasonable fixed amount, like 3GB for a 8GB VRAM card), you can convince most of the other viewers (*) to use less VRAM and avoid overshoots and trashing; you will simply have a less pretty render (more blurry textures) than with my viewer. (*) Not the PBR ones reusing LL's newest texture fetcher code, sadly, since LL pretty much destroyed any mean to adjust the texture memory manually in their new code. 🙄

Exactly why it is a bad idea to enable texture compression when, like me, you move a lot around and do not just stay still in one place... Texture compression causes awful FPS hiccups when driving, sailing, or flying. Even for people staying in the same sim, the ”hiccups” will happen when they move around (and especially turn around) or cam around, since textures are being re-loaded from the disk cache, then re-compressed to fit in the VRAM each time your camera FOV changes. If you do have enough VRAM (*), just do not use texture compression. Period. (*) With 8GB of VRAM and using the Cool VL Viewer, I can deal with pretty much any situation without using texture compression, including venues with 300+ avatars like what I experienced during SL20B public meetings.

The server might accept an ”object return” request (or auto-return timeout) from a neighbour when the said object merely overlaps their parcel border (i.e. even when the root prim of your object is well within the limits of your own parcel). This might be your problem, here...

This is already the case... I do not see any need to further movement restrictions, as long as you have the appropriate age for the rating. But LL could easily implement a way to forbid any connection to sims not corresponding to the logged in user rating, to prevent even rezzing in the distance of anything they are not allowed to see...

The channel could be several sims long (such a channel already exists between Sansara and Heterocera, between Nautilus and Corsica, and between Corsica and Gaeta V: the one to Zindra could even be longer if at all needed), and be rated adult all along. This way, there is no chance some non-Adult could ”cam between” (and even less move) to Zindra, coming from G or M rated seas... Note also that, server-side, LL could implement (if not already done) a restriction for non-Adult accounts, forbidding the Adult sim servers to connect at all with a viewer logged in with a non-Adult account.

Well, for a start, it would be nice if Zindra (the continent hastily built to host the Adult refugees after the demoting of all the ”Mature” main land sims to ”Moderate” status), could get some love from Lindens and Moles... I mean, we really need it to be brought on par with older main land continents (with public rez zones on roads at each sim border, better public buildings, the addition of water sims and protected water channels to allow sailing all around the continent, the addition of land sims with some hills and mountains, etc). Also, why not moving it closer to the other continents on the grid (it's just an offset to change in sims coordinates), and link it via an ”Adult channel” to the rest of the SL seas ?... That would be a good start for LL to finally acknowledge the fact that without Adult activities, SL would already be dead and forgotten !