Jump to content

Extrude Ragu

  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Extrude Ragu

  1. Continuing on that train of thought, does that mean that the amount of mesh being rendered before and after CTRL+ALT+T changes? presumably 100% transparent mesh must be being skipped from rendering if it has a negligible impact on performance, but such meshes are visible in CTRL+ALT+T. So the viewer is rendering more then?

    The Devils Advocate in me wonders if someone could make a CTRL+ALT+T lag bomb, where a whole bunch of 100% invisible complex meshes are worn, and because they are transparent they don't have a noticable impact until someone CTRL+ALT+T's at which point it could overwhelm the viewer.

    (Sorry for writing so much :) )

  2. @Beq JanusHear me out on this and tell me if it is a smart or dumb idea, I am just going based on my understanding of what you have wrote:

    Perhaps I could even have two of my Chests in one linkset, one with many materials, one with just one. When the user wants the chest fully visible, I'd just have the link with a single material shown, and otherwise I'd show the link with many materials.

    Counter intuitively, even though the user is now wearing twice as much mesh, the lag would be reduced when the user has the Chest fully visible, because only a single material is visible and thus a single draw call instead of 8. Invisible mesh does not make a perceivable impact on performance and thus the 2nd link even though it has all those alpha slices would have a negligible impact on performance because it's all 100% transparent.

    Am I understanding this right? Although I am one of the smaller creators, it'll still hit a lot of people if I rolled out changes like this so I want to be sure.

  3. That was an interesting read. This graph was quite fascinating to me


    The drop is quite dramatic at first, although it is interesting how it seems to have less effect beyond a point.


    As someone who creates a couple of Chest Mods for the Kemono Body, this is interesting to me.

    My mods aim to reduce lag by reducing the amount of mesh used, and they do this by taking advantage of the Alpha Slices of the Kemono Body.

    But what you're saying here at least as I understand it is that 100% transparent mesh has little to no performance impact on the viewer unlike visible mesh, so trying to reduce the amount of invisible mesh does not really make much of a difference at all. In fact, things that I assumed created a lot of unnecessary lag on the Kemono Body (Such as having two sets of legs, one human, one animal hidden) would really make no perceivable difference to performance, and we can actually keep invisible meshes worn without much guilt.

    Instead if I really wanted to make a difference, I would provide my Chest Mod without alpha slices to reduce the number of draw calls. Of course as a creator that is a tough call, as Kemono is not BOM. The best I could do is provide a 'low lag' version without alpha cuts in the future.

    • Like 1
  4. What can I say. I can't make third party viewer devs make freedom compromises so that we can get more rounded viewers.

    I just as the end user wish it were the case, at the end of the day I have to use one viewer as my daily driver. I'm not going to switch to Black Dragon just to take a picture,  then go to Catznip to use RLVa things then to Alchemy to get some performance gains and then back to Firestorm because I want to Teleport someone home from a context menu.

    At least if some of these viewers banded together, there might be hope that at least one other viewer besides firestorm might have enough combined work put into it, to be a stable daily driver that is well supported and frequently updated and isn't just some isolated case of 'It's our viewer, we'll do what we want'.

    As for user interface, Black Dragon is the only viewer I've ever had to close because it has caused me a migraine. Creature habit might not mean a lot to you, but it does to me. I'd rather not have to hit a brick wall for every single little task I try to complete in a viewer.

  5. 11 hours ago, NiranV Dean said:

    Which is not going to work because you'll end up with Firestorm's situation again. You'll have too many people wanting too many different things in the Viewer and the Viewer will simply have no focus at all, a jack of all trades but a master of none. Quantity != Quality.

    You see that as a bad thing, but in the end of the day as the end user Black Dragon is completely hostile towards me and Firestorm manages to do everything I need it to do, despite not necessarily being great at any one thing.

  6. 6 minutes ago, Profaitchikenz Haiku said:

    I don't view it as trouble, I think it's a healthy situation. We get choices because there are differences.

    It is a lack of focus. When you split the efforts of people into too many products,  what you end up with is many mediocre products, that all take longer to develop. If you go into a supermarket and there are 20 different flavors of Jam, chances are they all cost more and taste worse than a store that just sells 3 good ones. Likewise you as the consumer are more likely to buy a jam from the store that sells 3 because too much choice is overwhelming and you just want a good jam, not a quirky jam.

    Most of the viewers struggle to maintain a good release cycle, some going years at a time without a stable release. I think the developers have stretched themselves too thin for the sake of independence and the end result is nobody can deliver a viewer that does everything well. And when there's no viewer that does everything well there is a lot of viewers that do a lot of things bad.

    My opinion is that if of those 8 different 3D viewers we have now, the developers should really be joining forces and focusing on delivering about three good viewers, they can contribute code from each others viewers and take the best from several and put it into one good one.



  7. The trouble with open source development seems to be that everyone goes their own way and puts the things they personally care about into the viewer.

    The end result is that we have like 6 different viewers, that are all good at one particular thing, but none that are good at everything.

    Some viewers are really speedy, but ruin it by being too opinionated about UI, taking away choices.

    Some viewers have all the choices in the world, but run like crap

    And then there's the LL viewer

    In the end all the performance improvements in the world meant nothing to me if the things I want to work don't. And thus firestorm won despite it's framerate issues lol

    • Like 1
  8. Use llGetTime to get the time since the script started or the last call to llResetTime()..

    Here's some psuedo code. I use next_stop_to_think to define how long it will take before I get going again. I always think for 5 seconds.

    float   next_stop_to_think;
          	float elapsed = llGetTime();
            if (elapsed > next_stop_to_think)
               // Wait 
              llSay(0, "Thinking...");
              next_stop_to_think = 5 + llFrand(10); // We'll stop to think again in 5 to 15s
              llSetTimerEvent(5.0); // Think for 5s
              llResetTime(); // So that elapsed will always be time since last stopped to think.
            } else {
               llSetTimerEvent(1.0); // Ensure timer resumes normal pace


    • Thanks 1
  9. This is not the solution to the problem. I am a bit passionate about this. Allow me to explain.

    There is a standard way of overcoming this issue that most game engines use, called Animation Constraints. But first you have to understand a little bit about the problem:

    Why don't our hands line up when we play our hand holding animation?

    The vast majority of animations in SecondLife are FK (Forward Kinematics) animations. SecondLife has a bone heirachy starting from the Pelvis. In an FK animation, there is no target that the bone is pointing to.

     To get your hand in position, the Torso bones, shoulder, upper arm, lower arm and finally wrist are rotated by specific degrees on each axis. Where the hand ends up is unpredictable because these are fixed rotations and the length of your bones varies based on your shape.

    How do we overcome this?

    Game Engines would use IK (Inverse Kinematics) animations. In an IK animation, we do not specify the rotation of each joint in the chain, but rather we declare a point in space where we would like our hand to end up. The computer automatically calculates the rotations necessary to achieve the desired pose, responding to your shape automatically.

    We use a system of constraints to define where these targets in space are. Sometimes constraints are relative to other bones on our own body, sometimes they are relative to the ground. Sometimes they are relative to moving points in space (Such as grabbing a door handle)

    The Original Lindens Knew

    Things are about to get very nerdy (as if they weren't already). The Lindens who created the animation system knew about inverse kinematics and bone constraints. The .anim file format the Lindens created, supports bone constraints (to an extent). In fact, the default noob animations that play when you have no AO use them!

    So why aren't we using them?

    So far the main animation tools that people use to create animations for SecondLife do not support the constraints feature that SecondLife has. Whilst Blender itself supports IK and constraints, The Avastar plugin that people export them with does not. Tools such as Qavimator do not support them either.

    So all the main third party animation tools can't take advantage of this feature built into SecondLife.

    Frustrated with this, I made a tool once to read and write animation file data, just to see how they work.

    A Linden who perhaps doesn't know much about the animation format has at some point broken ground constrained animations.

    There are also some limitations [1] [2] of the format currently, that I have made suggestions to the Lindens in the past to fix.

    • Like 3
    • Thanks 2
  10. Thanks for the information

    8 hours ago, Beq Janus said:

    For this you'd need to be able to wear and unwear an alpha layer.

    This would not work - The creators body modification would need to use BOM too to match the bodies skin. If the user wore an alpha layer, it would hide the skin on both the body and the mod. There is no way that I am aware to have an alpha layer affect only one BOM attachment. That is why I am saying, even with BOM there is still currently a need for a body to have lots of texture faces because it's the only way to have control of visibility without affecting other attachments using BOM too.

  11. @Beq Janus You talk about the issue of 'Alpha sliced' avatars creating more 'draw calls' for the viewer. You seem to have a good understanding of what is going on under the hood. What creates more draw calls in a body specifically? More texturable faces? Or the mesh being split into multiple links?

    Related: In a recent JIRA, a Linden mentioned there is a Magic Texture UUID which is built into the viewer but not built into LSL. This is IMG_INVISIBLE. Which I gather the UUID is "3a367d1c-bef1-6d43-7595-e88c1e3aadb3". The Linden mentioned that if a face uses this UUID, it is skipped from rendering 'very efficiently'. They said the effect is only known to be used in Alpha Wearables when 'Fully invisible' is checked but could not comment on if this efficient skipping is used elsewhere within the viewer. I would be very interested to know if the 'efficient skipping' applies to other worn attachments or rezzed objects as I imagine this could be an FPS booster.

    Beq also seems to advocate that bodies should not be using alpha slices any more, but instead use BOM Solely. I would like to draw attention to the fact that this would make products such as breast mods, or in my case Squeezy Stockings which change the shape of thighs by hiding a part of the original body impossible. I think that SecondLife should have some way to make such mods possible without incurring a 'draw call' performance penality, as that remains once of the big reasons why a creator is likely to supply their body split into many parts and faces, even with BOM.

  12. Sim crashed today. Everyone got disconnected.

    When we try to teleport in, we get



    Teleport failed.

    Teleport attempts are limited to 6 per minute. If you are having trouble, wait one minute and try teleporting again. If the problem persists, log out and log in again.


    This was on first teleport attempt after logging back in. None of us have attempted to teleport in 6 times.

    Some new bug introduced at some point?

  13. 14 hours ago, Lucia Nightfire said:

    Looks like 0.1 FPS to me, heh.

    Firestorm managed about 4 lol. Except, whenever I moved the camera too much, it would freeze up for a few seconds. Presumably pulling stuff from the cache on the UI thread :)

  14. 7 hours ago, Cackle Amore said:

    It's not really much different from how caspervend mass deliveries work though, just the added benefit of finally being built in.

    Although I do use Caspervend mass deliveries feature in the past, I found the effectiveness limited. In particular I sold a product  that had some systems built into it and found customers still using the old version many years later.

    The bulk of updates that seem to be done by customers are done using the CasperUpdate system, which is a script in the item that phones home and checks for new versions when the product is rezzed or attached.

  15. On 7/8/2021 at 7:43 AM, Daniel Voyager said:

    Physical avatar presence within the regions won't be available or engaging in local chat

    Think this is a mistake personally. I know people in my community who log in with their phone from time to time, and their physical presence is still appreciated even if we know they can't see us unless they enter the 3D view. For partners it can be a comfort thing too

    • Like 2
  16. I used to use a tool called Land Sensor in my sim to keep a rolling log of people who had recently visited the sim. Mostly for admin purposes and nice to know how busy the sim was or wasn't whilst I was asleep. It had an app and would let you do remote administration and stuff.

    I've been using it for years but noticed it stopped working recently. Now I can't get it to work again, the creators store seems to no longer exist. Wondered what happened?

    It's a shame because there does not seem to be a good alternative right now and it was a really useful tool.


  17. Although I can see the spirit of this development, I don't think bulk re-delivery is an effective way to handle product updates.

    A user just has to be signed off for a while  for the message to be lost to history and the update never noticed. The user receives the update to the product whilst they are not using the product and might not even care about receiving further updates on an item.

    It would be better if the rezzed item itself detects when an update is available and prompts the user. That way the user is only prompted from items they are actually using.

    I did make JIRA's for this but I got the canned we won't do it response iirc.

  18. In case anyone is having this problem in the newer version of Firefox, the menu is different:-


    1 - Go to Settings

    Click the Hamburger Menu in the Top Right and find Settings:


    2 - Manage Cookie Data

    Select Privacy and Security from the left hand menu,
    Scroll down to Cookies and Site Data,
    Click Manage Data...


    3 - Delete Secondlife Cookies/Site Data

    In the dialog window, search for SecondLife, Select the Sites
    Click Remove Selected and then press Save Changes.




    Hope it helps

  • Create New...