Jump to content

Jelly babies


You are about to reply to a thread that has been inactive for 2818 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts


Bryce Kidd wrote:

The render my friends setting needs to be as persistant as derender is. Especially for the changeover period as everyone adjusts, especially those in the Fur and Anime communities who will want to see their friends wach time they log in.


this

a whitelist of friends avatars, exempting them from being jellybabied is pretty essential for the social component of SL

 

eta: avatars as not everybody we might need to exempt are on our friends list. Live performers for example 

Link to comment
Share on other sites

  • Replies 130
  • Created
  • Last Reply

Top Posters In This Topic


wherorangi wrote:

by jumping I mean I am playing scripted dance animations which can be seen in the variance of FPS on the gfx card. The FPS range is about 50 to 80 average 58.4. The variance is wide due to:

a) occlusion (more or less) triangles in the view as avatar turns and moves, and

b) the work the main processor (i7 in my case) has to do to prep the data for the 660, and

c) the time taken to transmit data over the internal bus, and retrieve data from memory and/or from cache

seems to me that while mesh objects can contain less triangles than oldschool prims, it takes longer for the main processor to prep the data than it does for prims, due to the organic shape of mesh clothing (more math calculations)

seems to me also that in the metric calculation there is a understatement toward mesh and away from prims, meaning that I am not sure that the work that the main processor has to do (in a type vs type comparison) has been factored in as well as it might be

adding more avatars to the view doesnt change the basics of this. There's just more data of each type to manage and render


I'm not sure that's completely correct. With a mesh, it's more work to calculate the first one but once it's calculated it's consistent and repeatable. One Maitreya mesh body will produce a substantial drop in framerate, but going to the Maitreya store and watching a dozen avatars wearing Maitreya bodies doesn't produce a drop a dozen times as high becase many calculations can be re-used.

