– Jelly babies will take over SL soon (AKA how linden lab is planing to break second life) –

So theres a lot of talk about the upcoming patch that will break SL visually, so i think its time for me to rant about it too.

So we all know how laggy and unplayable SL can be, its probably one of the biggest problems with second life today.

LL is going to do what LL does best, implement a half assed fix for a symptom instead of fixing the cause of the problem, optimizing the viewer, fixing how it handles video memory, making the viewer use full capabilities of your videocard’s processing power(it uses CPU to calculate and only uses GPU to draw), And maybe even making a D3D version of the client for windows users.

JB
Anyway, this “solution” that LL came up with will undermine the whole point of mesh avatars and i suspect this will make a lot of people just quit SL in the log run. It will Automatically derender any avatars exceeding whatever arbitrary render weight setting that you or LL chooses for you by default. You wont be able to wear your fancy mesh outfits, bodies and heads without being visually muted for everyone around you, you will have to go back to using the linden body and linden avatar body and its crappy body paint clothing layer. (It will tell you when you are muted though)

Current problem with render weight calculation is that it sums up everything, including the LOD for every object you wear(LODs that the game doesnt even use because of a rigged mesh LOD bug),  instead of what your video card has to actually draw on your screen. This calculation is horribly inaccurate, it doesnt tell you what actually makes you lag, and people just abuse the rigged mesh LOD bug to cheat the render weight count.
To calculate real render weight, the viewer would need to calculate it in real time and only the things your video card has to actually render, anything else added to that just undermines the whole calculation. You can look at a perfectly fine avatar low polygon avatar that for some reason has an absurd render wight and not lag looking at it, and you can look at an avatar that has an excessive amount of polygons but abuses the LOD bug that makes it have a low render weight, and it makes your viewer go 5 frames per second (People cheat render weight by using single triangles for all the LODs)

So here’s what i think should happen first before this feature is implemented.

  1. The rigged mesh LOD bug has to be fixed, currently the game doesnt use LODs and displays the same high detail model on all distances, this, apart from texture memory issues, is what they should be focusing on if they really want to fix the lag.
  2. The render weight calculation has to be done in real time and only count things that are being rendered, if this is not possible to do without rewriting the whole code, at least make the render weight calculation only count the high detail objects and not the LODs because its absurd, your wearing 1 object at the time, not all 4 different detail versions of it.

Btw one legit benefit of this jelly baby feature is that it would make graphics crashers impossible, instead of implementing this to the UI, they should instead just leave it in the debug settings menu but set it to a certain max amount by default so that it would still show everyone correctly but at the same time would automatically derender any graphics crashers.

 

About utilizator404
What is this for?

