KjartanEno

Firestorm 6.4.5 beta does have EEP (and so do some other third party viewers like Kokua). Personally, I'm looking forward to Love Me Render RC becoming the default release, hopefully soon. The sun and moon specularity has been fixed now, in my opinion, in LMR RC. There may still be some work to do fixing the presets, especially sunrise and sunset, but otherwise it's looking very good. LL's current release viewer and the TPV EEP viewers still have very dull looking sun and moon specular shine, which looks rather unnatural especially when compared to the point and spot lighting shine. Firestorm 6.4.5 beta EEP image: Love Me Render RC EEP image:

It can be frustrating when looking at new releases only to realize that the creator doesn't offer clothing to fit one's body. Slink is well established, having been available for years now. One would think that it should get support from clothing mesh makers, but I have also found an apparent decrease in releases that fit Slink male. That being said, I've got a lot of clothing already from Lapointe & Bastchild, Legal Insanity, FashioNatic, and many others. I still buy items from Gild and PFC, for example, that fit Slink even though they no longer make new clothes for the body. There is a lot to choose from already, but I feel your concern.

Skins for Bakes On Mesh require textures for the head, torso, and lower body, all using the SL UV layout for system avatars. You create a skin right in your inventory. Your customer simply wears it, no scripted appliers or relays required. If you can find high quality templates to purchase in the marketplace or in world, it can substantially reduce the work involved. Beware cheap templates since they offer few options, may be blurry or low resolution, and worst of all could be stolen content. You will pay for quality, but then your end product will sell based on the quality you offer and word of mouth recommendations from your customers. Templates often come in PSD format for use in Photoshop. If you do not own Photoshop, there is a free to use browser based image editor that can open PSD files called Photopea. I've used it from time to time for those files that have adjustment layers which GIMP cannot handle. GIMP is my preferred image editing application. It is free and does almost everything I need it to (aside from the adjustment layers I mentioned). High quality templates will have options for heads including many eyes, lips, noses, and other ways to shape the face. The idea isn't to simply show and hide layers, however. Hopefully you'll experiment and create something unique that goes beyond the source templates you use. When it comes to differences between heads, the most noticeable thing is how the lips look. Catwa in particular has fuller lips than any other mesh heads. If you sell skins that are intended to fit many heads, you need to test your skins on those heads and put the options as different skins in your product. Including shapes would be a good idea as well. Being Bakes On Mesh skins, you could also include extras such as tintable lip tattoo layers, eyebrows, and a basic hairbase. I can't stress this enough: Know the market you intend to sell in. Buy skins from creators that you like and examine the product critically. See if you can do better! Edit: Even more important!! If you see a template for sale in the marketplace, the PSD files that you get would come in a separate download link. Contact the seller in world to make sure they are ACTIVE before making such a purchase. If the download links no longer work, you need to be able to get help, and an inactive seller can't do that for you!

Now for some fun with EEP... These images aren't about the skies, however. These images were captured with the Love Me Render RC viewer (in Windows) to show how the new specular changes look. There is only sunlight causing the shine on surfaces in these images. In most places it would be hard to render a lot of scenery due to the texture thrashing that LL's viewers can experience. So, let's go sailing! 1 2 3 4 5 In all but the last picture, the avatar has a 'wet' effect applied to the 'tattoo' mesh layer over the main skin mesh layer. In the last image, the avatar only has the BoM skin with normal and specular map materials.

Here is a script that creates the materials seen on the prim I've been showing: default { state_entry() { llSay(0, "Click to change my texture and materials."); } touch_start(integer total_number) { llSetLinkPrimitiveParamsFast(LINK_THIS,[ PRIM_COLOR, ALL_SIDES, <0,0,0>, 1.0, PRIM_TEXTURE, ALL_SIDES, "5748decc-f629-461c-9a36-a35a221fe21f", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0, PRIM_NORMAL, ALL_SIDES, "473d11b5-8080-1061-b916-8695e34b301e", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0, PRIM_SPECULAR, ALL_SIDES, "41ed9bea-e332-f96b-7861-e94c4b741138", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0, <1,1,1>, 255, 255 ]); } } Another useful test object anyone can create is a black sphere. Once you have a sphere and have made the diffuse color black, set a blank specular texture, a white specular color, glossiness 255, and environment 0. Use the sphere to see how the reflection dims as you set the sun and moon closer to the horizon in production EEP, while the reflections stay bright in Love Me Render. The Love Me Render EEP Sunset can be made to look like a WL Sunset if one edits personal environment settings. What I'm seeing in my tests is that Love Me Render increases the maximum sun/moon brightness achievable with the settings. It also makes it possible to get that level of brightness even when the sun or moon is on the horizon. Since the maximum possible brightness has increased, any environmental settings already created will look brighter in LMR than production EEP viewers currently show them. This will make specular materials appear to have more shine under sun/moon lighting, and it appears to allow a higher scene contrast. In the images, Kokua is set to twice the 'normal' sun luminescence to get about the same brightness on surfaces and specular shine on materials as the image taken from Love Me Render RC. It's not just about brightness, though, because there are other differences in the way that shine is being calculated along the specular exponent and environment (mirror-like shine) component. https://www.dropbox.com/s/euwdqamq2ai6ori/Kokua647-Midday-x2.png?dl=0 https://www.dropbox.com/s/tn8uco3xyjm5ayt/LMR-Midday-Default.png?dl=0 So, yes, the existing Sunrise and Sunset presets will appear to be broken because of some changes. The issue to fix isn't the shine, it's that the presets need to be adjusted to the new lighting intensity, in my opinion.

Adding to my previous post, one more image showing EEP sunset specular shine in the just released Kokua 6.4.7. This is sun/moon light only, and it's the current state of EEP, not counting Love Me Render. You would see the same result in Firestorm 6.4.5 beta as well. https://www.dropbox.com/s/3jb5gyhqh8sjb2v/Kokua647SpecularSunset.png?dl=0 Now THAT is totally unacceptable, even if the colors are more aligned with what is seen in a WL viewer. The top of that prim should be at least as bright and reflective as the image taken in Alchemy viewer (see my previous post). EDIT: I started playing with the personal lighting in that scene. The Sunset preset does indeed have a very weak looking sun on current viewer releases, and there appears to be no way to increase the sunlight's brightness enough to make it look like WL Sunset. However, I moved the sun higher in the sky and cranked that sun brightness to the max... and the result shows that a strong sun specular shine is possible in the current release viewers. https://www.dropbox.com/s/f3tgztq64a1rabv/Kokua647SpecularShine.png?dl=0 @arton Rotaru, I am not so sure that Love Me Render is fixing the specular so much as changing sun & moon light settings overall. Making it possible to set the sun brighter will in turn 'fix' the lack of specular shine. @Stevie Davros, I think you are 100% correct. It's not the shine that's broken, it's the preset.

Here are a few images using Alchemy 6.3.6 (Windlight) and LL's Love Me Render RC. There is a flat normal texture with a gradient of 0 to 255 in the (8 bit) alpha channel and a specular texture with black, dark grey, light grey, and white, which is repeated on each half. Additionally the specular texture has a gradient in the alpha channel going in different directions on each half. The diffuse color is black. http://wiki.secondlife.com/wiki/Material_Data What you see in the images: 1. The bottom of the prim has dull reflections, and the top of the prim has sharp reflections. "A higher alpha value [in the normal map] will result in specular highlights that are brighter and tighter." - Wiki 2. The top left and bottom right will show environmental reflection (that mirror-like shine), and the bottom left and top right will have no environmental reflection. "A lower value in the alpha channel [of the specular map] will diminish the impact of the environment map reflections on the surface of the object." - Wiki https://www.dropbox.com/s/rhtwumxk49i0fva/AlchemySunsetSpecularTest.png?dl=0 https://www.dropbox.com/s/uiq6kv5c10jc0e2/AlchemySpecularSunset.png?dl=0 https://www.dropbox.com/s/rqpevfr8hgr06jl/LoveMeRenderSpecularSunset.png?dl=0 I could post an LSL script to apply the UUIDs of these textures to a prim if anyone is interested. As seen in the images, EEP Sunset is definitely not the same as WL Sunset. To do further tests, I want a Linux viewer like Firestorm with this update. I'll have to keep an eye out on the Firestorm development updates to see if and when it gets these changes, and then I'll compile a personal version for testing. I need more extensive testing without the 512MB texture memory limit of LL viewers, and Linux viewers run significantly faster on my system. I have some more personal benchmarks that I made today in Windows, and the results were surprising to me. (Hint: Windows is a slug!)

