Weight watcher's frustration

[Gaia Clary]

Tiberious Neruda asked yesterday why his Bowling pin would not go below 6 PE. So i thought, maybe i can benefit from my recent experiments with the new Prim Equivalence calculation system...

So here is my Bowling pin:

Physics Weight	0.1
Streaming Cost	0.8
Prim Equivalent	2

OK, thats is good so far. The PE=2 is because of the Server weight (1 + 1*0.5 = 1.5 -> rounded to  2.0). Now i want to have 10 of these pins standing together:

Physics Weight	1.0 (as expected)
Streaming Cost	7.7 (close to expected, probably due to rounding)
Prim Equivalent	20 (10 times 2.0)

Still as expected.

Now i do the "link us and save weight..." magic:

Physics Weight	1.0
Streaming Cost	7.7
Prim Equivalent	12 (this is not what i expect)

Well, this is not what i expected. Why ?

Because:

 

1. The PE is the maximum of (Streaming cost, Physics cost, Server Weight).
2. Since SC= 7.7 and PW=1, Server Weight is what makes the PE go up, so SW=12

But...

The pins do not contain scripts. And they are not made physical objects. Hence the SW should be 1 + 10* 0.5 and that is 6. Hence i expect to see a PE of 8 here (because of the streaming cost = 7.7 becomes the highest of the three numbers).

Am i wrong or is this a bug ?

[guY Ralior]

What seems utterly frustrating to me, although we haven't seen the final settlement of the cost which is PeW and the actual Linden cost, is the fact that that bowling pin example, and I am sure you would agree, would be an utterly easy 1 prim sculpt and possible could get double that number of pins and still be one prim. Under the current account system that is a difference of 60Ls at upload which is quite significant.

So a person who plans on only building sculpties as the system is changed to the new accounting system will see quite a significant impact on the building resources on the first day of the rollout and will have done nothing at all, other than make what a lot of people see as evil sculpties something which has been designed by LL as a way to get content inWorld.

With that in mind if they were the person building this bowling pin array out of sculpties one day it would cost 10Ls next day same sculpt would cost 70Ls or 120Ls, I just don't see how that can be justified even if it is going to make a seriously significant difference in lag. It means what people have been doing for years and sort of praised for it now are going to be punished for building that way. All of this doesn't even take into account when the person rezzes it on their land and resizes that cost goes up again not in upload charges that will have already been paid, but rather now it will affect the parcel prim limit and their cost associated with that if they want to still keep everything they have on their land and still have same prim overhead.

Ultimately "mesh" which was being praised as this new awesome, great, creatively expansive thing, seems is turning into a way for LL to make more money not only on the new availability of mesh but also and even more so on the system they have had in place for years. 

[edited] So yes I hope it is a bug and is off by quite a few points

[Gearsawe Stonecutter]

I don't think it is a bug. From what I have seen the more mesh parts you link together the. here are my results using a single face trianlge.

Prim in set	PE	Average PE
1	2	2.0
2	2	1.0
3	3	1.0
4	3	0.75
5	4	0.80
6	4	0.67
7	5	0.71
8	5	0.63
9	6	0.67
10	6	0.60
50	26	0.52
100	51	0.51
200	101	0.505

so we get a bonus for linking more meshes together if the PE is really less than 1.5. It would nice if something made sense with mesh. I have talked to a few people on Angin which have not tried mesh yet and heard some of there plans. Then had to respond you can't do that or you will want to keep it sculpt becasue of high cost or you will not want to link it to prims. or can;t switch out meshes with a script for animations or can't control the rigging via script yet.

[Gaia Clary]

But from the formula in the wiki, we can derive:

 

Total Server Weight (static objects) = num_prims/2 + 1.0

Total Server Weight (dynamic objects) = num_prims + 2

See also http://community.secondlife.com/t5/Mesh/Understanding-Mesh-Server-Weight/td-p/950355

So in my above example it looks like the prims are all counted as dynamic objects. When they where counted as static objects, the total Server Weight should be 6 for 10 objects and not 12 as i see...

BTW i just tested what happens when i actually add a script. And the weight does not change. So i getting more confident that something is wrong...

[Gearsawe Stonecutter]

What is the streaming cost of the pin. The cost system is stil in flux. I would imagen there will be changes even after release.

[Drongle McMahon]

Are people using the Show Render Info streaming cost wieght here? If so, I think that has gone seriously wrong since at least 234066 and is still wrong in 234193, See recent comments on CTS-536 for details. The server is still seeing the correct cost. So until the viewer code is fixed, we can really only get the streaming cost by looking at changes in parcel object count, and that only when it's the streaming cost that predominates. The PE is obtained from the server. So it will njot agree with any calculations based on the Show Render Info streaming cost while the latter is incorrect. It's the PE that you should believe for now.

Other errors I reported with PE in 234066 were related tp physics costs and are now fixed. There are still some problems with adding scripts. Baically, the server cost seems bot to get updated when you add a script to am already linked linkset, but does when you link things already containing the script.  There are also some elays in updating the display, but not the parcel count, after deleting the script(s) in a linkset.

[Madeliefste Oh]

---

guY Ralior wrote:

Ultimately "mesh" which was being praised as this new awesome, great, creatively expansive thing, seems is turning into a way for LL to make more money not only on the new availability of mesh but also and even more so on the system they have had in place for years.

---

LL can only make more money when mesh will be widely adapted by the users. For rezzable objects mesh isn´t going te be interesting with this high prim count, the market will be too small. Seen from a merchants perspective mesh is only interesting for attachments. Attachments are free for the user. Whether I wear a 1 prim ring or a 300 prims ring, for me as a user the price is the same: zero. For LL the price is not the same. With the 300 prims ring I'm a more expensieve user then with the 1 prim ring.

Mesh will become big for the attachment branche, but for rezzable objects mesh will be mainly ignored since cheaper prim low sculpties are available. So when these plans become reality, there will be a market for meshes where is nothing to gain for LL, except from 5% sales from the marketplace. 

But its seems that is how they want it, well then that's how they will get it.

 

[arton Rotaru]

---

Drongle McMahon wrote:

Are people using the Show Render Info streaming

cost

wieght here? If so, I think that has gone seriously wrong since at least 234066 and is still wrong in 234193, See recent comments on

CTS-536

for details. The server is still seeing the correct cost.

---

Though, taking Runitai's comment; "The lod ratio array index was off by one", I would assume there was something wrong in the algorithm. Regardless if it is even more wrong now or not. But that index is still off in the server code then. So I actually have really no idea what the PE is, will be, should be, can be, shouldn't be, would be etc...

[guY Ralior]

LOL

[Drongle McMahon]

At the risk of being banished, and without understanding what he means, I will dare to suggest that I think he may have been mistaken about the index, whatever it was. The reason I think that is that, for cases where the streaming cost dominates the PE, the PE is totally consistent with the maths described in the wiki; correct parabolic curves, inflection points at the correct radii, correct minimum and plateau levels. Until the latest changes, the Show Render Info streaming cost also agreed perfectly with the PE in those cases. So I am convinced there was nothing wrong except the repeated application of the object scale that was producing the wrong numbers in the upload floater, whch made them depend on r^4 instead of r^2.

That is not to say that the previous numbers were to my liking. That depends on things like the cost scaling factor. But they were consistent with the wiki algorithm (except that the incorrect use of LOD switch points r/1.0, r/0.24, r/0.06 instead of r/0.24, r/0.06, r/0.03 has been corrected in the code but not in the wiki text).

[arton Rotaru]

Like I said in the other thread, let's wait and see.... :matte-motes-sunglasses-1: