NiranV Dean

Did you? I must have missed that, i'm sorry. The comments on my videos give insight into how this is made. The short answer is it's not Second Life, if the realistic Motion Capture isn't a dead giveaway. In Second Life its simply not possible. Second Life only has a very tiny amount of blendshapes for A,E,I,O,U to which the Viewer reacts. I'm using VRChat for those Videos as it A: allows me to use VR equipment (hence the realistic motion capture) and unlike SL uses the industry standard oculus voice blendshapes (15 to be exact) for the most used noises that are being detected while talking. VRChat blends between these 15 blendshapes depending on the sound you make, which totals to the lip sync you see. I don't do these videos in Second Life because avatars in Second Life simply look dead and static and move completely unnatural even when using motion capture animations.

Provided by Axo:

You won't be able to upload meshes on BD ever. I do not plan to ever implement it. It is too prone to widespread destruction with just a small little mistake. Use the LL Viewer to upload.

This bug and its various degrees of intensity have been around since Materials at least. Depending on what version of this bug it dates all the way back to Meshes. Great it's finally getting some attention after 10 years or so. There are many to choose from, here the most common ones that can cause this: Rigged alpha-blended surfaces. All of them. They are treated as solid surfaces and will "cutout" other blended and transparent surfaces behind them (long ago even clouds and water). Rigged invisible objects that have at least 1% glow. They will be treated as solid and visible (both shadows and for the sake of occluding things jut like the above). "Invisible" rigged default Linden body parts, e.g your shape, hair, eyebrows, shoes, etc. If you use an alpha mask and in the mask you use a masked texture instead of completely disabling the body region, it will be treated as fully solid and visible, again just like the above, it can even stick through your mesh body depending on your shape and cause all kinds of weird shenanigans (like your hair getting occluded) Sadly there is no fix for most of these. LL has to fix whatever is borked with rigged alphas (and blended alphas in general, they are treated as fully solid in the depth map, causing depth of field to go off on them). The glow thing however is an "intentional" as far as i am aware. Black Dragon has invisible glowing items disabled.

I don't know what to do in this case. It's not Viewer specific and can happen in any Viewer for many reasons, it usually stems from a faulty/corrupted login (usually accompanied by not being able to see friends, not being able to move, avatar not loading and several other things depending on severity and when exactly the login started "failing"). It can happen for several many reasons, anything that can disrupt the login order or connection. Firewall, Defender, Router, bad server connection. If it was fine before it is usually one of the later ones.

I suppose the easiest solution i could think of is simply importing the FBX animation from Mixamo into Blender, then changing the skeleton bone names to match those of SL, then exporting as BVH or ANIM, you'd have to make sure that no position (other than hips) or scaling transformations are included, only rotations.

It's certainly weird. Before i made my own server-side AO i used Oracul AO which also had turn left/right animations (and just like most AO's i had those filled with animations) and they worked fine (at least locally for me), in fact they worked too good, often times playing longer than necessary (which made other people see me play the animation when i wasn't spinning for them, e.g spinning in place or spinning animation wise but not physically). This could even be done on purpose by constantly drag-looking around in small circles, forcing the rotate animation to keep playing.

The difference is only between BD and SL then mainly. It probably stems from the fact that BD's default turn settings are lower, the official default settings for turning are 30° so before any "turning" animation plays you need to turn away ~30° in any direction from the initial "center" to which the avatar will then readjust and turn, while in BD the turn threshold is all the way down to 2° meaning essentially as soon as you even as much as think about rotating in any direction you will immediately see the avatar start the turning animation. However, there might be some desync happening here due to you checking for the animation rather than using the server-side AO features, i have never used the old AO system so i don't know what exactly it does and how it works but i'd assume it checks clientside, whenever the client is playing the turning animation, this coupled with BD playing them much more than other Viewers might cause a desync somehow (although it shouldn't as you are using the LSL play animation command which is a synced command, so everyone should see you play it).

Highly WIP, mostly unfunctional atm but its slowly getting there. This might actually need a full on rewrite (or at least a completely new widget type) but i suppose this is roughly what you wanted.

Deforms and undeforms (don't) work because of how the animation system works. Any and all bones need to be animated, otherwise they will remain in whatever position/rotation/scale they were before. For most of the normal non-bento bones this isn't a big issue as they are always animated (at least rotation and position)... however bento bones and all additional bones (such as collision and attachment bones) are not animated by default so if an animation changes them (a deformer) for an avatar, they remain in their position forever until your skeleton is rebuilt or they are changed again. Usually this can be fixed with a simple right-click reset skeleton (and animations if you need the Scorched Earth variant) but needs to be done by every person individually who's around you, simply leaving render range for a bit and coming back will recreate your avatar for them and fix it too. This highlights one big problem, undeformers really DO NOT work at all, don't be fooled, what you are doing is just further deforming your avatar, DO NOT use undeform animations! Stop the deformer animation and Reset Skeleton, this is the ONLY true fix. Take it from the person who is LITERALLY wading through the entire animation system and its internals to make an animation editor in the Viewer.

Yea... i don't know what happened there, i vaguely remember something about those fixes going official, i may have offered them to LL during EE because someone (maybe Alchemy) suggested it to me but i've never seen any of those fixes going anywhere (at least not the maintenance releases i was tracking). If anything they also weren't using the original commits either due to some patch failing or something, they have done that before although all commits i have ever seen like that never made it into any RC, let alone release. I wasn't saying you are wrong or not crediting anyone, just that i remember fixing this issue a while back (apparently 8 years already...) and i only know of you implementing said fix into your own Viewer, thus making it only 2 Viewers that fixed this, i remember being very proud that you took my fixes!

ah, i didnt see the video, i was going by the thread description, rolling water was exactly what i fixed. Edit: I watched the video. THAT is EXACTLY what i fixed long ago and i'm pretty sure that was the fix you ported. https://git.alchemyviewer.org/NiranV.Dean/blackdragon/-/commit/c6b473f3c3ad43641a0dbf2f9441c1418ccfc07d https://git.alchemyviewer.org/NiranV.Dean/blackdragon/-/commit/fe272ae174d41d41738e7c569b6692900b0fcfa1 http://sldev.free.fr/forum/viewtopic.php?f=3&t=2&p=6968&hilit=Black+Dragon#p6968 You are also referring to these which were also things i fixed, i was only aware that you ported the water hurling fix that the OP is having. https://git.alchemyviewer.org/NiranV.Dean/blackdragon/-/commit/35aa90392b4ab4250b38a6df30fa58cf57efb9c2 https://git.alchemyviewer.org/NiranV.Dean/blackdragon/-/commit/35aa90392b4ab4250b38a6df30fa58cf57efb9c2 Also this is the current version for EE: https://git.alchemyviewer.org/NiranV.Dean/blackdragon/-/blob/Release_4.3.1/indra/newview/app_settings/shaders/class1/deferred/waterV.glsl I'm using the original LL shader with only the two above changes (water hurling and water waves fixed) both of which still are not fixed in LL Viewer to-date. My changes are hardly useless for EE since they applied to EE exactly identical, EE hardly even touched the water shader.

This issue was fixed long ago in BD, Henri ported it to Cool, im not aware of any other Viewer having this fixed

Yea see thats my problem, i'm not thinking about now, i'm thinking about the final product and how i can achieve that (if at all) and i'm genuinely unsure if i can.

If i remember correct my Viewer has this feature already implemented

My biggest problem with that is still the "zooming" , assuming an animation always plays with 60 FPS, and an animation duration max of 60 seconds, thats 3600 frames. The transform sliders are huge and have a range from -PI to +PI, so roughly ~6000+ possible values and precision sliding is impossible, you have to use your keyboard to go increment by increment, same would be the case with frames, there is no way i can cram 3600 frames into one slider without it becoming a mess.... we need a zoom feature... and thats where its going to get tricky.... unless i make the sliders HUGE and have them extend beyond the window, that is have a scrollbar at the bottom to allow scrolling horizontally....oof

That should be quite easy.

Auto-keyframing is on the list of todo's. Weird reverts come from the way animations and the SL skeleton work, animating a bone that is not otherwise animated (all bento bones) will simply remain in their last position they were in, so if you ever moved them at any point, they will simply stay that way, if you move one of the extra spine bones and you go back to posing mode it will remain that way because there is no animation overwriting it and thats where you last put it, this could be fixed with a simple "reset" after reverting back and before applying all current keyframes. Shouldn't be hard to fix. Now the UI is going to be the biggest pain, SL does have keyframing sliders but they are... barebones and hardly useful, i will need to massively rewrite them and employ a metric ton of magic to get an UI similar to standard keyframe editors, just listing them all and having the currently selected frame sync to all of them is going to be a headache, not to mention making the keyframes selectable and then its still a matter of the looks, a slider is really not good for this and it will require some kind of "zoom" or "scrolling" so you can get closer in and mousedrag single frames easier (this one is going to be my biggest headache, i'm not sure if i can do this at all)

1) The UI is currently barebones and just functional, i have not yet worked out how the final UI (or the UI at all) will look and work like. I doubt you will ever be able to view all keyframes at the same time though, SL simply does not have any UI widgets that support this, it would require writing an entirely new UI. You can however copy/paste bone transforms from one bone to another (the animator inherits the Poser's functions, unless i broke that), select the keyframe to copy, right-click the bone and select "Copy Transforms" then select the keyframe to copy the transforms to and right-click again select paste for whatever type of transforms you want to be pasted, i do not know how well this works tho, i have not tried it (it was not modified for keyframes yet, future updates will add this however. Another way although a little "dirty" would be simply selecting the keyframe to copy, then clicking the "+" to add a new keyframe, new keyframes are always a copy of the previously selected ones, with the newly created keyframe, simply change its keyframe time to be at the end of the animation (if your animation is 5 seconds, change it to 5 for example) 2) New keyframes by default are added in 1 second steps, you can however select any keyframe and change its time to whatever you like, simply type a new float value into the text field (between the interpolation method and "+" button) then hit Enter, again this is clunky due to the UI being barebones and SL's UI simply having no way to type directly into lists, something i may or may not be able to change. The timeline works very straight forward, the "Time" value is simply the exact time in seconds the keyframe happens. 0.5 means it happens at 0.5s in the animation. 3) For an animation to properly work and display all keyframes you have to make sure the animation duration is long enough to include all keyframes, there is a quick option to automate this. 4) The difference between Spline, Linear and Step are as follows: Spline and Linear are the same (after release i saw this in the code, Spline is simply Linear sadly) Step is essentially "No Interpolation" as in it will jump from keyframe to keyframe, like old-school 2D sprites do. Again keep in mind this is the very first ever release in the history of SL that we can edit animations directly inside SL, this will take some time to be fully fleshed out, get QoL features, have all bugs worked out and be something that is somewhat easily usable and even after a year or two i doubt the UI will be anywhere close to a normal Animation tool, again SL simply does not support this kind of UI design and it will be a massive challenge alone to get a semi decent UI for this. The best thing you can do is use it and give feedback: So far from your post i got -> dedicated copy/paste keyframe functions, easier way to see all keyframes, more obvious time management widgets (possibly writing directly into the list), better UI layout. Other things people have already reported is the "time" value being completely undocumented and a frame count rather than direct time value would be better (although this would require the user to do math and know how much frames the animation has and where to put them and so on unless i fill the UI with lots of statistics). Theres also more things planned like manual spline interpolation curve generation with options to change how it shall be generated, auto-fill keyframes, create keyframes from interpolation and a couple other minor things such as target framerate.