I booted up the Windows 10 partition on my computer and then did some stuff in RL. By the time I got back to it, things had settled down. I got the Love Me Render viewer to update, and I downloaded several current TPV to continue my benchmarks. More on the benchmarks in another post, since at this time I want to make some observations on the sun/moon specular shine fixes. I have to say, in my opinion it is much better. While the sunlight specular is stronger than it had been in the WL viewers, at least I can say now that the sun actually shines. It is proportional to the spot/point light specular shine now, in my opinion. I think I can work with it. I guess the question remains whether, as arton Rotaru says, they are too strong, and thus breaking a lot of existing content. I would have to see these changes ported over to Firestorm's code so that I can compile a version usable on Linux. Then I would be able to make more extensive tests. Below are some images I took using the Love Me Render viewer. My avatar's skin uses alpha channels on the specular and normal maps to vary specular hardness and environmental reflection amount. As a result it is by no means a uniform flat shine. https://www.dropbox.com/s/6d57m2sswr5ge53/LoveMeRender-Spotlight_Only_1.png?dl=0 https://www.dropbox.com/s/3ap0tqghk0jov0d/LoveMeRender-Spotlight_Only_2.png?dl=0 https://www.dropbox.com/s/2swwldjn2vmo7vz/LoveMeRender-Sunlight_Only_1.png?dl=0 https://www.dropbox.com/s/slky5pzkdjm8b8h/LoveMeRender-Sunlight_Only_2.png?dl=0

I have an update on the whole adaptive sync issue. My monitor has an OSD option to display the current actual framerate. When running any viewer, it remains at 144Hz. Furthermore, adaptive sync only works on full screen applications that are not blacklisted in the file /usr/share/drirc.d/00-mesa-defaults.conf. To be sure, I added the lines: <application name="Cool VL Viewer" executable="cool_vl_viewer-bin"> <option name="adaptive_sync" value="false" /> and ran Cool VL Viewer in full screen mode. There was no effect on the framerate. I still got ~20 fps in EEP rendering while the monitor showed 144Hz. There was no adaptive syncing. I have inserted the line "export vblank_mode=0" in the cool_vl_viewer launcher (in place of the Nvidia specific launch options). There is no vertical syncing to presumably lower the framerate. Furthermore, at the same location where I ran my tests yesterday, I ran Cool VL Viewer in windowed mode and made the window approximately 1280x720. The framerate stayed at ~20 fps. This is not a GPU limited scenario. This is renderer code slowing things down.

I may have to log into Windows and check the Love Me Render RC out. Whether you feel it is too strong or too weak, what I'm looking for is consistency between point/spot lighting and sun/moon lighting. The former is still stronger than it was in WL viewers, and many do find "shiny" = "pretty." No doubt further adjustments will be made.

@Henri Beauchamp, I included links to images to show that the viewers are rendering almost identical scenes in case anyone wants to compare. The framerate is also visible since these are screenshots of the desktop. Current Mesa drivers on Linux support a tear and stutter free variable refresh rate for modern AMD GPUs when used with DisplayPort on adaptive sync monitors. It is what it is, and I've said all I had to say.

