Jump to content

Render weight weirdness


ChinRey
 Share

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

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

Recommended Posts

Look at this picture:

Plant shape weirdness_001.png

Three lovely bunches of irises. Just regular "plant stars", nothing unusual about them at all except for one detail.

The one to the left has two sheets angled at 90 degrees (8 tris) and render weight 404.

The one in the middle has three sheets angled at 60 degrees (12 tris) and render weight 404. So increasing the triangle and vertice count byt 50% doesn't affect the render weight at all.

The one to the right has four sheets angled at 45 degrees (16 tris) and render weight 389. In other words, doubling the number of triangles and vertices actually reduces the render weight!

Apaert from the number of faces, they are identical, same dimensions (except the three sheet one is shorter along the y axis since there is no sheet following that axis exactly), same texture, samle physics model and they are all full LOD.

The difference is so minute it doesn't really matter but even so, how can adding triangles and vertices reduce render weight?

 

(Sorry about the sandy background btw, I'm afraid my work platform got hit aby a hitn of global warming last week and hasn't recovered yet)

Link to comment
Share on other sites

There's a wiki. Not clear this is for static objects too, and may be out-of-date, although it was last edited this year. If it's anything like that, it will depend on (for this size) the triangle count of the lowest LOD and the texture dimensions. Not sure what you mean by "full LOD". Does that mean all LODs same? For so few triangles, this could be dominated by the unique texture weight - 128x128 gives 288, 256x256 gives 320, 512x512 gives 352 etc. Assuming the texture is the same on all faces, that would be the same for all of the models. Then if there were differences in the triangle counts of the lowest (and maybe low) LODs, there would be small differences. On the other hand, the smaller "radius" of the three-plane version should make the triangle cost lower. Hmm. I have never bothered with render cost because it doesn't really affect anything. Some experiments may be in order. What happens if you use a non-alpha texture? What happens if you change the LOD scheme? What are the texture dimensions and low LODs like?

Link to comment
Share on other sites


Drongle McMahon wrote:

There's
. Not clear this is for static objects too,

It's the only information we have though.

Using the formula there render weights for the four models should be 392, 396 and 400 respectively.


Drongle McMahon wrote:

and may be out-of-date, although it was last edited this year.

Both the page and the formula are clearly out of date.

The page is out of date because the information there is obviously incorrect. This is easy to demonstrate. Rez a cube, check render weight, it's 404. Scale the cube up to 64x64x64 m. According to the wiki info this should increase the render weight slightly but in fact it reduces it down to 389.

The formula is out of date among other things because it does not take into account new materials. Faces with alpha masking or normals maps do not add to the render weight although it's not hard to see they add to the actual render cost. (I didn't check specular maps but I assume it's the same there). It also seriously underestimates the effect of rigged mesh (and yes, the page says "rigged" not "fitted mesh ;) )

My favorite part of the text on that page is in the introduction:

"It does not affect land impact, but high render weight values may result in low visual performance on some hardware." No, mr. Linden Lab, render weight has a significant impact on visual performance and quality of experience for everybody in Second Life, regardless of their hardware! Whoever wrote that line should be a politician.


Drongle McMahon wrote:

Not sure what you mean by "full LOD". Does that mean all LODs same?

Yes.


Drongle McMahon wrote:

Assuming the texture is the same on all faces, that would be the same for all of the models.

That is correct.


Drongle McMahon wrote:

On the other hand, the smaller "radius" of the three-plane version should make the triangle cost lower.

Usually yes, but not in this case. The number of triangles of the different LOD models are weighed aganist each other but since all LOD models are identical, that shouldn't be a factor. The average of 12, 12, 12 and 12 is 12 regardless of what "weighing factor" you add to the equation.


Drongle McMahon wrote:

Hmm. I have never bothered with render cost because it doesn't really affect anything.

Actual rendering cost is one of the most important factors influencing how we perceive Second Life every time we log on to the grid. But there is a question how much value the rather inexact estimate the render weight offers has. Linden Lab clearly hasn't spent much time or effort on it. This is of course partly because it doesn't affect server performance so there's not much incitement for them to do so but also for the much better reason that actual render cost depends on so many unknown variables the render weight can never be more than a rough estimate anyway.

Link to comment
Share on other sites

Well, I guess that wiki is irrelevant. I tried some flower thingies like yours, 1,2,3,4 2-sidede planes, all 1x1x1 (the 3-plane one stretched to get that bouding box, the one plane one gets it by default). Untextured, they all had the same display weight, 269. With a 256x256 texture that rose to 325, whether it was alpha or not. Also, it made no difference at all whether I used the same mesh at alll LODs or let the auto-LOD do its stuff - it reduced them all to 2 triangles. I don't know if the code for this weight is in the viewer or server. All the other weights are from the server, but I am going to look for it in the viewer now.

Link to comment
Share on other sites

"Actual rendering cost is one of the most important factors..."

well, yes, but Im prefer tp rely on common sense about what will be costly rather than on the figure given to us. I think thge most interesting thing is the multiplication factors for alpha (4x) and flexi (5x)*, which emphasises how costly those are. I believe these were worked out after a mot of experimentation and measurements by a Linden who will remain anonymous. So at least in that respect they probably reflect something mear to the truth.

So flexi-alpha hair is 20x.

Link to comment
Share on other sites


Drongle McMahon wrote:

I tried some flower thingies like yours

Thingies??? You have to stop discussing with me, Drongle - I'm afraid I have a negative influence on your usually impeccable mastery of the English language.

 

 


Drongle McMahon wrote:

I don't know if the code for this weight is in the viewer or server.

