Jenna Huntsman

It's worth noting that not all viewers support the square bracket syntax (Notably, any V1 style viewer does not support this, e.g. CoolVL and Singularity).

It's worth noting though that like LeLutka heads, you can swap back to regular SLUV. The packaging of the body is as follows: Cinnamon Body (This is the one that uses the new UV) Chai Body (This is SLUV) Both bodies have the exact same shape, just different UV maps.

Here's a good primer on how to set up BoM: https://modemworld.me/2019/08/27/bakes-on-mesh-a-basic-primer/ HUDs, your best bet would be to contact a scriptor via the Wanted forum, or tinker with LSL yourself and get some assistance from the LSL forum.

Why are you overcomplicating it? Use one of the BoM AUX layers (I'd recommend using either AUX_2 or AUX_3 to avoid conflicting with LeLutka's ear textures) and use the bakes system to handle tinting and layering. That means you don't need 100s of onion layers, you don't need a HUD, and users are free to create their own compatible textures (if they're so inclined).

Have you tried measuring with a prim in-world? Avatar height reported by the appearance window can be a little unpredictable at times, and more often than not does not reflect the true height of the avatar. (note that Prims measure using meters, so for my avatar, 1.61m in height translates to 161cm, or roughly 5'3" )

Your CPU is going on for 10 years old, so a poor framerate on SL isn't all too surprising - SL is heavily CPU bound and even modern hardware has issues running SL at full speed.

VRAM is largely irrelevant if you've got a card with 6GB or more. Most SL viewers cap VRAM usage at 3GB - the extra headroom is good to allow your system some room to breathe. As for memory chip speed, the other inefficiencies with the SL pipeline mean that you'd be hard pressed to notice the difference.

Have you updated both your head and body as of late? Belleza recently released an update which includes conformance to the SLNeck standard, which resolves neck issues for all heads that use the standard (Essentially any head made in the past year, and heads that creators have updated to conform). Try updating both and let us know what happens.

* Nvidia is better if you are running Windows, but if you're running Linux, you're better off with AMD

Let's rewind a little: What are you trying to do? Reading through this it sounds like you're trying to generate a smooth spline between point A and point B, then feed that data into a pathfinding character - is this correct?

That's because the graphics stack used by SL has to be cross platform - remember when everyone wanted a DirectX 11 viewer? That never happened because it would remove Mac and Linux support. Supporting Metal would remove Windows and Linux. LL don't have the manpower (or, lets face it: money) to rewrite the viewer for approximately 5% of SL users to have slightly better performance, while cutting everyone else out of the loop. Vulkan, on the other hand, is near enough confirmed to be the next step forward, (supports all 3 platforms, and is supported on most hardware configurations going back to 2013), BUT - rewriting the viewer is no small task. Heck, right now LL aren't even the ones working on the Vulkan viewer, but the Lindens are very interested in it; however it's a very early prototype right now.

From memory, I think the answer was a 'we'll think about it' - not a confirmation. Regardless, some TPVs can already be compiled to ARM (at least, on the Linux side of things) - but again, don't expect it to be a magic fix to performance issues

I wouldn't get my hopes up, after all, as Coffee said - no TPV devs have their hands on an M1 of any kind, and LL only just fixed a longstanding bug with MacOS (after.. years?) Bear in mind though that M1 and M1 Max are *consumer* chips - i.e. they're designed for web browsing and productivity uses, not gaming (which would be SL's use-case), so don't expect performance to be great. edit: also, LL aren't going to port the viewer to Metal, ever. It's not cross-platorm, just like how we're not going to get a viewer based on Dx12. Vulkan, on the other hand...

A lot of things changed with EEP. Colours seem washed out because of the way WL presets are interpreted by the EEP renderer (there's a lot of gaps that need to be filled, without any additional data) - for example, with EEP ambient light colour is controlled by no less than 3 separate items, whereas (from memory) WL only had 1. The glow effects have changed largely due to changes with material map rendering that was introduced at the same time as EEP, to fix long-standing issues with how materials work in SL - this often means that items set up for pre-EEP materials often don't work as they did *but* with some tweaks to their settings can be made working again.

Another funny thing about them is the advertising is often incorrect - for example, VPNs claim to offer increased security and prevent hackers from hijacking your connection, however this hasn't really been a good argument for years, with HTTPS now being the standard protocol, alongside other things such as DNS-over-TLS, meaning that your connection is likely to be encrypted end-to-end to begin with. I find the video Tom Scott made on the topic on YouTube quite good at debunking most VPN ads ( https://www.youtube.com/watch?v=WVDQEoe6ZWY )

Chances are that the VPN connection is suffering some issues. LL doesn't have any reason to block a VPN (well, not quite true as if you're using it to get around restricted entry to Skill Gaming regions from certain areas where they are banned), BUT SL is very sensitive to poor or sub optimal network quality, which happens all the time with VPNs (as your network traffic isn't being routed directly into the backbone of the internet, but instead, going from you > your ISP > backbone > VPN ISP / datacenter > VPN server > ISP / datacenter > backbone > AWS entry node > LL server) Submit a ticket to your VPN provider and get them to look into it.

I'd also note that you should *always* supply a system alpha with any clothing you intend to sell, regardless of if it has auto-alpha or not, as mesh bodies increasingly move away from traditional alpha cuts towards using the BoM alpha system. Not including them might create a headache when a body updates and removes auto-alpha functionality - whereas, if you were already supplying system alphas you just need to tell people to use an item which they have already got, in the same folder as the clothing (ps. I actually prefer system alphas, as they don't break regularly, unlike auto-alpha systems wherein it's a crapshoot whether it will work or not (and thus, force me to equip the body HUD))

Isn't that wildly inefficient? Why not run it through the entire pipeline as a text character? This would also beneficial as the result would be (at least to my knowledge) a vector graphic and thus can scale with the screen resolution without having to render multiple mipmaps to account for the size of the text displayed

It's useful for anything related to llHTTPResponse For example - I have a few items where a response is sent to a users viewer, giving them a URL to load. Normally, you'd expect to serve this URL as content type text, or HTML for more advanced stuff. In my case, neither of these are very helpful, as I want to provide a response that has some UI design, which rules out content type 'Text' as, well, it's just plain text. Content type 'HTML' would work, but it's limited to only opening in the browser built into the viewer, and external browsers (e.g. Chrome, Firefox, etc.) can't load the page. (This is a limitation by LL). So, to solve these issues, I serve my response as content type 'XHTML', which is very similar to HTML but has much more strict formatting rules, however it isn't limited to just opening in the built-in browser. Another use would be communicating with an external web server, for example, exchanging information via JSON.

Another body coming down the pipeline is the Cinnamon & Chai body - not sure of the name, but it's a sub-brand / rebrand of Slink, releasing an all-new body. Looks pretty interesting from what's being said on the dev channels.

Could you use some sort of Delta time calculation based on the reported time dilation? Edit: What @Quistess Alpha said is a pretty good way of applying Delta time for scripts.

For anyone reading who is confused or doesn't understand: Newer Chrome versions block 'insecure' content by default - that means, any content loaded over HTTP (not HTTPS) won't load. The issue here seems to be that product images sometimes fall back to serving over HTTP, and not HTTPS thus meaning images won't load. As pictured above, this can be worked around, although it should not be needed - by default, at least on my connection, images are served via HTTPS. meaning I do not require this workaround.

If you have the devkit for the body you're developing the tattoo for, I believe Photoshop can allow you to paint directly onto the model itself (ala z brush) via it's 3D mode.

These 2 aren't friends. Nvidia will get better FPS on Windows for SL - it's a known thing that AMD's OpenGL implementation on Windows sucks, and this isn't likely to change given the amount of games which rely intensely on OpenGL (which isn't that many, as Vulkan is now a thing) If you feel inclined, you can try out Linux which has a vastly superior OpenGL implementation and thus SL performance is much improved (On my system, which is similar to yours, I went from around ~24fps average to between 80-100 on Linux). Other than that, turn down your draw distance, and turn down particle effects to around 1024. Turn down your LOD settings to around 1.5.

Does having a texture in Mask mode with the cutoff of 255 also trigger this?