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

[Drongle McMahon]

At the outset, I invite corrections, criticisms and any other comments concerning the following.....

I have been studying the new triangle-budget-based algorithm that was introduced with viewer 224488. (This affects only the Show Render Info streaming cost for now. The PE in the edit dialog is still using the preceding iteration of the algorithm in the server. The resource cost shown in the upload dialog is still affected by the bug using r^4 instead of r^2.)

The idea behind this is to imagine that many copies of the object are evenly distributed and to calculate what proportion of the 250,000 target rendered triangle budget is used up, on average, for each object, given that they will have various LODS at different distances from the camera. The prim equivalence (still called streaming cost in the code) is then that proportion of the prim allocation for the corresponding area.

For now, at least, the triangle count is simply estimated from the byte sizes of each LOD mesh's download data, with corrections for header overhead etc., assuming an average consumption of 16 bytes per triangle. Here is the first problem. We know that faceted triangles use almost three times the amount of data as do smoothed face triangles. So they will cost about three times as much each by this estimate. That is correct as far as streaming cost, but the question is whether faceted triangles consume three times as much cpu and gpu resource for rendering. Runitai did explain that they were more expensive, but I don't know that it is as much as three times more. This matters in so far as rendering cost is now supposed to be the more important factor.

Secondly, the present code uses the area of the circle circumscribing a region as the area within which objects will be seen at all by a camera at its center. That is equivalent to using a draw distance setting of 128*sqrt(2) = 181 meters. The area of this circle is (close to) 102932 sqm. That is 1.57 times the area of a region, 65536 sqm. However, the prim allocation that is used to work out the PE is 15000, which is the number of prims allocated to 65536 sqm. It should be 1.57 times as much. Unfortunately, this would increase the PE streaming cost by 57%.

The second parameter for which an assumed value is embedded in the logic is renderVolumeLODFactor. The present code assumes that this is 1.0. However, as far as I understand it, the triangle budget is set in order to provide an acceptable performance for the users of low end machines. The default settings (taken from viewer 234551) for the "low" overall graphics setting are draw distance = 64m and renderVolumeLODFactor = 0.5. For "medium" it is 96m and 1.25, for "high" it is 128m and 1.25, and for "ultra" it is 256m and 2.0. So It would seem to be sensible to base the triangle budget on exposing the "low" user with default settings to the 250,000 triangle budget rather than using the 181m and 1.0 settings implied by the present code. To investigate what effect this would have on the calculated PE streaming cost, I generated graphs of streaming cost vs. radius for a typical object with 4-fold data size reductions at each LOD, using the various default setting combinations instead of those implicit in the current code. This allows comparison with either the cost from the present code as well as that corrected for the 1.57 fold area discrepancy described above.

In the first graph, values from the current implicit settings are the orange dotted line. The solid orange incorporates the 1.57 fold correction. Black uses the "ultra" settings, blue the "high", green the "medium" and red the "low". The level of the final plateau (only highest LOD ever seen) for each is shown in the appropriate color. Differences in the plateau, simply proportional to the area in which objects are rendered, is the most obvious effect. The curved parts are complicated because the inflection points as well as the vertical scaling are affected. It is very clear, however, that the implicit values of draw distance and renderVolumeLODFactor used in the calculation have very large effects on the resulting streaming cost.

If the triangle budget is motivated primarily by the aim of controlling the resource consumption for the users of lower end machines, then it may be reasonable to suggest that the calculations should represent the settings they are likely to be using, rather than the relatively high level settings implicitly used. This would result in streaming costs about five times lower than the current calculation (without correction)  yields.

An alternative representation of these graphs is in the second picture. This shows the log of the ratio of the streaming cost with the altered settings to those of the current calculation (the dashed line in the first picture), at each object radius in the same range. The color scheme is the same as before. The dashed lines represent the median for the uniformly distributed values of radius. The numbers indicate the actual ratios to the current calculation for these medians and for the plateaus.

 

[Atashi Yue]

Drongle,

