Jenna Huntsman

To add on to this, as someone with some industry experience and have spent a fair amount of time researching the subject: As the others have said, the key thing to remember is that the camera is simulated - so the camera, again, is not constrained by the laws of optics and optical science. Another thing to keep in mind is that the default settings are.. just.. bad. They actually represent a lens which couldn't really exist, so these are best changed to represent a more accurate sample. To use computer science terms, GIGO. (Garbage In, Garbage Out). The Debug settings "CameraAngle" and "CameraFieldOfView" are unrelated - namely, as they use different units and are measuring a different thing, see the wiki page linked below (Under "Debug Setting Glossary"). In terms of screenshots and SL photography specifically: Don't use "overscan" if you can avoid it. The SL rendering engine handles resolution scaling pretty poorly, and not all postprocessing effects will be scaled the same. (That's not to say you can't use it). Take a read of my wiki page, it contains a lot of useful info relating to DoF and lighting within Second Life: https://wiki.secondlife.com/wiki/User:Jenna_Huntsman#Lens_Settings

Interesting - I don't always see that behaviour, just on the pre-bento .dae files I have, the post-bento will import with the skeleton's head and tails in the correct place. Odd. Edit: Testing the import with Find Bone Chains and Auto Connect works for the other pre-Bento DAEs that I have, but interestingly not the Ruth2 dae from the Git - seems like the heirarchy is broken on that one, however it seems that the uploader handles it just fine. Having looked at the Ruth2 body, it's missing all of the mSpine bones for a start - guessing that could cause an issue? Ideally I'd try retargeting the Ruth2 I've got onto a complete bento skeleton (with the correct orientation) and then try uploading it, see if it works, but I don't even know where to start with that (Blender is very confusing to me at times)

It notes on the GitHub page that while it uses the bento skeleton, the bones which are unused for weighting have been deleted - so, in other words, it's an incomplete skeleton. My theory is that the uploader has 2 different behaviours depending on the skeleton used - if using the Bento skeleton, then it seems to use a much more standard and logical bone representation wherein the head and tails of the bones are located at each end of the bone. On the other hand, the pre-Bento skeleton places the head of the bone at the midpoint along the bone, with the tail facing +Y. See below screenshot, which is the .dae provided from the Github. My question is, how does the uploader decide when to use the newer behaviour over the old? Does it require the complete Bento hierarchy, or does it look for specific bones to be present?

So, having had a play for a bit, it's all very weird in ways which I wouldn't have thought: (feel free to correct me on these observations if you have more knowledge than me!) While the model has the expected axis of +X forward, Z up, all bones origins must be positioned at the middle of the bone, with the tail of the bone rotated to +Y (except when it's not, although this (more logical) behaviour seems to be limited to the bento skeleton) (todo: add more things here later, ran out of time for now)

This behaviour is likely caused by the exported file having the wrong axis settings. For reference, SL expects the exported file to have the following axis settings: Y Forward Z Up See below. If your exported file uses any other axis settings, then the armature will become distorted. Note that SL is sensitive to transforms applied within the file, so make sure that the armature has the correct rotations and joint positions within the file. That's likely caused by the exported mesh being in the wrong scale. SL is also sensitive to the scale of the file, so you *need* to make sure that the scale is correct, and that the units used are based on inches, not meters (Blender default). See some of my posts here: EDIT: So, playing around, I can see there's more weirdness at play than just the above. Will keep tinkering.

As a general rule, copyrights and trademarks are only good if they are enforced - that's also the reason why Disney are so litigious when it comes to their IP, as if they are not, the copyright can become invalid. But equally this is extremely time-consuming and expensive to do manually, as SL, unlike YouTube (end by extension, Google) does not have automatic moderation, so ultimately it falls to either the copyright holder (in the above example, Marvel), or Linden Lab (who likely will only take action once an item has been flagged as infringing IP, as again, manually screening every MP listing would require too much resources). So, the answer is: Report the listing, and wait until LL takes it down, or the creator modifies the listing and product to remove any copyrighted or trademarked material linked to the IP.

The environment shouldn't matter, as when your neck is correct there will be no seam regardless of lighting conditions. Make sure to disable the neck sheath option of the body, as this is no longer really needed. Make sure to double check that your head skin and body skin are from the same brand, and same skin tone. Note that some brands have still have incompatibilities even between the same skin tone, so make sure that they are 100% colour matched. Alternatively, use a neck blender (Izzie's sells one). Ensure that you are not using any material maps that are not from LeLutka or Belleza. This includes any 'wet look' maps. Always stick with the default maps when troubleshooting. (As an aside - I'm assuming your character is a male, as you mention the Belleza V3 body as being the latest - if you're a female, the latest version is V6).