21 Responses to – Jelly babies will take over SL soon (AKA how linden lab is planing to break second life) –

  1. Pingback: Are Second Life’s Jelly Babies Breaking SL? | Nalates' Things & StuffNalates' Things & Stuff

  2. The Unstoppable Force says:

    That is disturbing … looks like a hear see and speak all in one XD
    Let’s hope they don’t break mesh, one of the last games in town.

  3. The Unstoppable Force says:

    Seen a few more of these posts, this should prove to be an interesting social test in months to come … lol

  4. Venompapa says:

    Hm…. one more reason to walk around naked with my kemono, in clothes im over 120k render weight, without clothes and with hair+head+neko tail+neko ears+my collar im only on 78k render weight, side note in their current beta viewer which holds this feature the default render weight limit is 80k

    so now i can go around naked and whoever complains i can just say *****you if i put clothes on im being a colorful noodle? XD

    But of course meanwhile at crowded clubs and other places ppl will lag to death same way from these terrible TMP and similar mesh avatars due their cheated low render weight.

    *claps* congrats LL.

  5. The_Copulator (aka That whore Bella) says:

    It’s clear… We need a replacement for SL, how is casper tech’s miivo? coming along?

  6. asamiimako says:

    On the one hand I don’t think this is that bad of an idea, avatars are by far and away the biggest FPS killer, and while the viewer could be optimized (D3D wouldn’t magically solve any problems by the way, OpenGL is way more flexible and if done right would surpass D3D anyway), it’s not that bad at doing what it does. Content creators just suck to ridiculous levels in terms of optimization. I’ve seen LODs get used for Rigged Mesh on occasions so I’m not sure about this whole bug you’re talking about, but on the other hand I do think the default settings will be troublesome for this feature.

    Honestly LL should just implement some sort of avatar impact system like Land Impact which would force creators to do things the proper way instead of the ridiculous 3-4 level subdivision meshes you see today.

    Either way, maybe this will let us say goodbye to all the shitty mesh bodies with multiple overlapping layers because “Muh texture clothing.” Especially TMP bodies, those things are atrocious beyond words.

    • Venompapa says:

      Funny thing mostly not even the avatars are my FPS drop problems but certain shitty built place which even lags me when its butt empty o_O but yeah this thing not really that bad idea, then as i seen we can blacklit/whitelit people separately regardless of your current rende weight limit settings, i like it better than derendering laggy avatars which even makes their nametag gone poof :D

      Then about the multiple overlapping layers on mesh bodies, first i dont see why the hell creators does not make these optional, i mean fuck.. wear it only if you actually use it :S but no, all these crap are no mod and cant even get a rid of the layers and its till there rendered 3 or four times. Also i still would be glad if LL adds texture layering for mesh, similar to the LL body texture layering, just bit more limited, like 3 or 4 layers per texture face, since we have this shiny serverside baking its could be done serverside anyway then its just sends you the layered texture for display, this would be the best because wont need render the damn mesh body four times, then wont need render four damn texture per layer which is mostly keep getting blurred out on these bodies for me so i need hit the damn refresh on them to see their tattoo or whatever layers actually using x.x

      • Venompapa says:

        Forgot to add, sadly this update wont say goodbye for shitty mesh bodies like TMP because of the cheated render weight with the all triangle only LOD models, funny thing TMP mesh body has lower render weight than the Kemono body x.x

    • with D3D SL would use all the capabilities of your GPU, it would allow SL to use more than 512mb texture memory and you wouldn’t need to split the scene up into multiple instances of GL to bypass the dumb 8 light per scene limit, and all the other dumb stuff. As proof of concept that SL doesn’t even use your GPU, i ran 8 windows of SL, all of them ran smoothly, i started teleporting around and loading stuff and going to large crowds of people on one of the viewers, it started to lag and go like 5 fps, the rest of the viewers till ran smoothly. If that one viewer had full access to all the resources of my video card, it wouldn’t be lagging or the rest of the viewers would be lagging too because that one ate up all the resources.

      As for the LOD bug, rigged meshes dont drop in LOD as you zoom out, by the time rigged and rezzed meshes drop to LOD3, rigged meshes only drop to LOD1

      Here’s an example, Green is unrigged mesh attachment, red is rigged mesh attachment, blue is rezzed on the ground. http://s3.postimg.org/w4iebbl9d/zoom.png. The TMP body circumvents the render weight limit by having a bunch of triangles for LODs

      Also as Riana said, most of the lag is also caused by terrible sim builds with lots of 1024×1024 textures on everything, places like malls with lots of vendors.

  7. Joseph Baker says:

    Hate to break it to you, but after this post I’ve done some research on this “Jelly Babies” issue and they aren’t adding it, they’re moving it. It’s always been in SL’s viewer and was a development tool. They’re making it so everyday users without their advanced or develop menus available can switch on “Jelly Babies” mode to cap off avatars that may be lagging them. It’s client side, as one would expect. This “new” feature is not only likely to be based on preference and able to be toggled, but it can likely be customized allowing users to set custom render caps. I don’t believe it will be “automatic” by any means, think of it as adding a new option in the Graphics tab of Preferences. While I’m at it, I’d like to agree in the issue of the improper render weighting, that really needs to be fixed.

    • Yes i know, as i already mentioned in my post

      “instead of implementing this to the UI, they should instead just leave it in the debug settings menu but set it to a certain max amount by default so that it would still show everyone correctly but at the same time would automatically derender any graphics crashers.”
      But they arent just adding a button for it, they are reworking the whole thing to include the Vram usage and other info into it too, and notify you when you exceed the default limit.

      and yes i know its something a user can set himself, but by default its set to 80k by linden labs

      “It will Automatically derender any avatars exceeding whatever arbitrary render weight setting that you or LL chooses for you by default.”

  8. Seffa says:

    Actually it’s pretty cool that they’re making the “jelly babies” mode easier to access, if indeed that is what they’re doing. Things like the LOD bug seriously need to be fixed for it to be effective though.

  9. That Guy says:

    Setting avatar attachments aside, the “LOD bug” shouldn’t be “fixed” because larger structures (any mesh for the environment at higher scale) have the LOD falloff scaled differently, so that the second LOD and up is streamed to the user, but not really used (also depending on the intended distance you want the asset seen of course). So it’s actually wasted memory.

    Technically we should have the option to disable the large-scale asset from even HAVING the second and up LODs. Since we don’t, we make them single triangles, as to make sure those unseen/unused LODs aren’t to heavy when streaming to the user. But yes, for irresponsible avatar attachments that use more geometry by themselves than most modern MMOs entire rendered maps, yeah, the LOD’s nice to actually have…

    • Rezzed objects dont have the LOD bug, only rigged mesh attachments, and yeah large rezed objects shouldn’t have LOD.

      • That Guy says:

        Obviously the use of the term “LOD bug” I misunderstand then. Because for large scale objects it is yes a good idea to make LODs one triangle per material. It does lower the LI, but can’t be considered ‘cheating the system’ as the lesser LI is actually honest without the extra bulk streaming. Well, I guess it’s good that’s cleared up. My apologies. Best regards then.

      • yeah i do that too with large objects

  10. NiranV Dean says:

    I hate to blow this up but:

    A:
    “You wont be able to wear your fancy mesh outfits, bodies and heads without being visually muted for everyone around you, you will have to go back to using the linden body and linden avatar body and its crappy body paint clothing layer.”


    This is simply not true. I can wear my full Solarian Avatar, with all clothes and some very inefficient flexi prim/sculpt hair and only get ~ 38k ARC.

    The problem here are misc attachments, not meshes, if anything the ARC calculation favors meshes massively, which is why this system is somewhat unreliable. Specifically sculpt attachments, flexi prims, alphas (including completely invisible prims and/or objects) and everything else that makes use of many small but detailed seperate objects/prims, for example, most old furry avatar handpaws, backpaws or faces are attachments that will massively tax your ARC, same goes for many old hairs like those of Magika (which i’m wearing myself). My hair taxes in with ~ 25k ARC, while the entire avatar itself + clothes only goes to 10k (with proper LOD’s).

    In other words, the attachments people are wearing are the problem, they are simply inefficiently meshed/sculpted/build and often the root of the problem.

    B:
    “To calculate real render weight, the viewer would need to calculate it in real time and only the things your video card has to actually render, anything else added to that just undermines the whole calculation. You can look at a perfectly fine avatar low polygon avatar that for some reason has an absurd render wight and not lag looking at it, and you can look at an avatar that has an excessive amount of polygons but abuses the LOD bug that makes it have a low render weight, and it makes your viewer go 5 frames per second (People cheat render weight by using single triangles for all the LODs)”


    I know about people cheating with LOD’s which simply shouldn’t be allowed but lets start with the first things first, ARC is calculated real time (unless your real time means something else than my real time), it updates constantly and it calculates in everything the viewer has to render, including invisible meshes/prims/sculpts which are still rendered (and are massively more taxing than visible ones), i am not sure if it includes LOD’s into the calculation but it would make sense somewhere, to punish high amounts of polygons in all LOD states, that also means that people can cheat it, which is not the problem of the calculation but rather a problem of the uploader allowing it but then again you cannot really completely stop it, you could add dynamic limits, sort of like the lowest LOD has to have at least 20% but lower than 50% of the original’s polygon count, that way people could still somewhat cheat by always using the lowest possible value but at least it would make it a bit better, it would massively punish people for uploading meshes with extreme poly counts.

    C:
    “LL is going to do what LL does best, implement a half assed fix for a symptom instead of fixing the cause of the problem, optimizing the viewer, fixing how it handles video memory, making the viewer use full capabilities of your videocard’s processing power(it uses CPU to calculate and only uses GPU to draw), And maybe even making a D3D version of the client for windows users.”


    I agree that LL is only treading the symptoms instead of curing the root cause. BUT, the root cause for our performance problems in SL are many, optimizing the viewer is just a tiny fraction and will sadly not help much, there is not much to optimize without totally rewriting the render pipeline and using much more efficient ways of rendering everything, even that would only cure the symptoms for a bit but not actually fix the root cause. The root cause for our issues is not the viewer, its the content in SL, every willy-nilly can create his shit in SL and that may be SL’s biggest feature but also it’s biggest problem, there is no one, no guide, no nothing, no quality control and especially no way for a normal user to know what’s bad for him. Consumers want to consume, so they buy what they like but most consumers don’t care about ARC or efficiency in SL, they rather just complain that SL is slow and unoptimized which is only a tiny fraction of the actual bigger problem, themself. Content creators create without any supervisor watching them, there’s no quality control, they can do whatever they want and the users who buy that stuff don’t care, they don’t want to know anything about all this, all they care about is that they can get their super highly detailed texture spamming clothes on, what SL really needs is its user base to wake the fuck up and stop buying shit, get informed about at least some basics so they can roughly tell crap content apart from good content. On the other side those content creators should finally stop squeezing their 1024×1024 textures into everything, a 1024×1024 texture for a single body? fine, just remember you could squeeze 4 x 512×512 squares into that one, that means you could squeeze the upper body, lower body and head and another extra into it, instead they spam 1024×1024 textures for every body part.

    Honestly, SL’s way of setting a memory value is…. weird… it’s extremely limited and inefficient on top of that, i unlocked the memory values in my viewer allowing me to freely increase the scene and permanent system memory to up to 1024mb, which works just fine, the viewer can use it perfectly fine, so it’s not really a memory handling issue but rather a stupid way of how the memory setting works.

    Also, one viewer cannot utilize the full capabilities of your GPU simply because of the same reason most other applications can’t, something in your system is bottlenecking hard and that’s the CPU, SL is not multi-threading friendly, using “only” 2 cores (the rest are dynamically used due to Windows’s multi threading system) and those not even efficiently, its mostly just the first core doing most of the work and the second for some offload, if SL was fully multi-threading optimized we would see a massive performance increase (especially on AMD CPU’s), at least as far as the rest of your system goes and obviously as far as the current scene allows, having 6 million polygons onscreen with a fuckton of 1024×1024 textures will still do no good.

    —-

    Back on topic to the jellybaby thing, i think LL did a great step forward but sadly gave in at the very wrong moment, the problem of the new derender system is simply that you can completely negate its effect by turning it “off” (setting it to unlimited), i think they should have forced a hard value (something like 200.000 ARC) and slowly lower it as time passes, also explaining people why and how they can get better ARC and how its going to help SL so people actually understand what’s going on. The whole system message roughly telling you how many people derender you was a perfect chance to punish high ARC people and make people reduce their ARC and look for optimizations. LL totally ruined it because “we wanted options” for the wrong kind of features.

  11. A. The solarian avatar is made by a person that knows what hes doing, i have did some testing myself to see what i can wear, my favorite hair alone were 70k, while the limit by default is 80k.

    B. By real time i mean, as in only show the rendering cost of whats actually being rendered on the screen, if you zoom out and LOD is swapped, render cost should also go down too, zoom back in and cost goes up again as the model switches back to high detail. What we have now is all 3 LOD objects get added to the rendering cost as if you were all rendered at the same time.

    C. Yes the problems are many, but some of them are a lot bigger than others, and its those problems that LL could be addressing instead of punishing the user for the shittyness of their own service. Some of those problems are easy to fix, such as proper LOD display for rigged meshes or letting the viewer use more than 500mb of video memory.
    The content itself can be regulated better too by let’s say popping up a red warning in the uploader, notifying you about your excessive polygon counts and maybe even linking the user to some retopology tutorials and a basic common sense crash course, and maybe adding some hard limits on how many 1024×1024 textures or how much texture memory an attachment can have.

    As for the CPU bottleneck thing, that’s the whole problem, why does SL even involve the CPU into rendering the scene to begin with, all of that should be handled by the GPU alone, no other proper videogame does that, they only use the CPU to calculate physics and shit like that, but not process geometry.

    And no, i think its great that they gave us the option to just turn that shit off compleatly, id rather lag miserably in a crowded dance club than miss out on some hot piece of ass that got derendered cuz the game couldn’t handle the weight of dat booty, but more importantly, i would like everyone to see me as intended too, other wisewhats the point in even having an avatar.

    And while this feature would help reduce the lag caused by other avatars, what about the lag cause by terrible sim builds? r all those malls with full of 1024×1024 vendor images and all that other rezed out crap with all its 1024×1024 textures on everything, lagging the shit out of you even when the sim is empty, jelly babies wont fix that.

    Also polygon counts aren’t even the problem, SL is a monster at how many polygons it can process in real time, rendering all those million sculpted prim hairs that have more polygons in them than an entire world of warcraft instance during a raid, just turn on wireframe mode and look at someones hair and be amazed how SL can process all of that and still run at a smooth 60fps, its all the 1024×1024 textures on everything, terrible prim builds and improper LOD swapping for rigged meshes is whats killing your frame rates.

    • NiranV Dean says:

      B: It does, somewhat. Your Avatar size and the surface area will change depending on the current LoD loaded, the ARC doesn’t tho. Which is… kinda weird, i might want to take a look into the code myself to see why.

      About the Texture thing, that’s not quite right, the textures in itself do not cause your framerate issues, they can’t due to SL’s limits. The Viewer can use a given (depending on your settings) amount of your texture memory, i think we all know what happens when games use more texture memory than your GPU has, right the GPU starts caching textures in and out, causing massive frame loss, this is not directly the case here as this GPU texture limit can basically never be reached unless you of course set your Video Memory slider to something ridiculously high that will allow the Viewer to actually allocate more texture memory than your GPU has, unless that happens, all the textures do is reducing your framerate as long as they are being downloaded and decoded as well as cached into your memory, after that, your framerate should rise again no matter their size, that doesn’t make them less of a problem thought, they still cause the famous texture trashing which is not a bug but a feature of the Viewer which just tries saving available texture memory by trashing old textures or reloading them in lower resolution.

      About the polygon thing, yes and no. There are meshes that have many polygons, causing a normal, mediocre framedrop, there are also meshes out there with almost the same polycount causing much higher framedrops and even completely unstable framerates, i couldn’t yet figure out why exactly that is since i do not own any of these meshes (human meshes, all of them) and i probably wouldn’t be able to reliably find out since they are most likely no mod but i’m certain its not caused by their textures, i’m not a mesher so i haven’t had any experience in what exactly causes this unreliable behavior but i’m sure that it has something to do with the way the meshes are made as i heard there was something going around for a while that caused faulty meshes to be uploaded which cause massive framerate issues. Also as far as i tested (long ago when meshes were introduced), SL is only able to render 6 million polygons roughly, before it will start derendering old stuff, i remember one of the early mesh avatars managed to break these 6 million and caused even my own avatar to derender.

  12. Immediately set it to “no limit” in my Firestorm preferences … just eww

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s