That is not true. You absolutely can. Every Viewer has an animation export feature. It is simply not hooked up to any button in the UI. The Poser can "snapshot" any pose you are currently in, even keyframe-less interpolations inbetween. It can also export these, i just don't allow you to do it... well LL doesn't allow me to allow you to do it.

Camera controls with keyboard have always had this... weird delay between pressing the buttons and them actually doing something, you have to hold down the keys for a very short moment before they start doing something. You shouldn't be using the keyboard controls in the first place, they are a backup and are not meant for precision controls. Mouse camera controls are far more precise and give you exactly what you want. That being said i see no reason why up/down should behave different from left/right inside the Viewer, tho overlapping controls (with the menu shortcuts or gestures) can result in these keyboard events to be eaten sometimes, this can result in weird, choppy or no movement at all. I will have a look into whats actually causing these weird keyboard camera control delays, the upcoming update fixes mouse control precision (again) allowing you to make one-pixel big movements with your mouse count towards moving the camera again, this may or may not have fixed the issue with keyboard controls too but i'll put it on my list of things to look into anyway.

You cant. BD does not allow to export as animation if you start from an animation (Poser) and starting Pose creation allowing export T poses you

Beta 3 (previous) can be found here: https://drive.google.com/file/d/1iev3n_lT9GGKM-jKMZiP7ZPWW6khaP5U/view?usp=share_link Beta 4 (just released) can be found here: https://drive.google.com/file/d/1pIlYMrpt39U6lyZgu08WWUGMKnBrnw2t/view?usp=share_link Generally speaking these Betas can be found in the Discord server where they are posted before any official release they are meant for testing to gather some feedback and bugreports.

Odd. But whatever that is should be fixed in the 4.3.1 Beta. You should give it a try. Note that 4.3.0 exports poses with all bones and transforms active, this means it will essentially make an exact copy of your avatar, including shape, you cannot use your poses on any other avatar or it will deform. (also fixed in 4.3.1 Beta). 4.3.1 Beta also allows exporting entire animations, creating/adding/removing keyframes and importing full animations too. What do you mean with a "library", what is it supposed to do? Any .anim that was exported at some point can be reimported and exported again, so .anims you create are technically your library.

Looks like the NVidia driver shadow bug, *should* be fixed if you update your drivers, you might also want to downgrade them (to a year prior), it was a very well known issue, posted a couple times here on the Forum too.