Since you suggested it, I did some tests at that location. Lovely place. I'm more interested in the differential between viewers on my computer, which may or may not be representative of the experience of other residents. So, consider this a personal benchmark. Images are included at the links below. Rather than using someone else's settings, I use what I'm accustomed to. As Henri says, benchmarking is an art. My settings across all viewers in this test, which is fairly typical of my general usage: ALM, SS Ambient Occlusion, Terrain Scale High, Shadows: Sun/Moon + Projectors, Object-object Occlusion, Water: All Avatars and Objects, Avatar Physics Max, Draw Distance 128m, Max Particle Count 3072, Max non-impostor 12, Post Process Quality Max, RenderVolumeLODFactor 2.0, Flexiprims Max, Trees Max, Avatars Max, RenderTerrainLODFactor 2.0, Sky Max, Hardware Skinning, Terrain Detail High, Anisotropic Filtering Enabled, Antialiasing 2x, VSync Disabled, Texture Memory 2048 MB, Enable OpenGL VBOs, Enable Stream VBOs, No Texture Compression, No DoF, 1920x1048 windowed, and mesh multiplier LoD factor set to 1.0 on Cool VL Viewer. Environment set to midday for consistent shadow rendering framerates. (EDIT: It would seem that Firestorm 6.3.9 was not at midday, but close enough that I consider the result acceptable.) I cammed around upon login to rez the surrounding mesh and textures on each viewer so as to provide a consistent loading of the entire scene as would be typical of normal usage. I have my own scripted avatar camera control. Pressing ESC (SHIFT+ESC in Cool VL Viewer) puts the camera in the same location. I allowed the scene to settle down for a few minutes after camming the surrounding areas before arriving at the framerates I've recorded. I press CTRL+9 for the default field of view. My system is running Linux, kernel 5.5.12-desktop-1omv4001, Mesa 20.0.7. I have a Ryzen 1300x (4 cores) @ 3.575 GHz, MSI B450M motherboard, 16GB (2x8) DDR4 3200 RAM (@3200 in BIOS), Sapphire Nitro+ SE AMD RX 580 8GB. My monitor is 1920x1080 144Hz adaptive sync. All viewers were tested with operating system in Performance mode. I've attempted to make as fair of a comparison as possible. These are all from the official downloads. Clearly EEP presents residents with a real framerate hit. Whether further code optimizations can improve the current state of things remains to be seen. Singularity 1.87.8193 WL 32 fps Firestorm 6.3.9 WL 27 fps Firestorm 6.4.5 EEP (beta) 22 fps Cool VL Viewer 1.28.0.6 WL 24 fps Cool VL Viewer 1.28.0.6 EEP 20 fps https://www.dropbox.com/s/w0ufziaq3soqesc/CoolVLViewer12806EEP.png?dl=0 https://www.dropbox.com/s/mc2dhtgix5zj6by/CooVLViewer12806WL.png?dl=0 https://www.dropbox.com/s/39bpry6fkvh83q9/Firestorm639.png?dl=0 https://www.dropbox.com/s/h1ql39e6da3trs4/Firestorm645.png?dl=0 https://www.dropbox.com/s/kz7kao79x0eyl6n/Singularity1878193.png?dl=0

Which apparently only affects the performance of Cool VL Viewer? Come on, Henri, I want to work with you on this. You're a smart person. This is a puzzle. I want to figure it out. Fine. It's your viewer. I'll lurk, following progress and updates, and leave it at that. Posting a personal TPV benchmark of all current Linux viewers comparing EEP to WL on an EEP feedback thread is off topic? 🤐

Alrighty then, so we are comparing WL and EEP performance as they stand among the currently available viewers. I cannot provide any meaningful information from the official LL viewer on Linux, so here it goes. As I've said before, I use all of these viewers, some more than others, because they all do things that I like. I want to see things improve, but that takes meaningful discussion. It's easy to pick favorites and join teams. I'm not on any team. I just want the facts. All measurements were made in the exact same location, with the exact same avatar (fully mesh, HUDs and all), with as close to the exact same settings as possible: 128m, full ALM with ambient occlusion, shadows, anisotropic filtering, antialiasing, etc., in a skybox. Trust me that if I can run Linux for a decade and Second Life viewers since 2015, I'm not a newb at settings. Firestorm 6.3.9 WL 108 fps official download Firestorm 6.4.8 EEP 86 self compiled in Ubuntu 16.04 -O3 -AVX2 Kokua 6.4.6 EEP 89 official download Singularity 1.8.7.8193 WL 125 official download Cool VL Viewer 1.28.0.6 WL 85 self compiled in Ubuntu 16.04 -O3 -AVX2 Cool VL Viewer 1.28.0.6 EEP 70 self compiled in Ubuntu 16.04 -O3 -AVX2 RenderWaterCull=1 (EE&ALM only) Cool VL Viewer 1.28.0.6 WL 83 official download Cool VL Viewer 1.28.0.6 EEP 69 official download RenderWaterCull=1 (EE&ALM only) Perhaps my Ryzen system doesn't like Henri's official release being compiled -O3 for his own Intel CPUs, which could include all his precompiled libraries? Cool VL Viewer (official release): Built with: GCC v4.8.5 Compiler-generated maths: SSE2. Compile flags used for this build: -O3 -fno-delete-null-pointer-checks -falign-functions=16 -falign-jumps=16 -fno-align-labels -fno-align-loops -fno-ipa-cp-clone -fsched-pressure -frename-registers -fweb -fira-hoist-pressure -DNDEBUG -std=c++11 -fPIC -pipe -g -gdwarf-2 -gstrict-dwarf -fno-var-tracking-assignments -fexceptions -fno-strict-aliasing -fvisibility=hidden -fsigned-char -m64 -mfpmath=sse -fno-math-errno -fno-trapping-math -pthread -fno-stack-protector -Wall -Wno-reorder -Wno-unused-local-typedefs -Werror -D_GLIBCXX_USE_C99_MATH=1 -DLL_LINUX=1 -D_REENTRANT -DXML_STATIC -DLL_USE_JEMALLOC=1 -DLL_ELFBIN=1 -DLL_LUA=1 -DOV_EXCLUDE_STATIC_CALLBACKS -DLL_FMOD=1 -DLL_OPENAL=1 -DLL_SDL=1 -DLIB_NDOF=1 -DLL_X11=1 Compared to the much faster Singularity: Singularity Viewer (official beta, because I had an issue with the later releases, for now): Singularity Viewer (64 bit) 1.8.7 (8193) Feb 7 2020 09:30:16 (Singularity Beta) Release Notes Grid: Second Life Built with GCC version 40904 Second Life Server 2020-08-08T03:54:43.546455 Release Notes CPU: AMD Ryzen 3 1300X Quad-Core Processor Memory: 16026 MB OS Version: Linux 5.5.12-desktop-1omv4001 #1 SMP Fri Mar 27 17:10:50 UTC 2020 x86_64 Graphics Card Vendor: X.Org Graphics Card: Radeon RX 580 Series (POLARIS10, DRM 3.36.0, 5.5.12-desktop-1omv4001, LLVM 9.0.1) OpenGL Version: 4.6 (Compatibility Profile) Mesa 20.0.7 RLV Version: RLV v2.8.0 / RLVa v1.4.10a libcurl Version: libcurl/7.48.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 J2C Decoder Version: OpenJPEG: 1.5.2 Audio Driver Version: FMOD Studio 2.00.07 Dullahan: 1.1.1320 / CEF: 73.1.12+gee4b49f+chromium-73.0.3683.75 / Chrome: 73 Packets Lost: 0/1426 (0.0%)

