Food for thought? (warning - long, with maths).

[Vivienne Schell]

Naw, Drongle, compared to the most meshies you are certainly one of the most modest and serious ones. No offense. It´s just: You cannot boil down Second Life to a visual format and verticles and polygons and cost calculations and fps.

It attracted and still attracts tenthousands of folks each day, each second. The absence of mesh did *not* prevent Second Life from becoming the (still) leading Virtual Reality on the planet. There are much, much more significant reasons than mesh or not mesh for the slow down since 2009. And there is more than one *valid* reason for limiting mesh imports to a *relatively* reasonable amount. I must admit that I always questioned - and still question - the sense of mesh imports while there are tons of much more important LL construction sites being left to themselves, abandoned or simply ignored.

And what I hate the most are ignorants who actually think that *their* tool and format of choice is the only one Second Life needs and wants.

[Vivienne Schell]

Vivienne, you should add a link to that "Black Rose for all Your Play and Role Play Needs ", so that people will know where to buy the latest medieval mesh fashion in the bright upcoming future.

[arton Rotaru]

---

Vivienne Schell wrote:

And what I hate the most are ignorants who actually think that *their* tool and format of choice is the only one Second Life needs and wants.

---

 

Oh, I'm sorry about that. Must be hard to hate yourself. :matte-motes-stress:

[Vivienne Schell]

Some of us outstanding artists even cut off their prim ear! Imagine!

[arton Rotaru]

---

Vivienne Schell wrote:

Some of us outstanding artists even cut off their prim ear! Imagine!

---

Your world, your imagination! And mine and everybody else's as well. :matte-motes-nerdy:

[Runitai Linden]

Ok, getting this very helpful, insightful thread back on the rails --

Two quick things and one long thing:

1) We were using diameter instead of radius, fixing that now, and the error margin seems to be getting smaller because of it -- thank you.

2) The new total area of 102k is the area of the circle that circumscribes a single region -- I found that using the area of the region (65536) tended to give the lowest LoD less weight when determining the average and resulted in a higher than accurate streaming cost.

 

The long thing: realistic budgets

I'm absolutely thrilled that the discussion is turning towards triangle budget and framerate analysis instead of comparison with individual prims, but there seems to be some misunderstanding of what "scene statistics" reports.  The "Render Info" display describes the currently rendered frame and includes information about everything in your current view.  The "Scene Statistics" console describes everything in the region you're currently in that the viewer is aware of, so it could be missing small object that are far away, and it definitely excludes content from neighboring regions.

What this means is the triangle budget of 250K is for a single region at medium mesh detail settings.  If you have a machine that can handle more than that, you can spend the extra power bumping up your detail settings, pushing out your draw distance, and enabling effects that require multiple render passes (like shadows and water reflections).  

Someone asked for a report on graphics hardware.  I'll see what I can dig up.

 

 

 

 

[arton Rotaru]

I visited some Linden Homes regions again and used the scene statistics display. Graphics setting Mid (heck, this setting gives me plenty of FPS :matte-motes-nerdy:) Teleporting in the middle of the region, without walking around gave me 330k to 1.1 million tris. I guess the first number in the display is the triangles the viewer is actually rendering, and the second (after the "/") is the total number of triangles in the region? If I start to walk around I collect more and more triangles.

IMHO, raising the triangle budget from 250k to 300k would not hurt to much. Respecting that a possible shifting to more mesh content on the grid will require at least a year, or 2 (if ever?), even cheap Laptops will have decent graphics power at this time.

 

[Drongle McMahon]

I hope Runitai will give us a bit more explanation of those numbers. I flew arouind Mesh Sandbox 6, where there are some piles of my xculpty pipe bend left around, with draw distance at 64, an d watchd the numbers. When I could see a pile of 100 pipes, both numbers were about 200k, as expected. When I retreated to where I couldn't see them, they went down to about zero. This happened a bit further away than the draw distance. At intermediate distances, or manipulating renderVolumeLODFactor, the first number dropped as expected with the sculpty LOD changes, but the second stayed at the number of triangles in the high LOD. Turning round to make tings go in and out of view made no difference. So I think it is reporting the LOD adjusted triangles in visual range (plus a bit?) , followed by the triangles without LOD adjustment. Which we are supposed to consider, I am not sure, but as the cost calculation does take LOD into account, I think it must be the first.

[Drongle McMahon]