Those current settings you're looking at, are those in Basic?  The reason I ask is I don't see any way to find out what Basic is set to at all.

Current viewer Second Life 2.7.6 (234621) Jul  1 2011 14:50:42 (Project Viewer - Mesh) switched to Advanced (which logs you into AGNI instead of ADITI btw) has graphics set to High on default with RenderVolumeLODFactor set to 1.125.

 

[Josh Susanto]

Boil it down for me.

Does it mean people are going to continue buying my sculpts, or not?

[arton Rotaru]

I would lie when I say I understood it all from the first read, but it sounds reasonable to me.

[Tapple Gao]

I don't see any simple relation between the length of the high plateau (the smallest radius that causes high LOD to always be shown) and the renderVolumeLOD factor. Based on your graph, it looks to be about:

RVLOD - radius

0.5 - 31

1.0 - 43

1.25 - 18

1.25 - 25

2.0 - 31

So the high radius depends on draw distance as well? What is the formula to calculate the inflection points from RenderVolumeLODFactor and draw distance? A source code pointer and/or formula would be great. Or are the inflection points in the graph not the same as the LOD switch distances?

[DanielRavenNest Noe]

---

Drongle McMahon wrote:

 

If the triangle budget is motivated primarily by the aim of controlling the resource consumption for the users of lower end machines, then it may be reasonable to suggest that the calculations should represent the settings they are likely to be using, rather than the relatively high level settings implicitly used. This would result in streaming costs about five times lower than the current calculation (without correction)  yields.

 

---

This is what has bothered me about the cost formula.  I have been testing the Crysis 2 / CryEngine 3 MOD SDK and set up a scene with terrain and plants..  The attached photo is on the "Ultra" graphics setting (the highest they have), on a very demanding graphics engine - all the plants are animated for example, to move in the wind.  It's a bit hard to read the statistics in the upper right corner but there are 500K triangles, and I am getting 30 frames per second, which is very acceptable. 

Basing the SL formula on 250K triangles for a much simpler rendering engine is much too restrictive. In effect you are preventing people with decent PCs from actually using them, for the sake of people with slow PCs.

http://lh5.googleusercontent.com/-hkqEOf35KMg/Tg-WkPDtOII/AAAAAAAACkc/nvqCsYfiZu4/s1600/DemoLevelSunset.JPG

 

[Atashi Yue]

Apples to Oranges though Daniel - your scene isn't streamed live is it?

[Drongle McMahon]

I will try to collect some answers together here.

========================

Atashi. The "settings" that the existing calculation implicitly uses are deduced from the code. It considers objects within a circle with radius 128*sqrt(2) to contribute triangles. That is the situation with this set as the draw distance. Then it uses the LOD switch distances that you get if you have renderLODFactor set to 1.0. To get the other settings, I used viewer 234551 and set the graphics to Low, medium, high or ultra and looked at the effect on the draw distance (in the preferences dialog) and the value of renderVolumeLODFactor (using Advanced->Show Debug Settings).

========================

Josh. I don't think there is much doubt that people will go on buying sculpties. They are still the most economic way of making a lot of things. There may be some competition from mesh in some areas, especially attachments. I don't know what sculpties you are selling, so I can't try to be more specific. Of course the balance depends on final costs they settle with. So far I would say everything seems to be moving more and more in favour of sculpties. That is just one rather disappointed opinion though.

========================

Tapple. The source for the calculation is in .../indra/newview/llmeshrepository.cpp, LLMeshRepository::getStreamingCost. You need the latest source for the triangle budget based version. You can get it from the page where you download the latest viewers. The code in the wiki is quite outdated, but there is some useful explanation there. The inflection points are not the same as the LOD switch distances. The latter depend on the radius*, r, and are r/0.24, r/0.06 and r/0.03,(about 4, 16 and 32 times r) multiplied by renderVolumeLODFactor. Th inflection points in the curves are the result of statements like llclamp(area_high,min_area,max_area); where where area_high is the area in which the highe LOD is showm and depends on a quadratic function of r. The max_area limit causes a discontinuity in the function. (The min_area limts have only very small effects).

