Henri Beauchamp
-
Posts
1,188 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Henri Beauchamp
-
-
2 hours ago, Coffee Pancake said:
That word .. It does not mean what you think it means. https://www.merriam-webster.com/dictionary/infirm
Sorry for being French... Disaffirm, perhaps ?
-
9 hours ago, panterapolnocy said:
Because EEP has a different internal structure than the old Windlight system and slider would not work -Â for fixed skies there is no such thing as âtime of the dayâ anymore.
Wrong !
I implemented the day light time slider for the EE local environment editor in the Cool VL Viewer (as well a another slider for the time of day at login).
It works just fine, but did involve changes to the default settings (using WL translated defaults that do include a day cycle, instead of the âfixedâ midday/midnight/sunset/sunrise EE defaults). This could be backported into any other EE viewer as well...
Â
-
4
-
1
-
-
3 hours ago, panterapolnocy said:
All TPVs should/must follow the Shared Experience rule
There is a basic misconception about what this rule actually means: it simply means that a TPV cannot implement a feature that would break the way things looks for *others*; in the past, there have been viewers implementing such features (e.g. non standard attachment points on your avatar, that then had the said attachments appearing in your avatar's center in other viewers) that other viewers (and especially LL's) could not render properly, which did break the âshared experienceâ for all users of all viewers but that particular TPV.
Now, what you display in *your* own viewer (as long as it does not affect what others are seeing in theirs) is *your* business. Else simple things such as local environment settings would be forbidden !
So, if you prefer how WL looks over EE, you are perfectly founded in using a WL viewer: it won't break anyone else's experience !
-
1
-
1
-
-
2 hours ago, Coffee Pancake said:
Can confirm.
Can infirm: the Cool VL Viewer will keep both renderers (WL and EE, and switchable on the fly with the same viewer binary, i.e. no need for two different viewer versions) âforeverâ, or at least until LL changes for a Vulkan renderer.
-
1
-
-
Quote
most of my car games require I have to use windows
Installing a dual boot (Linux/Windows) is also quite easy to do...
-
The GTX 1650 will be fine (anything equal or above a GTX 960 will do, even with full shadows). Just avoid AMD graphics cards: the OpenGL drivers for them suck rocks and will ruin your FPS; Linux Open Source OpenGL AMD drivers are much better than Windows', but at equivalent hardware, NVIDIA (with their proprietary driver) invariably beats AMD hands down in OpenGL graphics.
With a good enough graphics card, the bottleneck in SL clients (viewers) is the CPU, because the renderer is mono-threaded: you need a CPU that got the best possible mono-core performance (for your budget). A Coffee Lake (or better) or Zen3 CPU will give you the best results.
Also do not neglect RAM: 16GB would be today's standard for a comfortable SLing experience, and 8GB would be a strict minimum.
Â
EDIT: oh, and in case you are not allergic to Linux, do use it for SL: you'll get quite a significant FPS bonus with it compared to Windows...
Â
-
1
-
-
Sorry, double post (apparently, the SL forums are just as unreliable as groups: had to reload and it double-posted as a result) :-P
-
On 4/5/2021 at 11:12 PM, Maestro Linden said:
I would expect this change to remain in place in medium term - there are currently no plans to revert it.  That said, I would not declare the change as âpermanentâ - group chat will continue to evolve as Linden Lab evaluates its performance and tweaks the design.
Instead of baring everyone but moderators to receive the list of the group IMs participant, what about updating that list as a slow trickle (group server load permitting), serving first people who do post in the group session (so that at least they receive the full list every few minutes or so) ?
Also, I believe that at least the moderators list should be transmitted to everyone (it is important to know who are the online moderators if you get grieved, for example).
Finally, the Cool VL Viewer has, for years, been adding automatically posting group members to the âspeakersâ panel list when they are missing: such a feature could be added to other viewers as well, so that at least all people who posted in the group are (locally) listed for everyone.
-
2
-
-
This should put an end to fake news about viewers performances, and demonstrate the potential of the multi-threaded image decoder: ViewersTest.mkv
Testing protocol:
Since the choice in available (release) Linux viewers is slim, I tested Firestorm and Kokua (the very latest EE releases) against the Cool VL Viewer. All viewers running on the same PC under Linux v5.11.8 (vanilla, self-compiled kernel, with all mitigations off):
- CPU: 9700K @ 5.0GHz locked on all cores (i.e. only C0 & C1 states are allowed). No thermal throttling (well cooled CPU).
- GPU: GTX1070Ti @ 1980MHz for the GPU & 9200MT/s (=4600MHz) for the VRAM. NVIDIA current proprietary drivers (v460.56)
- Exact same graphics settings, so that all viewers use the same, common settings: e.g. no Classic Clouds enabled, 1.00 Mesh LOD multiplier in Cool VL Viewer since they don't exist in others; Objects LOD limited to 3.0 and Terrain LOD to 2.0 in all viewers (FS can do more), etc...
- EE rendering mode for everyone (Cool VL Viewer can do both EE and WL). Midday default setting.
- All the viewers' caches and log files are held on a RAM-disk.
- No other software running than the viewer and the screen capture, which does disadvantage the Cool VL Viewer since the capture software loads one or two of the cores (appear in dark green in MATE's load monitor) that would otherwise be used by an image decoder thread or two.
- Of course the âbackground yield timeâ setting was set to 0 for all viewers.
A scene with ârelatively heavyâ outdoor setting was chosen, pretty much at random, just after looking at the map for one such sim without any avatar around (in draw distance), with a bit of everything: sky, water body, land, trees with alpha textures, buildings, meshes, etc. Only one avatar on screen (alas imposed for 100% reproducibility reasons) wearing a BoM body, mesh hair, prim attachments, flexy cape (i.e. a bit of everything).
The viewers cache are primed with a first dry run (not shown), so that all textures get cached in the RAM disk for the perf measurement run.
âTexture timeâ HUD info and texture console shown. The scene is considered fully rezzed when less than half a dozen of fetches are active (some moving mobiles in DD may cause new fetches after the initial rezzing, and since they are random we won't count them).
The rezzing time is taken with ALM off, so that less time is used by the render pipeline and the viewers rez faster (the texture fetcher getting more CPU time in the main thread for itself), especially FS and Kokua which do not have a multi-threaded image decoder; those also have KDU, which is much faster than the Cool VL Viewer OpenJPEG...
At the end of each rezzing, I switched the ALM mode and full shadows on (SSAO and DOF off), so that you can appreciate the FPS rate differences as well (and so that I won't hear again some total non-sense about my viewer performances)... The Cool VL Viewer especially shines with ALM off, since I optimized most of the C++ code, but not the shaders (they are almost exactly the same for all these viewers), and very little the render pipeline (llpipeline.cpp) itself (so the CPU-hungry shadows code makes the speed gain less obvious, i.e. not 80% gain and over, but closer to 50%).
Also remark the memory consumption...
Â-
2
-
1
-
Quote
If the GPU isn't being 'fed', there's something amiss in the pipeline.
Nothing amiss in the pipeline: just your CPU slowing down when it should not, which causes the âdropâ in the GPU load, since it's not fed as much work.
QuoteYou know that the internal viewer frequency measurement is inaccurate.
It *is* accurate (at least as much as /proc/cpuinfo is) in the case of the Cool VL Viewer: my code detects which core it is running on (this is even reported in the log file) at the very moment it gets the frequency for that core. At this point, the said core should already be in turbo mode !!! It certainly is on all systems (5 different PCs) I tested it on !
Since, again, you seem to be the one and only person who tested my viewer and found it âslowerâ, I will not even bother and loose my time replying to the rest (neither to any other posts of yours): I simply urge everyone reading you, to never take your words for granted, and make their own tests instead !
-
2
-
-
Again ?...
For a start, you are diverting this thread from its original topic which is not about the GPU load, but about multi-threading. The improvement brought to the latest Cool VL Viewer version won't change a thing to how high is the GPU load (or to the frame rates) in static scenes, but how fast textures are rezzing on login, after a far TP, or while moving around (the latter even more obviously when the new âBoost textures fetches with speedâ feature is enabled, in Advanced -> Rendering -> Textures).
Second, look at the About boxes, and see how the CPU frequency jumps up and down for the same viewer or between viewers. Obviously, there is something amiss with your system(s) since as soon as any viewer is logged in and rendering any scene, the CPU freq should go to turbo for the core running the main thread and not budge from it !
Simply LOCK your CPU to its maximum frequency on all its cores to achieve the maximum performances.
One thing is certain: on my various systems, the GPU load is constant (but so is my CPU frequency) and yet well below 100% (more like around 40-70% for a GTX1070Ti, depending on the scene being rendered), even with ALM+shadows+everything on: with anything equal or better to a GTX960, the SL viewers are 100% CPU-limited; it also means that if the frequency of the CPU core running the render pipeline (i.e. the main viewer thread) goes up and down, the GPU load will follow it.
-
2 hours ago, Ansariel Hiller said:
I didn't remember that to be honest.
It was in 2011 and 2012, in IMs, in SL... I keep all the logs, since I won't accept anyone to doubt of my word, anytime, and I can always prove by A+B what I am asserting.
Total (and yes, sometimes quite blunt/unforgiving/harsh) honesty and reliability are among my intangible principles. I say what I do, I do what I say, always. Period.
2 hours ago, Ansariel Hiller said:But then it was also more of a general hint that it might be easier to provide such patches directly under LGPL
What makes adding changes from Cool VL really difficult is, that you only provide a single diff for each week's change. I don't know if you commit such a change to repository as a single blob, but going through diffs that are several thousand lines long and include several different changes among lots of reformatting of code is extremely tedious and error prone. Sometimes I have a feeling you reformat code back and fourth to obscure the actual changes.
I am an old fart (and not proud of it: just a fact of life, sadly), with 40+ years of programming experience behind me. It means that I am/keep using tools that I have been using for decades ('Nedit', 'grep', 'patch', 'diff', 'find', 'cut', 'sed', bash scripts, Perl scripts, Tcl/Tk scripts...)... I know, it looks ancient (antediluvian ?), but they empower me with a productivity that many (most ?), âmodernâ (âyoungâ ?) programmers would envy.
I am sorry, but at my age, I won't âadaptâ (read: loose productivity and efficiency) to tools such as cvs, svn, hg, git (or whatever other fancy ârepositoryâ software you can cite): I find it incredibly faster to read (yes, even with my old eyes) a ârawâ patch file (and recode it in my own way, with bug fixes and optimizations) than browsing those (or, horror: merging them and fixing merge errors), and the rhythm at which I can publish new releases (weekly, with only very sparse, part time usage of my free time), compared to the time needed by entire teams of developers to publish a release of their own viewer, should incite you to start and wonder if you are using the most efficient tools... đ
In other words: yes, you can freely reuse my code, but no, I won't provide you with a patch (or commit) that applies cleanly to your own code... Shocking, I know ! đ€Ł
PS: oh, and please everyone, get it right ! The name of my viewer is âCool VL Viewerâ (yes, âViewerâ is part of the name !), not âCool VLâ... Like in âEiffel Towerâ, you know... or âFreedom Towerâ.
-
15 hours ago, animats said:
Firestorm does that, too.
Nope ! No other viewer got it (so far); they have mono-threaded image decoding (i.e. the decoder runs in one thread, along the main program loop), but not a multi-threaded one like it is now the case for the Cool VL Viewer.
7 hours ago, Ansariel Hiller said:Looking at Cool VL doesn't really help the majority of TPVs out there at all, since Cool VL is under GPL license and except Singularity all other TPVs are under LGPL, meaning they can't easily re-use that code.
Did I ever refuse the re-licensing of my code ?... Like I wrote recently in an email to one of FS' developers:
QuoteYep, you can re-License as LGPL *all my viewer code*: I just kept the GPL because LL's v1 code was itself GPL (+ FLOSS), but since pretty much all today's code in my viewer got backported from LL's v2+ viewers or rewritten by me, with the exception of, perhaps, some parts of the v1 UI code from LL (that is no more in v2+ LGPL viewers, and that I did not touch), everything else can be re-licensed as LGPL. :-P
And you perfectly know this yourself (or do you want me to exhume the IM conversation logs we had in the past ?)...
As always, the condition for reusing Open Source code from another developer is giving credits to them.
As for Kathrine's multi-threaded LLImageDecodeThread code, you will have to ask her about the permission to reuse her code in your viewer.
-
2 hours ago, KjartanEno said:
I've been to clubs where some avatar drags the framerate down to single digits due to the ridiculously high polygon counts that the body, head, hair, and all other attachments add up to on that agent. If I wanted to be dishonest, I would put my avatar in the view while wearing some awful bit of prim jewelry barely visible to the camera, yet severely affecting the overall framerate for that particular viewer. Instead, it made sense to me that someone could cam to the same view I showed and get an idea of how the sim renders without the variable of an avatar to account for.
There is no âvariableâ when you can render the same avatars for all benchmarks. As for clubs and venues, I never seen my viewer dropping to single digit frame rates, even for venues with 40+ avatars and âimpostoringâ turned off ! Mind you, the avatar rendering is especially carefully optimized in my viewer (e.g. with joints caches indexed by integer keys instead of recursive searches down the joint hierarchy by string keys, cached attachments, cached rigged skinning matrix, etc) !
2 hours ago, KjartanEno said:I'm not sure just how many people log in and admire the exact same view every single day. Part of the fun in Second Life is moving around. I took my Bandit 170 around the waterways of Bellisseria this morning using Alchemy viewer. It was wonderful. If 'zooming around' is enough to adversely affect the framerate of Cool VL Viewer compared to other viewers, will it be a good viewer for boating?
Amusing, for someone who wrote in a PM to me on my forum (dated 2020-10-06 17:46:30):
QuoteFirst and foremost I wanted to say that when it comes to driving and boating on mainland sims, your viewer has the others beat hands down. When using the latest viewers, whether Firestorm, Kokua, or Restrained Love, and navigating the roads of Heterocera or the coastline of Bellisseria, they often become incredibly sluggish as the mesh loads, making it an overall unpleasant experience. With your viewer, I'm able to zip along nicely even as a lot of mesh and textures are loading. I don't know what 'magic' you use, but I like it!
But you missed entirely the point: since you cannot zoom in the exact same way between different benchmarking sessions, you are destroying the reproducibility of the benchmarking (one viewer could get advantaged during one session, and another viewer for the next try, depending on how many objects entered the objects list during the zooming).
Beside, keeping more objects in object cache may be detrimental to the âfixed viewâ benchmarking, but will favour the frame rate while moving and turning around. And yes, I use a different algorithm (and different parameters) for LLVOCache than other viewers.
2 hours ago, KjartanEno said:And lastly, but most importantly, it's just a viewer. It's not a Church. There is no Sin here. Code is just code, not Holy Scripture.
No, it's not a church (and I'm an atheist, so...). But obviously, you are NOT a programmer. I do put art in my coding, and take pride from it, because yes, it is chiseled sculpture, with handcrafted optimizations (I'm not just âpissing codeâ and hoping the optimizing compiler will turn the resulting crap into a fast running binary).
If you want to see the results of this optimization work (that I pursed during the past 13 years for the Cool VL Viewer), you may try and measure the âmain loopâ overhead (which determines how much time it takes for the C++ code to execute at each frame, rendering (mostly) taken apart): rez a platform at 3000+ meters (where no object/avatar will be around, reduce DD to 128m if necessary). Stand with your avatar on that platform and remove everything it is wearing (i.e. keep only shape, skin, eyes and legacy hair). Log off, then for each viewer, turn off ALM (to remove most of the GPU/shaders overhead) before logging back in, wait one minute or so for the frame rate to stabilize and compare. I get:
Cool VL Viewer v1.28.2.4 WL rendering mode: around 1320 fps.
Cool VL Viewer v1.28.2.4 EE rendering mode: around 1100 fps (yep, EE overhead is far from negligible, and I need to work more on that !).
Firestorm v6.3.9 (WL): around 700fps
Firestorm v6.4.12 (EE): around 720fps
Singularity v1.8.9 (WL): around 1080fps (taken from the log to avoid opening the stats floater which would slow things down).
I can't sadly give you a figure for other viewers (which do not have a Linux version), but last time I tried with LL's viewer (when they still had a Linux release) it was by far the slowest with below 600fps....
This gives you a little idea of how much C++ optimizations I did put in my viewer (and make no mistake, other viewers, LL's taken apart, are also carefully optimized by competent programmers). So, when you tell me it is slower than all others while, Singularity and Black Dragon excepted, all viewers use the same set of shaders (with only very minor cosmetic/rendering differences that won't affect the FPS rate), it is simply an impossibility ! And all my tests always showed it.
End of the topic, as far as I am concerned !
-
1
-
-
5 hours ago, KjartanEno said:
I'm having fun.
And you are being dishonest and obviously trying to badmouth my viewer reputation... You did not even address the valid criticisms I pointed out (zooming around before benchmark instead of benchmarking at login position, no avatar rendered).
I urge everyone reading this forum to use their own benchmarks instead of relying on your flawed numbers !
-
You know, this is getting tiring... I made my way to the sim you took the screenshot from and guess what ? At the position on your screen shot (228,182,25), I cannot see this scene: I must zoom around with the camera to see it, meaning I collect a variable amount of objects in cache doing so (it's called the âinterest listâ), which ruins any reproducible benchmarking !
Also, I told you already: you just cannot benchmark viewers using a different renderer. If you want to compare my viewer (which can do both WL and EE) with others, at least use the same renderer ! As it is, this scene (which contains a lot of alpha textures) renders faster in EE than in WL (EE can batch those textures, which WL cannot do).
And where is your avatar ?... Are you using SL without any avatar rendered ?... Mind you, avatar rendering is costly (especially CPU side) and is an important element to benchmark as well.
So, here are my results with my viewer and Firestorm (I do not have a Linux version of Alchemy, but if someone passes me one, I'll test it too), configured in the exact same way: same graphics, with EE on in my viewer, ALM+SSAO, all water reflections, no shadow, same LODs in both viewers (3 for objects, 2 for terrain, max for all others, mesh LOD multiplier set to 1 in my viewer since Firestorm does not have this), low altitude clouds (AKA classic clouds) OFF in my viewer (Firestorm does not have them and they eat quite a few FPS). The major differences with your settings are: draw distance = 256m and a 1920x1200 screen (viewer window maximized in it), one avatar on screen, with a rigged mesh body, attachments (basic prims, scuplties and meshes, plus costly flexiprims).
The results, on a 9700K @ 5GHz locked on all cores and a GTX1070Ti locked @ 1974MHz (GPU) / 9216MHz (VRAM) are as follow: Cool VL Viewer v1.28.2.4 = 55-59fps, Firestorm v6.4.12 = 31-34fps. Proofs below (the frame rate is displayed in the bottom right corner for my viewer and upper right corner for Firestorm).
-
2
-
-
This week's release notes link is wrong, in the data returned by the âServerReleaseNotesâ capability (meaning viewers cannot display the notes):
2021-01-19T15:58:55Z DEBUG: LLFloaterAbout::handleServerReleaseNotes: HTTP headers: <llsd> <map> <key>cache-control</key> <string>max-age=2592000</string> <key>connection</key> <string>keep-alive</string> <key>content-length</key> <string>243</string> <key>content-type</key> <string>application/xml</string> <key>date</key> <string>Tue, 19 Jan 2021 15:58:55 GMT</string> <key>expires</key> <string>Thu, 18 Feb 2021 15:58:55 GMT</string> <key>location</key> <string>https://releasenotes.secondlife.com/simulator/2021-01-08.554811.html</string> </map> </llsd>
While the actual page URL is: https://releasenotes.secondlife.com/simulator/2021.01.08.554811.html
(i.e. dashes are to be replaced with dots in the HTML file name transmitted by the capability, or the file name should be changed to use dashes to separate the date fields, as it used to do until now).
-
17 hours ago, KjartanEno said:
If you have an Intel cpu and Nvidia graphics, perhaps Cool VL Viewer will suit you. On my AMD Ryzen & RX 580 system running Ubuntu 20.04 MATE (with compositing turned off), Cool VL Viewer is slower than other viewers even in Windlight mode, which is an option Henri maintains on his viewer.
If you could stop making your personal (and quite unique) experience a generality !
I do not know what is your hidden agenda (and to me it furiously looks like you have a nasty one !), but you are the only person so far who dares to pretend that my viewer is the slowest (whatever the hardware) !
I tested it on multiple computers (Intel//AMD & NVIDIA/AMD alike), and it always came first or second (Singularity is sometimes faster, but Singularity got some breakages, such as water reflection and displacement maps, as well as missing features).
To be valid a benchmarking protocol must be strict; all tested viewers must render the exact same scene(s) with the exact same settings (and there are settings specific to some viewers, that do need to be adjusted to be on par with others), and you need to be able to reproduce the results several times for each viewer (if you can't reproduce the same results in three sessions in a raw, then your protocol is flawed).
Also, default settings (as well as some algorithms) may be different in other viewers than mine (e.g. regarding the objects caching, or the data fetching routines, which impact how well the viewer renders and rezzes the world while moving around, i.e. not just in a static scene), but once everything is set equal, my viewer is definitely one of the fastest if not the fastest; I have been optimizing it (and especially the C++ code) for the past 13 years, so it's no surprise, really.
Finally, you cannot compare the Windlight and Extended Environment render pipeline and shaders unless you compare them over a range of different scenes (e.g. WL is usually (much) faster, but in scenes where there are a lot of alphas, EE will be faster than WL, thanks to its alpha batching feature).
-
1
-
-
10 minutes ago, Melinat3dDiva said:
Im having the same issue also
Logins are currently disabled. See the status blog notice LL posted minutes ago.
-
1
-
1
-
-
The Cool VL Viewer v1.28.2.0 released today now allows to move or delete âprotectedâ folder types when they are not named as they should (e.g. âCurrent Lookâ is not the proper name for a COF type, which should be named âCurrent Outfitâ) or are not located at the root of the inventory.
This allows fixing this issue (and any other similar issues) while securing the genuine protected folders (i.e. you do not risk deleting or moving them by mistake).
-
2
-
1
-
-
1 hour ago, Oz Linden said:
and there is a weekly Open Development User Group in text (it's going on as I post this). Try stopping by some time.
You mean 100% text chat (I won't understand anything on voice and have no time to loose with voice meetings in English) ?...
-
53 minutes ago, Oz Linden said:
As much as I'd like to take credit for it, we didn't do anything.
This does not bode well for the future, then... If LL is unaware of the cause (meaning it would be on AWS' side and they did not communicate about it with LL), it will likely reproduce. đ
One of the drawbacks of the whole âupliftâ thing...
-
1
-
-
Good news !
The SL-AWS slow/failing servers replies seem to have been solved during the night (i.e. yesterday's afternoon, SLT) !
Everything is back to normal for me, with fast logins, snappy rezzing and (non-failing) TPs, reliable inventory operations, baking, etc...
I'm still curious about the origin of that issue... So, if a Linden could elaborate about it...
Â
12 hours ago, Aishagain said:@Anna Nova The thing is, Anna, that LL have a very good and reliable Bug Tracking system in the JIRA and they rely on reports from folk who know what they're talking about, like Henri to give them firm evidence of problems which possibly do not affect everyone. Henri's experiences plus his insight into what âmightâ be the cause or cure are vital to their clearing up problems in SL.
Sadly, the JIRA is (and by far) not the best place for TPV developers to be heard (and even less listened to) by LL... Your issue gets lost in an ocean of other issues, with much less relevant/pertinent info given in the latter, and the JIRA triagers won't even know who the said TPV devels are or how valuable are their reports.
I have much better luck with comments in the commits to LL's viewer code (as a mean of preventing future SL bugs, by pin-pointing them in pre-release viewer code), with messages posted to the opensource-dev list, or on this forum. My posts in the latter two media are pretty rare occurrences, and usually denote a catastrophic degradation that require urgent attention from LL.
As for the viewer bugs, the JIRA is of little to no use as well for me, as a TPV developer: I do not even have (even a read-only) access to most JIRA issues (not even those referenced in LL's viewer commits !), and anyway, when I find a bug or got one reported to me, I fix it myself for my viewer (since it's Open Source, anyone could benefit from my fixes as well, should they care to have a look at the weekly diff and change log I publish for each new release).
<rant>There are the TPV devel group meetings, but sadly they are held on voice, meaning non-english speakers like me cannot attend them (well, they can, but won't understand half of what is said)...</rant>
<nostalgia>In the distant past (before Oz' era), these meetings were held exclusively in text chat, letting everyone a chance to understand and express themselves (via translators if needed), whatever their nationality</nostalgia>
-
1
-
1
-
-
1 hour ago, Keishaa Meili said:
Uh oh. So it seems that when I finally could SEE myself (and be seen by others) I just had a HUGE moment of luck. Anyway, I'm sure I had the Metachat problem, because I just still can see the offending folders (the infamous Current Look ones) in the inventory.
As I see it (from a long time (13+ years) SL viewer developer), the problem is that the âCurrent Lookâ folders you have in your inventory bear the same type code as the genuine âCurrent Outfitâ (COF) folder: there is normally only ONE such folder at the root of your inventory, and when dealing with the COF, the viewer (and probably the sever alike) simply scans the root folder of your inventory for the first (and normally only) folder with the COF type code: and uses it for all baking operations.
Depending on the order in which the folders appear in your inventory (this is not the sort order but the order in the inventory tree), any of the three folders you got could be found by the viewer and/or the server, and there is not even any guarantee that both the viewer and the server will find the same folder when rebaking, meaning the viewer will update one folder with what you are wearing and the server might look in another for what you are wearing !
It means that, by pure luck , you could happen to have both the server and the viewer updating and using the same COF-type folder for one session, and not for the next ! Add to this, the folder version issue (that I explained in my former post) and in fact you can only see your avatar baking when the genuine COF is found first by both the viewer and the server: good luck with that !
The method I described in my previous post (patching a viewer, compiling it, and using it to get rid of the âCurrent Lookâ folders) should solve your issue. Else, you'll have to wait until LL writes a script, tests it, and runs it on your inventory database...
Facebook
Instagram
Twitter
YouTube
Flickr
Environmental Enhancement Project (aka EEP!) Feedback Thread
in Environmental Enhancement Project
Posted · Edited by Henri Beauchamp
You won't have any issue with my viewer... It automatically translates EE settings to WL settings and vice-versa to render them. Sure, you do not have fancy Moon and Sun orbits, changeable Moon and Sun diameter and other such EE-only settings in WL rendering mode, but it displays EE settings fine nonetheless in WL rendering mode (and vice versa) !
If, like me, you spend most of your time in indoor scenes, you won't even notice a difference, but for your fps rate (usually significantly higher in WL mode, with the exception of scenes with lots of alpha textures which the EE renderer can batch, unlike WL).
I believe in freedom of choice. Why would I suffer lower performances when I do not care for EE fancy settings ?... On the other hand, it seems natural that I can see the effect of those fancy settings in EE mode whenever I want or need it. Thus my choice of a dual-renderer for my viewer. It can do both, so there's no loss for its users ! đ