I have been struggling to grasp the concept of a region-associated triangle limit that has anything to do with LOD. The LOD effect on triangles rendered is a combined function of the object's LOD meshes and the observing avatar's graphics settings, nothing to do with the region. So I see no alternative other than that the prim equivalent of an object should be that fraction of a regions' prim allocation that is represented on average by each of enough randomly distributed copies of the object within the region to cause a test avatar at the center to see the number of triangles set as the triangle limit. If the test avatar is using medium graphics settings, the number of triangles the viewer has to render per object is given by the existing streaming cost function with the radius multiplied by 1.125 (renderVolumeLODFactor) and the max_area set to pi*96^2 (draw distance =m 96). It is then easy to calculate the number of objects in the draw area that will make the triangle limit, and thus the number in the whole region that should be regarded as filling the prim allocation.

Instead, the triangle count is calculated effectively using a renderVolumeLODFactor of 1.0 and a draw distance of 181. Then slightly different means is used to convert that into a prim equivalence. So it occurred to me to ask how many triangles are seen by our medium graphics test avatar when the region is full, according to the currently calculated prim equivalence, with randomly distributed copies of an object. To cut a long story short, it depends on both the size and the LOD mesh ratio(s) of the object. The graph below shows the result. It plots triangle count vertically as a function of object size on the horizontal axis. The colors are orange for an object with five-fold LOD steps, blue for four-fold and red for two-fold. I was somewhat surprised to find that there are size ranges, 1.5 - 7 m and 20-25 m, where the triangle costs for the models with good LOD ratios (orange and blue) are quite similar to, and sometimes even higher than, the current triangle limit of 250,000 (dashed line). In other size ranges, the count is generally between 150 and 200,000. Less, but not dramatically so. On the other hand, a model with poor LOD ratios (red) is clearly being costed at substantially more by the existing calculations, as it is using generally little more than half the number of triangles expected when the region is filled.

So it seems the existing cost calculation, in spite of its not using the default medium graphics settings, is slightly but not hugely more punitive than is required to achieve the 250,000 triangle limitation for meshes with larger LOD ratios, although it does penalize models with smaller LOD ratios more than in simple proportion to the rendered triangle count. This is probably consistent with the aims of the developers in relative terms. However, it has no bearing on whether 250000 is indeed an appropriate limit. 

 

[arton Rotaru]

Ok, after reading it 3 times, I think I understand the graph now. It matters on the number of objects we can rezz on a region at a given size, which results in those differing ktris numbers.  :matte-motes-nerdy: Interesting!

What I don't understand is the181m draw distance in the streaming cost calculation. Why is it 181?

[Tapple Gao]

181 = 128 * sqrt(2) = distance from center of sim to corner of sim

[arton Rotaru]

Ahh yes, true. So this makes sense as well. thx :matte-motes-nerdy:

[Drongle McMahon]

In the code, there is a constant called max_area which is the upper limit on the areas of the circles where a particular LOD is seen. Essentially, triangles from objects outside that don't count. So it is analagous to the draw distance, outside of which the objects and their triangles don't appear. The value of this constant is currently the area of a circle that passes through the corners of a region, which has a radius 128*sqrt(2) = 181. So that is like assuming a draw distance of 181. If you use the draw distance to define max_area as the area of the circle within which objects get rendered, then to get the costs we have now, you have to use a draw distance of 181 for that calculation.

[arton Rotaru]

So, looking at your graph, it seems large objects are way to high in PE, because you only get ~120k tris on a region at it's prim limit?

[Drongle McMahon]

Using the larger max_area does prolong the range of size over which the PE increases. You might say that is letting it get too high. On the other gand, it is very unlikely that you would ever want to nfill a region with nothing but large meshes, and you might have other reasons for controlling them more stringently. The trouble is that the overall effect of the calcultions really depends on the distribution of object sizes in a region. I think those ranges where the triangle loads are around 250,000 are likly to be common, especially the 1.5-7m range. So the overall effect of the current PE is probably not as different from the one based on the medium settings as I had expected - I thought it would be something like 2.5 x all through the range.

[arton Rotaru]

Sorry for asking all this questions, but I want to make sure I read your graph correctly. Let's say, I have a large mesh of size 50m with x amoutn of tris. I fill the region with it to it's prim limit. The number of meshes is restricted by it's PE.

Now I do the "Test Avatar" thing and get ~120kTris. Way less than the 250k budget that should make sure even lower end PCs have a decent framerate.  I would assume, that I can put as many of this meshes on the region untill I have ~250kTris for the "Test Avatar". Sure nobody will fill a region with only such large builds, though the accounting for this particular mesh will be still to high, when I only place one of those on a region.

Or what is it I'm missing here?

[Drongle McMahon]

Yes. With that object evenly distributed, I think you will be limited by the region PE capacity when you get to about 120KTri. When the main server gets the fix for the diameter-instead-of-radius bug, I will try to get sdome real data to test this. Need an empty region for that.