Both renderVolumeLODFactor and max_area affect the curves by scaling the horizontal axis. max_area also wffects the vertical axis. The code uses a fixed value for max_area, which is 2*pi*128^2, the area of a circle with radius 128*sqrt(2), which circumscribes a region. Since this is used as the area in which objects will be rendered, it is effectively assuming a draw distance of 128*sqrt(2) (181), which is, of course, much bigger than that of someone on low or even medium settings (64, 96).

The code I use to draw the graphs is in R, which is perhaps rather esoteric. I can show it to anyone who is interested.

*In fact, I think the code is actually using the diameter, which results in the Show Render Info streaming costs having inflection points at half the radiuses shown in these curbes. The experimental switch distances are using r though, and as far as I know, the PE code in the server is using r too. That's quite tedious to test at the moment. I guess I should do it.

Ok. I did it anyway, and the server (233853) generated PE inflection points are actually smaller than the Show Render Info ones. Can't be very accurate because PE is rounded, but it looks like half where expected for the pre-traingle budget version (which used max_area of 65536 instead of the present 102932). So either that is making the same sort of diameter.radius error, or I am wrong (that quite finite possibility should always be borne in mind).

=====================

Daniel. I don't think we can expect them to styop insisting on looking after the low end (and eventuallt tablet) users. That is clearly their chosen strategy. The point I am trying to make is that they can do that pefectly well with a substantially less punitive costing if they base that on realistic low-end user settings. 

[Drongle McMahon]

I should add a couple of things that occurred to me after completing the post.

First, the figures I have used, as well as my interpretation of the underlying intent, have essentially assumed a continuous lansmass such as the mesh regions. Since most land in Agni is isolated islans, this is not entirely appropriate. When the draw distance circle overlaps tthe edges of an isolated region, the efffective area for objects that need to be rendered is less than the areaof the circle, as is the proportion of the regions prim allocation that it represents. This becomes a larger effect the larger the draw distance is. It quite complicated to calculate the averages for all possible camera positions, and I don't want to do it. However, the overall effect should be rather similar to reducing the draw distance; that is a reduction in cost. That s consistent with the fact that on avearge fewer triangles would have to be rendered than if there were surrounding regions with visible objects. The triangles per region can be higher before the same number have to be rendered per drawable circle. So this effect actually argues for less stringency.

Second, I have tacitly assumed that the developers strategy would be satisfied with the users of low end machines receiving satisfactory performance with the low or medium settings. They can quite easily counterv the argument by insisting that low end machines must perform with higher settings. I think this would be misguided, but it would be a logically consistent view.

 

 

 

[DanielRavenNest Noe]

---

Atashi Yue wrote:

Apples to Oranges though Daniel - your scene isn't streamed live is it?

---

It was built on my PC, but it could be set up to be streamed from a server.  The functions exist in that engine to deliver files incrementally.  The data for that scene amounts to 17 MB.  12 MB for the terrain map, which is 2x2 km (64 SL regions), and 5 plant models and textures for the other 5 MB.  There are only 5 kinds of plants, but they cover the entire map using "instancing", so there are roughly half a million copies used, mostly grass tufts.  Each copy only needs to record the location.  It comes to 265 kb per SL map region of area, so it's actually a pretty efficient way to landscape.  Of course, if you have more different kinds of objects that will be more data.

What I was talking about was PC rendering though, which does not care when the files arrived.  In Second Life the objects and textures are delivered after you teleport to a location.  Most game engines deliver them ahead of time on a disk or download.  Either way, when it comes time to render, the geometry and texture files go into the graphics card, and what matters is how many triangles and how complex the shader is.

[DanielRavenNest Noe]

---

Drongle McMahon wrote:

Second, I have tacitly assumed that the developers strategy would be satisfied with the users of low end machines receiving satisfactory performance with the low or medium settings. They can quite easily counterv the argument by insisting that low end machines must perform with higher settings. I think this would be misguided, but it would be a logically consistent view.

 