It is quite possible that I've got some setting somewhere which makes your viewer slower for me. I know your viewer should be faster. I use all current viewers that are available for Linux. Each one does something I really like, but none of them does everything perfectly. Perhaps we can continue this off topic discussion in your forum.

@Pat Perth, point taken. My comment was too harsh on coders, however. Writing good code is an artform in and of itself. Sometimes it takes a bit of back and forth to find that happy medium. That being said, I wonder if those who are writing the code really look at the results using standardized measurements. The easiest and most obvious thing to do is create a gradient 24 bit specular texture, but materials are more complex than this. For example, create a flat normal map with an alpha channel gradient for the 256 levels of specular exponent. This should mean that entire range of the specular hardness can be set in the alpha channel of the normal map, if my understanding of materials is correct. Such a texture applied to the normal map of a prim under sun/moon lighting should therefore show a consistent result in line with that same prim under a spot light. Likewise, the alpha channel of the specular texture can be a gradient to show how the transition from direct light to environmental reflection is being handled. No matter what might be considered 'ideal' from the perspective of a coder who has experience with renderers, or 'pretty' at first glance to a casual user who likes 'shiny,' the fact is that a huge amount of content was made using the Windlight renderer. If the data contained within the 32 bit normal and specular textures worked in a consistent and predictable way on the old renderer, why was it changed in the new EEP renderer? I am quite curious about things like renderers and shaders. Thing is, I could easily go too deeply down this rabbit hole, and I've got way too many other things to do!

I create specular and normal texture sets for my avatar's skin, and I keep hoping for a change in the sun/moon shine. It is most apparent when using dark skins. As any artist in traditional media would tell you, dark skins are not of uniform color. A person of color under the light of the sun or moon will readily show specular highlights in varying degrees of 'sharpness' depending on the smoothness/tightness of the skin being exposed. The shine from point/spot lights has improved, and I can live with that. However, sun/moon specular shine is still practically non existent, and I can say that, having compiled Firestorm 6.4.8 just today. As sluggish as Cool VL Viewer is on my system compared to Firestorm (sorry Henri, but it's true), I feel like Cool VL Viewer has about the right amount of sun/moon specular shine. The last time I tried Black Dragon (which was a while ago since I hardly ever log into Windows), it also had a more reasonable sun and moon specular. Is this issue getting fixed? There is much to like about EEP, and I've been working on my own personal day cycles. It's just that somewhere along the line the coders are making it very hard for the artists to get a consistent result.