Your spec would suggest that your computer is more than capable of running SL just fine with ALM enabled - as others have said, check to make sure that there's nothing absorbing resources in the background. Another thing to clarify.. is to define the 'lag' you speak of - 'lag' is often a bad term as it's a catch-all, covering poor FPS, bad networking (rubber banding, assets not loading, etc) or even serverside performance issues (scripts slow to execute, physics performing poorly, etc).

Copy and paste the spec your viewer sees about your system from Help > About [Viewer name] onto a post on this thread - it could be that your viewer is stuck using an integrated GPU for whatever reason, and will also answer any questions about what hardware you're running.

I think a major stumbling block to BoM materials is that the alpha channel of a materials texture is actually used as a data channel, not as an alpha channel - see here: https://wiki.secondlife.com/wiki/Material_Data#Texture_Channel_Encoding With that said, going with @Gabriele Graves' idea, you could just add in 2 more channels which contain the data for the alpha channel for each texture, so the existing texture encoding is preserved, and the bakes service gets the additional information it needs in order to correctly overlay and blend the textures together.

Take a look at the docs for llSetAgentEnvironment - that provides the functionality that you need. You don't need a fast timer either, as the function incorporates it's own transition logic, so you can use a slower timer in your script, and make use of the function's 'transition time' parameter instead.

You'll want to use the following: integer dln = llDetectedLinkNumber(0); if(llGetLinkName(dln) == "Hangar") { llDie(); } The 0 is important, as it defines the index that the command will use.

You'll want to use llDetectedLinkNumber() to establish which link triggered the collision event. Combine that with llGetLinkName within your if statement to find the name of that link.

I've had a little play around with this, but I can't get it to successfully convert any of the animations I've got - I'll upload one of them and DM you a link, but this is the output that I see: ./bvh2anim bentoReferenceWtransforms.bvh out.anim Animation priority: 4 Does the animation loop? (y or n) n ease_in amount: 0.3 ease_out amount: 0.3 nFrames: 1 Frame time: 0.041667 Segmentation fault (core dumped)

Have you tried the (beta) Linden Performance Improvements viewer? It contains a bunch of fixes to avatar rendering and provides a good bump in performance in crowded areas.

FWIW Chrome's GPU usage would heavily depend on the pages you visit - if you're visiting basic blogs, Chrome is pretty much not going to even touch your GPU, regardless of what spec it is as image decoding is pretty well optimized... But, if you're visiting sites that run games, then that's another story. Also, sites like YouTube tend to suck down a lot of CPU and GPU due to the streaming codecs they use to provide stable playback, so while on the surface you might think that they don't take much grunt to run, you'd be surprised.