---

I tried rezzing multiple objects until I had 1.2 million triangles in the scene, with the default low graphics setting I am getting 160 fps.  That is for an Nvidia GTX-260.  So scaling that performance down to whatever you consider a "low" graphics card to target for should give you an acceptable frame rate and triangle count combination.  Unfortunately I don't have a low end card any more to test with.

[Drongle McMahon]

I just visited a few places on Agni looking at triangle counts with draw distance/renderVolumeLODFactor settings of 184/1.0 and 64/0.5. Generally, most randomly chosen places were less than or just above 250 Ktri at the even at the 184/1.0 setting. More developed and commercial places tended to be much higher. A certain well known sculpty-rich furniture place had 2500 Kti at 184/1.0 and 1600 Ktri at 64/0.5. The center of Linden memorial park was 260 and 120 KTri at those settings. So (a) the "low" settings tend to give about 1/2 the triangle count of the "calculation" settings and (b) the target maximum triangle count of 250 KTri for calculation effectivel with 181/1.0 settings seems to be typical/average rather than being a miximum. It is exceeded by up to 10-fold by some locations, and by at least 2-fold by some locations that are listed as destinations.  (I will admit that the sculpty-rich 2500 KTri place was laggy even with my GT440 card (mid range modern?).

[Vivienne Schell]

"GT440 card (mid range modern)"

For some reason the recommended minimum cards are:

 

• NVIDIA GeForce 6600 or better
• OR ATI Radeon 9500 or better
• OR Intel 945 chipset

This is because the overwhelming majority of LL customers are not gamer animals. Nor 3D modellers. So yeah, the 4xx nVidia is last year´s model, but in SL it´s a top racer. From my pretty rich in-world experience i can tell you that the 8800/9800 or comparable ATI cards and the minor laptop graphics still are the average standard. Would be interesting to get some access logs from Linden Lab there.

Probably the state of the world economy since 2009 makes most people without an outspoken 3D gamer and modeller cause keep their money in their purse if it comes to eye candy upgrades.



[Atashi Yue]

 There are only 5 kinds of plants, but they cover the entire map using "instancing", so there are roughly half a million copies used, mostly grass tufts.

 

Unfortunately, SL doesn't render in that manner, as far as I have been told. We gain nothing by using multiples of the same mesh.

[hibit Spad]

Hey Drongle how about once mesh is release ading an updated version of this to the wiki?

 

 

 

[Drongle McMahon]

hibit Spad wrote:

Hey Drongle how about once mesh is release ading an updated version of this to the wiki?

Well, I will make some graphs of the final settings, if nobody else does, and some explanation to go with it. I think they are needed because the effects of size are not exactly intuituve. These particular ones though are really to compare different possible settings of the constants used in the calculation. As we must assume they will have settled on a version by then, that probably woudn't help much. More important is the effect of different LOD ratios etc. I can't really make those until the settings are finalised.

[Vivienne Schell]

Drongle, you are aware of the graphic card impact on LOD? Such a survey only makes sense if you would add a table on how LOD is displayed by certain graphic card classes. After all you want to make your stuff for people who do *not* run the latest and greatest hardware and super-routers, which is the vast majority of SL users.

[Drongle McMahon]

"Such a survey only makes sense if you would add a table on how LOD is displayed by certain graphic card classes."

I think you will finf that the graphics card has no direct effect on what is displayed at different LOD. If you accept the default settings for your graphics card, then what is displayed depends on the setting of renderVolumeLODFactor which the viewer decides for your card (if it knows about it). The effects of using those different settings as the basis for the cost calculations is precisely what the OP is about. If anyone wants me to do graphs for calculations based on other combinations of settings, I will be happy to oblige (as long as it's not too many).

[Vivienne Schell]

True, but a set to lower or higher than default LOD certainly effects overall performance, because they depend on shaders. Same for bandwidth settings and access speed.

[arton Rotaru]

To be honest, it doesn't matter much if you have 6 FPS or 5. :matte-motes-nerdy: Such a performance is very poor anyway. :matte-motes-silly:

 

[arton Rotaru]

---

Drongle McMahon wrote:

I just visited a few places on Agni looking at triangle counts with draw distance/renderVolumeLODFactor settings of 184/1.0 and 64/0.5. Generally, most randomly chosen places were less than or just above 250 Ktri at the even at the 184/1.0 setting. More developed and commercial places tended to be much higher. A certain well known sculpty-rich furniture place had 2500 Kti at 184/1.0 and 1600 Ktri at 64/0.5. The center of Linden memorial park was 260 and 120 KTri at those settings. So (a) the "low" settings tend to give about 1/2 the triangle count of the "calculation" settings and (b) the target maximum triangle count of 250 KTri for calculation effectivel with 181/1.0 settings seems to be typical/average rather than being a miximum. It is exceeded by up to 10-fold by some locations, and by at least 2-fold by some locations that are listed as destinations.  (I will admit that the sculpty-rich 2500 KTri place was laggy even with my GT440 card (mid range modern?).

---

I visited a couple of Linden Home regions with rendervolumeLODFactor 1.0 and 96m Draw Distance. 400k to 800kTris from what I saw, from the center of the sim. Did you notice that having the Show Render Info Display visible, the Viewer FPS drop significantly? Mine dropped  from 40 to ~10 FPS on filled regions :matte-motes-sour:

[Drongle McMahon]

I just went to a Linden homes place, Aetos, one of hobbity mushroomy ones, and checked a range of settings. Unfortunately, these is a discrepancy between the triangle counts in Show Render Info and that in the statistcs bar. The latter were usually higher. Oh well, that's par far rthe course, I suppose. I will put the the statistics bar counts in brackets. For the settings inplicitly use to apply the triangle count of 250,000, that is renderVolumeLODFactor=1, draw dist=184, the triangle count was 1247k (915). So that region is 5 (3.6) times as many triangles as will be allowed for mesh. The "low" graphics setting I see, rVLF=0.5, dd=64, was 435k (426)  triangles. Even that is 1.7 times the 250k budget.

[Vivienne Schell]

OMG!

These Lindens must be terrible dilettants who do not know what they are doing! Fire them and make yousrelf the lord of the mesh grid! I am sure you´ll make Second Life run with 600 fps (at least) on an iPad on a 28k modem connection, only by exchanging all the content, all the people, all the dilettantish trash for just you and you alone and your meshes.

:matte-motes-sunglasses-1:

[Drongle McMahon]

Vivienne.  I am aware of you apparent need to heap gratuitous and baseless insults upon anyone who wishes even to discuss the possibility of mesh making a positive contribution to SL, and take the offence intended. However, in this case, you are so wide of the mark that you damage your own position.

The point is that the imposition of mesh-like limits on existing content would entail widespread destruction of existing content, even that created by the Moles* themeselves fot the Linden homes, which we must assume to have been found acceptable by the powers that be. This simply demonstrates that the performance related limitations imposed on mesh are much more restictive than those that apply to what has been considered acceptable for other forms of content.

That observation is neutral fact. You are free to draw whatever conclusions you like. I imagine (though of course I don't know) that you would conclude that this is a good thing because it will stop a hoard of crazed mesh fanatics covering the world with their evil and artless artefacts. I would conclude that it deprives responsible builders from the opportunity of improving performance by limited, gradual and judicious replacement of complex prim and sculpty builds with simpler meshes.

* by the way, Moles are not Lindens. They are builders selected by the Lindens, presumably on the basis of their skill, artistry and knowledge of performance issues.

[Vivienne Daguerre]

Yeah, yeah, we get you Vivienne. You rule and we drool. We and Linden Lab staff are all morons who should bow down and worship your brilliance.

Are you done now? Why waste your bright light on us? We get your message. I think there are people elsewhere who have not seen the light.