Me and Hattie Panacek once did some informal avatar render weight tests. Very simple, We just switched on the Show Draw Weight function and tested different outfits. Some really interesting results and we both learned a lot from it. One thing we noticed was that we didn't always get the same readout so that value at least has to be caclulated client side.

 


Drongle McMahon wrote:

well, yes, but Im prefer tp rely on common sense about what will be costly rather than on the figure given to us.

Me too but inexact as it is, render weight is the only tangible measurement me have.


Drongle McMahon wrote:

I think the most interesting thing is the multiplication factors for alpha (4x) and flexi (5x)*, which emphasises how costly those are.


Not to mention textures! Render weight really illustrates how costly texture abuse really is and that alone justifies its existence.


Drongle McMahon wrote:

So flexi-alpha hair is 20x.

Whereas fitted mesh is only 1.2X

Right now I'm wearing a fitted mesh body with a render weight of less than 3500 and a flexihair with a render weight of more than 70 000. It's easy to see that my mesh body is far harder for my computer to render than my hair.

Link to comment
Share on other sites

I found at least most of it in the source code for the current release viewer. It is all calculated in the viewer. For mesh, it uses the same code that was used for the streaming cost calculation before that was moved to the server (I think it's still the same there though). It is based on triangle counts for each LOD that are not actual counts but are inferred from the byte size of the LOD data and an assumed bytes/triangle (16). This is so that it can take account of byte savings on compression (needed for download resource estimate, but not really accurate for rendering load). However, there are some adjustments for the overhead and for a minimum byte size. The effect of the minimum would be to make all LODs for meshes with less than a certain level of complexity have the same download weight, and therefore the same non-texture component of the rendering weight. This would be the case for our simple flower meshes. Effectively, the actual rendering cost is so low that it is replaced by a constant overhead. All of mine had download weight 0.06 in the uploader, which I think is what is expected for the minimum value.

As far as the textures are concerned, in the source code it looks as if it should do exectly what's stated in the wiki - that is 16*(h/128+w/128) per texture. I'm not sure, but I didn't notice anything that would include the extra textures for normal and specular maps, and adding them didn't have an effect inworld. I think this code hasn't been changed since before materials wer introduced. The effect of changing a 256x256 texture to a 512x512 did have the expected effect, +64. That fits with the previous numbers if we assume the blank texture is (treated as if it were) 32x32.

That then leaves 269 - 8 = 261 as the 'minimum' mesh non-text cost. That would fit roughly with your 404 if your texture was 1024x1024* 512x512, give or take a bit of rounding.

Where I come really unstuck is with the alpha texture. This only chages my flower from 325 to 340, while the code seems to be clear that the whole non-texture part of the weight should be multiplied by 4. I must be missing something there.

*corrected as pointed out by ChinRey.

Link to comment
Share on other sites


Drongle McMahon wrote:

It is based on triangle counts for each LOD that are not actual counts but are inferred from the byte size of the LOD data and an assumed bytes/triangle (16). This is so that it can take account of byte savings on compression (needed for download resource estimate, but not really accurate for rendering load).


ChinRey wrote:

Linden Lab clearly hasn't spent much time or effort on it.


I rest my case.


Drongle McMahon wrote:

However, there are some adjustments for the overhead and for a minimum byte size. The effect of the minimum would be to make all LODs for meshes with less than a certain level of complexity have the same download weight, and therefore the same non-texture component of the rendering weight.

So that's the 0.06 download weight you can't get below no matter what you try. That would explain why the 8 and 12 triange models have the same render weight, they're both at minimum. My 16 tri model has a download weight of 0.083 though. The same may happen to the resized prim I mentioned too although I didn't check the exact download weight for that. So it seems increasing the download weight slightly above the 0.06 minimum will reduce the calcualated render weight. That actually answers the question I started this this thread with. :) And since it's only a nominal not an actual difference and too small to have much effect even on the nominal level, it's hardly worth pursuing further.


Drongle McMahon wrote:

As far as the textures are concerned, in the source code it looks as if it should do exectly what's stated in the wiki - that is 16*(h/128+w/128) per texture.

That's what I found out too.


Drongle McMahon wrote:

I'm not sure, but I didn't notice anything that would include the extra textures for normal and specular maps, and adding them didn't have an effect inworld.

I didn't get any render weight changes when I added alpha masking or normal maps either. Didn't try specular maps.

That is rather worrying. I can understand why LL won't spend a lot of time fine tuning the render weight calculation but they really should have remembered something as obvious as this. And of course, now I'll always wonder if this was a genuine oversight or a deliberate attempt to obscure the actual cost to the users of their pet projects. They've also grossly undervalued the added render weight of fitted mesh and we already know from another thread they are willing to deliberately mislead to make normal maps seem more effective and useful than they really are...


Drongle McMahon wrote:

That then leaves 269 - 8 = 261 as the 'minimum' mesh non-text cost. That would fit roughly with your 404 if your texture was 1024x1024, give or take a bit of rounding.

It's 512 actually which should have given a render weight of 397 - close enough for jazz. A 1024x1024 texutre should increase RW to 525.


Drongle McMahon wrote:

Where I come really unstuck is with the alpha texture. This only chages my flower from 325 to 340, while the code seems to be clear that the whole weight should be multiplied by 4. I must be missing something there.

Seems the multipliers use the actual triangle count rather than the estimated one as their basis. Makes perfect sense. There's no need to make things simpler than they need to be.

I found this article on the web explaining how physics weight is calculated:

Second Life Physics Weight

Maybe they use some of the same method to determine the other weights too?

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3283 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...