Jenna Huntsman

That's about correct. This is because of a quirk of legacy materials having transmissive properties when using alpha blending, but no transmission (correct!) rendering when using alpha masking. This behaviour was carried over for legacy materials, as fixing it was deemed to be too disruptive. (Because the glass has transmission, it reflects light, so more light will mean higher intensity reflections. Because the sky is HDR, it's much brighter than the rest of the scene (especially as you're in an empty region), the horizon being very bright and showing intensely in the reflection is correct)

That blog post is the one that triggered the question regarding the beta status of the body, and the response was quite clear that there aren't any future updates to the 2 Senra bodies planned. (The post would seem to indicate that any future iteration would come in the form of an entirely new body)

According to Patch, this labelling was a mistake, and the body is actually in it's final release state. Any JIRAs would go into a feedback bin for a "future iteration" of the avatars, which aren't in development.

I notice that the blog post announcing the Senra avatars refers to them as "BETA" - How long is the beta period, and how do we give feedback on the bodies? Are the bodies locked in as they are, or would it be an iterative beta? (Link to post: )

If that was true, then the choice of words is truly abysmal. If they only wanted a copy of the in-world finished item, using wording like "Finished in-world asset" would be much better, as it excludes the possibility of needing the source files outside of SL.

Before you get too excited, download the glTF project viewer - it contains a lot of performance improvements in addition to a bunch of new features, so your existing hardware may be more than enough for your needs. https://releasenotes.secondlife.com/viewer/7.0.0.581126.html

Eh, their new UV failed for a couple reasons IMO: It was explicitly tied to a new body, and none of the existing Slink lineup was updated to use the new UV (meaning; there was no existing market for content that uses the new UV). This is the opposite of what LeLutka did, which was to go back and update their previous products to use the new UV, meaning that there was a large pre-existing market for the new UV Slink was already sliding down the board as their marketing wasn't very good, and tastes changed away from Hourglass, which was their most popular body (as far as I can tell, anyway), and Physique got dwarfed by Maitreya, which is (in my experience) a bit more flexible with it's shape They took a page out of the Legacy playbook for their new body, and slapped a large pricetag on it; yet didn't have anywhere near the marketing and hype to motivate people to actually spend that much. The shape of the new body was very meh, and more importantly, wasn't very flexible. It seems to me like if a new UV is the path they're going down, then taking pages from the LeLutka playbook is a very good idea (Free update for everyone who owns a Maitreya body? Massive existing market there!)

I'm going to guess the major change will be a new UV map, hence why: The information is coming from a skin creator, as it'd be smart to get other creators involved and making content for the new UV map ahead of launch The name; as it follows the LeLutka naming convention (X represents their new UV) Just a guess.

Might I draw your attention to: SDK License: Technical Info: Yeah, this is pretty DOA.

If you're having issues with overall scene brightness, adjust your viewer's Brightness (exposure) setting under Graphics. (Assuming you're using SL Viewer 7.0 +)

The lighting issues that people are seeing are twofold, as: The specific machine I took the screenshots with is affected by a graphics driver bug wherein the viewer's shadow softening does not work, so shadows are considerably harsher than they would be on your machine The screenshots were taken in the PBR project viewer, and not the absolute latest build - Lighting is still actively being tweaked in the PBR viewer, and the latest build had further work than the build I took the screenshots in. So, TLDR is don't focus on the lighting in those screenshots. I was in a rush to even get the screenshots, so I didn't have time to actually take proper photos and just ran with what I could get once everything had loaded in. One thing I will say, is that it didn't seem like the bodies had material maps in this demo, which would help out massively to add smaller details back in, and help balance lighting. (This might be because the NUX team are waiting until PBR launches, at which point PBR materials would be applied)

Hey all, In today's Lab Gab at SL20B, a new preview of the NUX avatars was given! I grabbed a fair few photos, all taken in the new PBR viewer. ( Imgur Album - https://imgur.com/a/a2i4W8p )

This, although I'd recommend disabling shadows before disabling reflections.

PBR does work with BoM (insofar as being able to use bakes textures on the Base Color map) - the material drag&drop is how regular textures are applied (PBR can also be done via the Build floater, should you desire). Appliers are a vendor-specific thing, so will depend on body creators (and / or 3rd parties in the case of Mod-enabled bodies) on updating their content to accept materials created with the new system (Likely this will amount to applying a material asset by UUID) - This will have a benefit in the sense that users are handed more control over how their bodies look (as, you get access to all material parameters via material assets, rather than pot-luck of whatever the applier creator's script allows).

I'm a little disappointed if I'm honest - I was hoping this work would help solve the issue of objects with large inventories take forever to load / update, but that behaviour hasn't changed

It's also worth noting that the Puppetry project is going to go a long way to address this issue, as IK is being worked on as a feature for that project.

You may have ran into a bug with the public build of the PBR viewer. You should be able to create a material asset in your inventory (right click in your inventory > New Material), then go from there.

Not quite correct, as the PBR base color map and the traditional diffuse map aren't quite the same - PBR base color maps do not contain baked lighting, as is commonly seen in SL diffuse maps. Not from the water, it's from the sky. Has since been fixed, but you'll need to wait a little while until the public builds catch up.

As per https://wiki.secondlife.com/wiki/LlList2Vector Chances are that llList2Vector call is actually returning <0,0,0> instead of <1,0,0>

Ah, that's it! My brain got stuck, so here's the new optimized function, with the Modulo and division removed and the string length stored in a variable: string MemComp(string sInput, integer iDir) { //Compress 2 UTF-8 chars into 1 UTF-16, or decompress 1 UTF-16 to 2 UTF-8. Credit: Jenna Huntsman, Mollymews, Quistess Alpha, Wulfie Reanimator string sOut; integer iLen; for (iLen = llStringLength(sInput)*2; iDir < iLen; iDir += 2) { if(iDir & 1) //If iDir is an even number (including 0), we're encoding - any odd number will decode. { //Decoding integer c = llOrd(sInput,iDir >> 1); sOut += llChar((c >> 8) & 255) + llChar(c & 255); } else { //Encoding sOut += llChar((llOrd(sInput,iDir) << 8) | llOrd(sInput,iDir+1)); } } return sOut; }

So, did some more tweaking today, here's what I've got now. @Quistess Alpha, I've managed to get rid of the Modulo operation, but I can't see a way around getting the division operation out while not adding to the memory impact of the function itself (so, no second loop); Unless someone has any ideas? string MemComp(string sInput, integer iDir) { //Compress 2 UTF-8 chars into UTF-16, or decompress UTF-16 to UTF-8. Credit: Jenna Huntsman, Mollymews, Quistess Alpha string sOut; integer iLen; for (iLen = llStringLength(sInput)*2; iDir < iLen; iDir = iDir + 2) { if(iDir & 1) //If iDir is a en even number (including 0), we're encoding - any odd number will decode. { //Decoding integer c = llOrd(sInput,iDir/2); sOut += llChar((c >> 8) & 255) + llChar(c & 255); } else { //Encoding sOut += llChar((llOrd(sInput,iDir) << 8) | llOrd(sInput,iDir+1)); } } return sOut; }

Intel GPUs haven't gone through a bugfixing pass for a little while, so it's likely that you're running up against a bug which should get ironed out closer to release (Most testing happens on Nvidia and AMD GPUs)

I actually started off in a similar manner, but figured I could tighten up the code into a single loop which I thought would save on memory a bit. Neat idea about using iDir though, I just put my own spin on it to compress it back into using a single loop again. See what you think! string MemComp(string sInput, integer iDir) //iDir is a bool, so should be FALSE (0) for encode or TRUE (1) for decode { //Compress 2 UTF-8 chars into UTF-16, or decompress UTF-16 to UTF-8. Credit: Jenna Huntsman, Mollymews string sOut; for (; iDir < llStringLength(sInput)*2; iDir = iDir + 2) { if(((iDir % 2) == 0)) //If iDir is a en even number (including 0), we're encoding - any other value will decode. { //Encode sOut += llChar((llOrd(sInput,iDir/2*2) << 8) | llOrd(sInput,(iDir/2*2)+1)); } else { //Decode integer c = llOrd(sInput,iDir/2); sOut += llChar((c >> 8) & 255) + llChar(c & 255); } } return sOut; }

Hey all! Had to come back here for a project that I'm working on. Did some updates to @Mollymews' Ord-based compression, to make use of the native LSL functions, and tighten up the function to use as little memory as possible. string MemComp(string sInput, integer iDir) { //Compress 2 UTF-8 chars into UTF-16, or decompress UTF-16 to UTF-8. Credit: Jenna Huntsman, Mollymews string sOut; integer i; for (i = 0; i < llStringLength(sInput); ++i) { if(!iDir) //If iDir is 0, we're encoding - any other value will decode. { //Encode sOut += llChar((llOrd(sInput,i) << 8) | llOrd(sInput,i+1)); ++i; //Iterate i by 2 and not 1 on encode. } else { //Decode integer c = llOrd(sInput,i); sOut += llChar((c >> 8) & 255) + llChar(c & 255); } } return sOut; }

You would be correct, the current implementation only allows for specular highlights that have the colour of the light source (non-metallic materials) or inherit the base colour of the material they're reflecting off (metallic materials), or somewhere in-between. That being said, this is possible within the glTF spec with the use of KHR_materials_iridescence, which is potential future work after PBR goes live.