In my head, based on what I've heard (that changing priorities would be an LSL-specific feature), I'd imagine that it'd be a minor modification to the existing system wherein the viewer is told to ignore all joint priorities within the file, and instead play all joints at the given priority level. Essentially that would break individual joint priorities, but as you say, the usage of individual joint priorities is fairly limited, so it would most likely be seen as an okay compromise. An alternate way to approach that might be the ability to specify the priorities through a parameter value, for example, using a constant called "JOINT_ALL" would target all bones, but you could also specify JOINT_ALL and another joint, for example, JOINT_MNECK and the animation would play all the joints (except the neck joint) at priority A, and play the neck joint at priority B. An example of that might be as follows: llStartAnimationSetParams("myAnimName",[JOINT_PRIORITY,JOINT_ALL,3,JOINT_PRIORITY,JOINT_MNECK,1]); The above example would function as mentioned above, animation "myAnimName" would play all joints (except the neck joint) at Pri 3, but play the neck joint at Pri 1. Another benefit to doing an approach like that might be the ability to specify other parameters about an animation, e.g. Ease-in time, Ease-out time, Loop

You can do this, and I have - although it's a lot of manual data entry and some manual recalculations due to quirks in the EEP system. Try going to this website to get yourself started: https://www.suncalc.org/ As a side note - PLEASE don't use Second Life as a replacement for a more accurate climate rendering model - Shadows in SL are not great at the best of times in terms of accuracy!

This is essentially your only option, since Lumiya (A full 3D viewer for Android phones) is no longer maintained and isn't available on the Play Store. As @MarissaOrloff said, the chances that Chromebook would even have the prerequisite horsepower to run a full 3D viewer (and for it to be a good experience, not 'will it boot?') is slim to none.

You should also post the environment details that the viewer sees from Help > About Second Life... That includes info about the system you're running, audio driver, etc.

The issue discussed here wouldn't be solved by a redelivery, it's issues caused by Legacy's asinine decision to make the entire body functionality contingent on the presence of an external server (which, at any point can go down or be otherwise inaccessible). You *can* go BoM with the body, which from my understanding fixes most of the gripes with the body, but that only works, if: BoM is already applied, OR, if the remote server is up, which would allow the user to apply BoM.

As someone with a lot of experience in the field, SL (w/ default settings) period is a bad thing to compare against a real camera as the lens of the SL camera is optically perfect - unless you enable DoF (I have actually began to make a list of DoF presets which correlate to real lenses, see here https://wiki.secondlife.com/wiki/User:Jenna_Huntsman/CameraLensPresets). The example that Henri gave is a good example of what the perceived issue is, although I think there may me more at play there - maybe the shadow map is being rendered at too low resolution? I can't say that I've ever seen this myself, even testing now, so maybe it's also YMMV. It's also worth noting that the human eye is much more sensitive to contrast than it is colour and luminance, so enabling ALM will inevitably cause some "blur", not because there is actually blur being applied, but because the contrast is lower. A great example of this is seen in Qie's post with the house, as looking at the image, I don't see any drop sharpness but there is a substantial drop in contrast (thus, making the image look 'blurry', as the eye is having a harder time distinguishing between objects).

Having played around with this recently, the global upload priority in a .anim file is purely information - the animation engine in SL only cares about individual bone priorities, the global priority value seems to only be used by the UI (thus, you can create an animation that claims it's priority 0 in the UI, but every bone is priority 6, as you say, 'cheesing' it).

I also have a 4K (3840x2160p - "4K" isn't a great term as there's multiple '4K' standards, for example DCI 4K, SMPTE UHDTV1 and CinemaWide 4K) and ALM is perfectly crisp for me. In actual fact, I prefer having DoF on (albeit with tweaked settings, to simulate a real camera lens, not the garbage default settings!) to provide a softening effect to distant objects. I always have ALM on - but not shadows (usually). As an aside, I do wonder if people mistake ALM being 'blurry' because of the increased frequency of unloaded textures, as the extra CPU load incurred by ALM means there's less time to spend decoding textures. Although more modern viewers now use threaded texture decoders, which alleviate this issue.

Not sure if you got an answer for this, but here you go: http://web.archive.org/web/20151227192030/https://jira.secondlife.com/browse/SNOW-586