With the formula multipliers that are "unreasonably high", they calculate things that are going to potentially and often unpredictably change every frame - with flexiprims the location of the vertexes will change when the object moves, and with alpha-blended textures each pixel has the potential to have a different value based on the other textures seen through that prim. (Incidentally, ChinRey is wrong - prims with alpha masked textures aren't subject to the alpha texture multiplier.) Your flexi-hair tests were done in situations where the only textures involved were the hair itself or system-generated land and sky textures instead of a changing background.

I'm not saying that the formula is completely accurate but I don't know enough about the rendering engine to say exactly how accurate or inaccurate it is. I do know that flexiprim rendering has been revised more than once in the five years I've been around here, and being in an area with a lot of alpha-blended overlapping grass prims is/has been death for framerates, at least with my old computer.

 

Link to comment
Share on other sites


Theresa Tennyson wrote
ChinRey is wrong - prims with alpha
masked
textures aren't subject to the alpha texture multiplier.


Oh, you must have misunderstood me there. What I meant is that an object completely hidden by alpha masking still has a render weight although there isn't actually anything to render at all. No alpha mutliplier but the base weight and the texture weight are still applied. This can have quite an impact on the nominal render weight of mesh bodies and body parts where it's not uncommon for more than half the tris to be alpha masked away.

Link to comment
Share on other sites

i just point again at the Statistics Bar image. The red band shows the variance in the frame rate, between 50 and 80 frames a second, due to my avatar turning exposing more/less triangles that need to be rendered

all of the resources needed to render the triangles are already downloaded, and most of the data is already in memory. Is still a whole lot of work for the processors to do

Link to comment
Share on other sites


Theresa Tennyson wrote:

I'm not sure that's completely correct. With a mesh, it's more work to calculate the first one but once it's calculated it's consistent and repeatable. One Maitreya mesh body will produce a substantial drop in framerate, but going to the Maitreya store and watching a dozen avatars wearing Maitreya bodies doesn't produce a drop a dozen times as high becase many calculations can be re-used.


This is not a reliable test in any way; running three alts on the same computer introduces way too many unknown variables.

However, three alts on that same darned sky platform over that same darned sandbox, one on the SL Viewer, the other two on Firestorm:

Render complexity readouts for the same avatar differed slightly. Even the two alts using the same viewer on the same computer showed slightly different render weight for exactly the same avatar.

  • Base fps with all avatars completely masked: about 40
  • With one avatar wearing a well known mesh body (rw about 4000): about 32
  • With all avatars wearing that same mesh body: about 30
  • With all avatars wearing different mesh bodies (total render weight about 18 000): about 30
  • With all avatars wearing very different flexi hairs: (total render weight about 168 000): about 24

Using AOs to introduce some movements (three different ones of course) didn't seem to have much effect.

It was very hard to get any reliable readings though since my computer was so heavily overloaded. During all tests fps kept fluctuating, sometimes dropping down well below 20. A test like this should be done with more than three avatars running on separate computers to be reliable.

Of course I should also have tested with three identical flexihairs but I couldn't find one really high ARC style that all three avis had. In any case, I'm done with my tests. They've already stolen way too much of my time.

Inconclusive as this test was, it does indicate that multiple fitted mesh bodies "stack up" better than multiple flexis. A plausible explanation is that they all are built on the same skeleton and that even different bodies from different makers use pretty much the same vertice pattern (probably the system avatar with all edges split in half and the vertices shifted for a different shape). Another explanation is that the lag from flexihair depends more on the alphas than on the moving vertices and that alpha lag doesn't stack up as well as "flexilag" does. This of course raises quite a few interesting questions but maybe we shuold leave them for later...

I have to emphasize, in case there is any doubt about it, that I do not know what the answer is. I do not even know if it is possible to calculate actual render cost precisely enough to make QuickGraphics a useable feature. But it is clear that what we have now is not nearly as good as it could be and needs to be-

There is something fundamentally wrong with how the viewers and servers determine an avatar's ARC. You run the same data through the same software several times and you get different output, in this case different enough that the deviation can be more than enough to determine whether an avatar should be shown in full of "jellybabied" out.

Regardless of how the formula is handled by the software, it has serious flaws in itself. We've barely touched the matter of new materials. Alpha masking does not alter an object's render weight. Hide the whole object from the scene with alpha masking and it still shows up with exactly the same render weight as if it had been fully visible. Normal and specular maps do not alter an object's render weight. Add as many and as high resolution maps as you like and there is absolutely no change in the render weight. Those omissions are more than enough to cause serious doubt about the reliability of the formula as a whole. What is the multiplier for fitted mesh btw? We don't actually know. The documentation mentions rigged mesh and we've only assumed that the same multiplier is used for fitted mesh.

In the beta testing feedback thread I asked Oz Linden about how QuickGraphics had been tested. His answer was that they had tried to visit different places with different avatar lag levels using different computers and that they had found good "safe" threshold levels for all occasions. Of course you can use QuickGraphics to eliminate all potential avatar lag issues! Just set the threshold low enough that everybody become jellybabies. Job done! Not!

He did not in any way indicate they had done any more thorough tests than that and never responded to followup questions.

Link to comment
Share on other sites


ChinRey wrote:

I have to emphasize, in case there is any doubt about it, that I do not know what the answer is.
I do not even know if it is possible to calculate actual render cost precisely enough to make QuickGraphics a useable feature
. But it is clear that what we have now is not nearly as good as it could be and needs to be-


I don't think that there will be a practical way to make that formula accurate. There are way too many dependencies with rendering scenes.

I did also a simple test @1920x1080, a rather extreme one maybe, but anyway. (Of course I had to turn off VSync for this.)

Simple 4 regular prim object with a 512 alpha blending texture. RW 464.



Small sized attached above my head. FPS 174.



Same object, only scaled larger. FPS 125. :matte-motes-whistle:

Same object, same render weight. Just the massive overdraw of the large object causes a FPS drop of almost 50.

 

Link to comment
Share on other sites


ChinRey wrote:


There is something fundamentally wrong with how the viewers and servers determine an avatar's ARC. You run the same data through the same software several times and you get different output, in this case different enough that the deviation can be more than enough to determine whether an avatar should be shown in full of "jellybabied" out.


It appears that previous viewers took the render weight of some objects, especially sculpted or tortured prims,"on the fly" at whatever LOD they were at when the calculation was taken. This number was somewhat persistent until something made the viewer recalculate it. This meant that the draw weight of those items would be quite variable, and would explain why your alts (who must have been running Firestorm) were seeing different numbers for the same avatar - they were at different distances from it.

The jellydoll viewer calculates the draw weight of all items at the maximum LOD so that it can make the muting consistent - otherwise avatars popped in and out of being rendered. I find the numbers for the current viewer quite consistent. This means, though, for many overenthusiastically sculpted/tortured prim creations this means that the draw weight will be incredibly, and unrealistically, high. My aunt has a hairstyle from a certain old-school hairmaker with a draw weight of a mind boggling 697,511 (211 twisted torii - if it was physical it would crash the server). If you zoom in on it you are very definitely drawing over 3 million triangles per frame just for that hair, but that number will drop off rapidly in the real virtual world. (If she throws that hairstyle on and a pair of Stilletto Moody shoes on with it I she has an ARC of over a million. Intense... Turn your RenderVolumeLOD up around her and dispair.)

As far as the server number for draw weight, I used a scripted draw weight monitor in a trafficked area and I could see the numbers change for the same avatar as various people entered and left the area, suggesting that it works exactly the way the wiki (and I) suggested. Sometimes in a quiet situation it would return exactly the same number as the jellydoll viewer but it was often lower and variable. particularly with outfits with non-mesh attachments. The server number will only be an approximation until all viewers use a criteria that produces consistent numbers.

Link to comment
Share on other sites


wherorangi wrote:


Bryce Kidd wrote:

The render my friends setting needs to be as persistant as derender is. Especially for the changeover period as everyone adjusts, especially those in the Fur and Anime communities who will want to see their friends wach time they log in.


this

a whitelist of
friends
avatars, exempting them from being jellybabied is pretty essential for the social component of SL

 

eta: avatars as not everybody we might need to exempt are on our friends list. Live performers for example 

I strongly disagree.

There should be no exceptions other than the score.

This is not a policy or drama setting - it is a technology setting to protect your system from harmful stress.

Whitelisting people won't help you there.

The solution is to convince people to use newer optimized goods that have lower complexity scores.

 

Link to comment
Share on other sites


wherorangi wrote:

here is me nekkid and just wearing my flexiprim hair. And wearing my most see-thru outfit. And only 75k complexity



Flexi with transparency naturally should have such high scores because it is rendering transparent moving objects.

The math to calculate in real time what colors should appear in view when there are dozens to hundreds of different partial shapes between the end point and the camera - and they are constantly shifting due to motion.

In 3D art, rendering something like the shot above could add hours to days to an art quality render. In real time with much less complex graphic engines and a lot fewer light calculations - it is still brutal on a system to render it...

 

Link to comment
Share on other sites


Pussycat Catnap wrote:


wherorangi wrote:


Bryce Kidd wrote:

The render my friends setting needs to be as persistant as derender is. Especially for the changeover period as everyone adjusts, especially those in the Fur and Anime communities who will want to see their friends wach time they log in.


this

a whitelist of
friends
avatars, exempting them from being jellybabied is pretty essential for the social component of SL

 

eta: avatars as not everybody we might need to exempt are on our friends list. Live performers for example 

I strongly disagree.

There should be no exceptions other than the score.

This is not a policy or drama setting - it is a technology setting to protect your system from harmful stress.

Whitelisting people won't help you there.

The solution is to convince people to use newer optimized goods that have lower complexity scores.

 

lets say that my computer can handle 4 million triangles. Me and my friend are at a live performance. There's 65 people at the concert

i am wearing 1 million triangles. So is my friend, and so are the performers (in total). Which leaves 1 million for everything and everyone else. Given that I have to make choices about what gets rendered fully on my computer, then I choose my friend and the performers

while also knowing that I am not going to be rendered by anyone other than my friend who has the same kinda computer as me

 

 

Link to comment
Share on other sites


Pussycat Catnap wrote:

I strongly disagree.

There should be no exceptions other than the score.

But there is. Just click on a jellybaby and select "Show in full" (or something like that).

 


Pussycat Catnap wrote:

This is not a policy or drama setting - it is a technology setting to protect your system from harmful stress.

 I don't get the impression that equipment poretection has ever been a significant factor here. I may be wrong but it seems to me that it's all been about improving visual quality by reducing lag. Gpu deterioration is mainly a European problem. (It's not legal to use lead to stabilizie the solder here so electronic equipment made for that market is far more vulnerable to heat damage than equpiment sold elsewhere in the world.) It's quite plausible LL isn't aware of how important this is to a large number of the users.

 


Pussycat Catnap wrote:

The solution is to convince people to use newer optimized goods that have lower complexity scores.

That is one of my main points too. QuickGraphics has no value whatsoever if people don't actually use it, and they don't want to use it, the negative effects are plain for anyone to see while the positive effects are very subtle.

It's going to be a very tough sell and that is why I keep insisting on testing. Not just testing btw, that's not enough, it's also important to document the tests. Hard, irrefutable facts are the only really effective argument we have if we want to convince people that QuickGraphics is indeed a good thing but right now we don't have any hard, irrefutable facts.

Anyway, the JIRA has now been triaged and marked as "Minor" which essentially means that no matter what we do or say, nothing is actually going to happen. I don't see any point in continuing this discussion.

Link to comment
Share on other sites

a positive thing about this is I went to mow lawns and map teleport to the back sim and booooom!! insta TDR gfx crash. Some idiot with a gfx viewer crasher. ufffftt !!!

so relog and set the complexity slider to low 19999. Back to same sim, same idiot. bite me you egg !!! q; (:

previously the only other way to stop this was to block the person, but sometimes don't get enough time before crasho

so thats good  (:

Link to comment
Share on other sites

Since no one has addressed the logic about why scaling it up increased it's Render Cost, ~  Surface area is factored into the calculation~

 

You can read more on it at ~  uhm ~ ::magically produces a wiki-link:: 

http://wiki.secondlife.com/wiki/Mesh/Rendering_weight

 

It's interesting to note that the surface area of the alpha texture affected your FPS so drastically.  I wonder why that is the case.

Link to comment
Share on other sites


polysail wrote:

Since no one has addressed the logic about why scaling it up increased it's Render Cost, ~  Surface area is factored into the calculation~

 

You can read more on it at ~  uhm ~ ::magically produces a wiki-link:: 

 

It's interesting to note that the surface area of the alpha texture affected your FPS so drastically.  I wonder why that is the case.

Yeah, but obviously that doesn't apply to the box prim object, as can be seen in the screenshots. It's display weight is the same for both sizes.

The reason of the drastic FPS drop is due to the overdraw. These 4 prims covered the entire screen, so each pixel has to be rendered multiple times instead of only once. At a resolution of 1920x1080 this causes a much higher pixel fillrate. It's why alpha blending is expensive in general.

Link to comment
Share on other sites


Drake1 Nightfire wrote:


ChinRey wrote:


Drake1 Nightfire wrote:

my bi-pedal mesh avs are still very complex, and will remain so after the new skeleton. They are done by some of the best in SL.


Oh, in that case there's no need to worry. If it's made by some of the best, it shouldn't take more than a week or two before you receive a lower lag upgrade. Problem solved.
^_^

Right, because the new skeleton will vastly change how a rigged mesh Lycan is rendered and will lower the ACI to almost nill. 

Well, in this image, my mesh Lycan that I made years ago, is way under the limit, and he is wearing mesh hair all over his body. Of course, I plan on updating him, as he will massively benefit from the new bento skeleton. It's actually pretty easy to get decent scores, if you understand what you are doing. My goal on the next version is to keep him under 20k.

 

Here is the wolf I made with the Bento skeleton. Notice how low his rendering cost is. He also utilizes bump map textures and specular map textures.

 

Link to comment
Share on other sites

  • 2 weeks later...

Can you explain in more detail what you mean by "Avatars are thrown far from my avatar"?

Is it just the jelly avatars this happens to?

Are you just seeing the jelly avatars displaced slightly (1-2m) from where they should be?

The jelly avatars behave like standard imposter avatars in that their position isn't always accurate, especially when they are sitting & if the jelly or imposter avatars are playing an animation, the animation isn't updated very frequently.

I'm not very sure if that's the effect you are describing though.

Link to comment
Share on other sites


Medhue Simoni wrote:


Drake1 Nightfire wrote:


ChinRey wrote:


Drake1 Nightfire wrote:

my bi-pedal mesh avs are still very complex, and will remain so after the new skeleton. They are done by some of the best in SL.


Oh, in that case there's no need to worry. If it's made by some of the best, it shouldn't take more than a week or two before you receive a lower lag upgrade. Problem solved.
^_^

Right, because the new skeleton will vastly change how a rigged mesh Lycan is rendered and will lower the ACI to almost nill. 

Well, in this image, my mesh Lycan that I made years ago, is way under the limit, and he is wearing mesh hair all over his body. Of course, I plan on updating him, as he will massively benefit from the new bento skeleton. It's actually pretty easy to get decent scores, if you understand what you are doing. My goal on the next version is to keep him under 20k.



 

Here is the wolf I made with the Bento skeleton. Notice how low his rendering cost is. He also utilizes bump map textures and specular map textures.



 

I wasn't talking about new mesh creations.. Polysail was saying that Bento would lower the ARC of existing mesh avs.. I was asking how.. She never did give a straight answer on that.

Link to comment
Share on other sites


Drake1 Nightfire wrote:


I wasn't talking about new mesh creations.. Polysail was saying that Bento would lower the ARC of existing mesh avs.. I was asking how.. She never did give a straight answer on that.

Just a guess, but I think she was saying that if existing mesh avatars were remade using Bento, then they would be much more efficient. There is nothing in Bento that would just magically make old content more efficient. That said, I'm sure some of the calculations for Avatar Complexity have been adjusted since before bento, so it might seem like bento made some of them more efficient.

Link to comment
Share on other sites


Medhue Simoni wrote:


Drake1 Nightfire wrote:


I wasn't talking about new mesh creations.. Polysail was saying that Bento would lower the ARC of existing mesh avs.. I was asking how.. She never did give a straight answer on that.

Just a guess, but I think she was saying that if existing mesh avatars were remade using Bento, then they would be much more efficient. There is nothing in Bento that would just magically make old content more efficient. That said, I'm sure some of the calculations for Avatar Complexity have been adjusted since before bento, so it might seem like bento made some of them more efficient.

Oh I'm fully aware of what she meant. She just kept saying "Bento will lower ARC" without providing any info as to how. The problem is that previous mesh heads and avatars will have to either be remade or a new version made. And i doubt any mesh maker will give them away as "updates." Bento should have been implemented before mesh came out.

Link to comment
Share on other sites


Drake1 Nightfire wrote:


Bento should have been implemented before mesh came out.


Rofl, that is pretty funny.

 


Drake1 Nightfire wrote:


The problem is that previous mesh heads and avatars will have to either be remade or a new version made. And i doubt any mesh maker will give them away as "updates."


Well, if the head, or body designers don't, meaning make a new version, then they will be left in the dust, as the new bento heads will be many times better just in efficiency alone. As it is, most people with current mesh heads won't even be seen by others because of the Avatar Complexity scores that these current mesh heads produce.

Link to comment
Share on other sites


Medhue Simoni wrote:


Drake1 Nightfire wrote:


The problem is that previous mesh heads and avatars will have to either be remade or a new version made. And i doubt any mesh maker will give them away as "updates."


Well, if the head, or body designers don't, meaning make a new version, then they will be left in the dust, as the new bento heads will be many times better just in efficiency alone. As it is, most people with current mesh heads won't even be seen by others because of the Avatar Complexity scores that these current mesh heads produce.

Pretty sure Solarian WILL be giving away its bento version as an update.

I agree with Medhue: those that fail to do so, will get left behind. You'll see their shop in newbie malls in a year's time, on that long walk between the landing point and the 'best in outfits / $300L on the board' contest for AFK people at the end...

The people that do update... will be the ones getting blogged about, bought, and used by the active SL community.

 

By contrast... in the mesh head arena, some designers have already said they will NOT update... and some mesh heads have started moving to discount bins (I saw a notice for one brand dropping its 'beginner / limited' version of its mesh head to 100L, as an example)...

And smart shoppers stopped buying things like mesh heads the moment LLs announced Bento because it was kind of obvious a shakeout was coming.

These days anyone with a copy of Daz3D and Blender seems to be uploading the latest Daz model... er... originally designed head... and putting it up for sale... so its no surprise many of those won't get updated. :P

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2818 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share


×
×
  • Create New...