Prim vs mesh performance

[ChinRey]

30 minutes ago, Profaitchikenz Haiku said:

When I made mesh wheels and axles to replace the 8 sculpts with three meshed items in one of FollowMeI'mThePiedPiper's engines, the total LI of the engine increased by 18 because of the need to make mesh models that would not degenerate into triangles at 8 + metres, however, the time taken by the script to move the engine around and also rotate the wheels and move the coupling rods more than halved. It's a subjective assessment, but the result didn't seem to adversely impact any other items in the region, so I assumed there was no extra loading put on the server as a result of having three mesh parts rather than 8 sculpted parts to deal with.

That's another factor that complicates things a lot. Once we start moving stuff around, the number of parts become more important than for static objects since each and every part will have to be constantly updated.

[Profaitchikenz Haiku]

Packets in / Packets out

 

I've spent a short while inworld watching both the stats floater and what's happening around me.

A very quiet mainland region, only one other avatar besides myself who was some way off and apparently not moving, I was sitting during the first tests.

Packets in/out figures were 25/40 approx when nothing else was happening.

When the train or funiculars started to move, the counts both shot up, in some cases to 80/160, but then dropped away again. However, this was not always the case, several times the train would come and go with no change.

When I stood up and moved around, both figures increased, and then dropped back as I came to a halt.

The in/out count would seem to be something to do with moving objects in the region.

So in the case Chin posted, there might have been somebody way up out of sight testing their new Himars missile system?

Edited September 20, 2022 by Profaitchikenz Haiku

[Profaitchikenz Haiku]

11 minutes ago, ChinRey said:

Once we start moving stuff around, the number of parts become more important than for static objects since each and every part will have to be constantly updated.

So, it might come down to this: are prims/sculpts easier for the physics part of the server than mesh?

Personally, I'm coming to the view that this whole LI issue is a case of a man-made problem. For some reason LL implement a 15,000 LI limit to a region. OpenSim does not. In SL, then, the need to reduce LI counts is more pressing than in Opensims, but the fact that some Opensim regions can offer up to 45,000 prims suggests that there is no hardware/software limitation that caused LL to set this limit. if it had been a power of two for the maximum Prims that would have hinted at software. The comparable case I recall was on Vax VMS where there was a maximum limit to the number of files a directory could contain (10,000 or 12,000 I think?) but there was no obvious reason why this figure was chosen.

It may well be that this was a figure established pragmatically that has to do with server loading, but I wonder whether it is now well out of date and the upper limit could be increased? That would then reduce the number of people trying to mesh up their prims to fit them all into the limit.

Edited September 20, 2022 by Profaitchikenz Haiku

[Beq Janus]

I think everyone overthinks the entire LI thing. LI is a composite number that was an estimate of the impact on systems 15 years or so back. It is in tended as a constraint, a brake on otherwise uncontrolled resource usage. It is not directly, scientifically linked to performance and having spent quite some time going back and forth over alternative calculations I am far from convinced that such a measure even exists.

When LI was implemented:

• We had slower networks
• Assets were sourced from the region
• textures were sourced from the region
• CPUs were slower
• GPUs were slower

LI thus has no real accounting for client side performance, any linkage is more incidental and than intentional. LI (as we know) is the largest of the 3 defining factors, the streaming cost, the physics cost, the server cost. Nothing in there says "rendering cost". I would go so far as to say that in reality LI was only ever a defence mechanism for the servers.

streaming cost = how much effort is it going to take the server to send this to clients
physics cost = how much effort is it going to take the server to calculate the physics collisions
server cost = how much effort is it going to take the server to run the scripts and manage the objects outside of the previous 2 cases

Even the LOD mechanism plays to this. The LOD algorithm factors in both scale and proximity, why? Because on average, far away things that are small are far less likely to need to be sent (by the server) to users, thus saving effort. 

Every single part of this is targeted at managing the server load based on a historical server setup.

These days the we are typically in a different place

• Faster networks (includes higher bandwidth, less packet loss, meaning fewer retransmissions)
• Assets are almost entirely served from the content delivery networks (in SL, not necessarily in OpenSim)
• CPUs (on servers) are faster
• GPUs don't actually figure in this.

The limits on a "sim" were undoubtedly calculated based on a point in time average/typical capability of the machines installed in the LL data centres, taking into account all their limitations at that point in time.

So the conclusion from this is that LI is not a relevant measure of performance as perceived by you, nor was it ever intended to be. Moreover, the correlation to region performance is significantly watered down for Second Life and to a lesser extent for Open Sim too. LI is therefore just a tax on rezzing things that gives them a value/cost that only remains relevant because of how land is rented and the correlation of space to "land impact"

[Theresa Tennyson]

On 9/16/2022 at 8:24 AM, ChinRey said:

 

 

Again, the mesh performed slightly worse than the prim original. The difference was all but insignificant and still within the margin of error but there certainly was no improvement. I already knew that SL's land impact algorithm gives meshes an unfair advantage over prims but 256 prims performing at least as well as a 6 LI mesh???

Interestingly I once calculated that with improved asset handling it would be possible to get 20-25 prims to perform as well as 1 LI worth of mesh. These test results indicate that this is already the case and my calculation was well and truly on the conservative side.

Why do you keep comparing the land impact of a mesh to the number of prims in a prim build? They're different things. Your 256-cube build would have a land impact of no more than 128 with modern accounting, and that would be overwhelmingly the server load. It would absorb download and physics loads from other linked objects like a sponge too.

Meanwhile the "6 LI" mesh might have a much higher land impact at a larger size.

[ChinRey]

I only mentioned LI as a sidenote since this was supposed to be about actual load but you have some very interesting points:

1 hour ago, Theresa Tennyson said:

Why do you keep comparing the land impact of a mesh to the number of prims in a prim build? They're different things.

Yes, I know I was a bit imprecise there. But 128 vs 6, that's still quite some difference.

 

1 hour ago, Theresa Tennyson said:

...

and that would be overwhelmingly the server load.

That's what I expected too but the test results tells a different story, the server is actually busier when it's handling the single mesh than when it handles the 255 prims. But as I've already said several times, these were very limited tests and the second one was under less than ideal conditions. Further testing is needed before we can draw a firm conclusion.

However, the tests are still strong indicators that the LI system gives server weight a lot more significance compared to download weight than it should. This is only to be expected anyway. The LI system is 11 years old and server power has improved a lot more than average bandwidth since then.

 

1 hour ago, Theresa Tennyson said:

Meanwhile the "6 LI" mesh might have a much higher land impact at a larger size.

The LI would also have increased if I had made proper LOD models for the mesh. I didn't since I was only going to test at full LOD. Not as much as you may think though. The object was already quite big - 12x3x10 m. The mesh' LI maxes out at 121 at 50x50x50 m size. That's a little bit higher than the 102 I expected but well within the margin of error and, perhaps more importantly, fairly close to the prims'.

Of course, most objects in SL are considerably smaller than 12x3x10 m and if I had reduced the size of the test object and if I had reduced the size, the LI system would have favoured mesh over prims even more than it did.

[Profaitchikenz Haiku]

1 hour ago, ChinRey said:

That's what I expected too but the test results tells a different story, the server is actually busier when it's handling the single mesh than when it handles the 255 prims. But as I've already said several times, these were very limited tests and the second one was under less than ideal conditions. Further testing is needed before we can draw a firm conclusion.

 

I'm not sure how we could even test server load:

There is no basic server load measurement akin to the Windows CPU/RAM usage.

The Ctrl-Shift-1 stats available to us aren't precisely defined to the point we can understand fully what is going on. Many of the timing figures such are averages over a 30-minute or so period.

Some of the figures are also more affected by network behaviour than by server activity.

Things like packets in/out are rapid but are responding to transients like position change/ avatar arrival/departure.

The physics memory seems to be a catastrophe/cusp figure, it's happy at 80-90 Mb until something goes wrong and then it shoots up to 100M and nothing works (failed to create object that has caused problems in this region...)

Things like streaming cost that we see when we upload a mesh are not available to us in real-time and so we cannot do a prim -> mesh comparison.

We have an objects used / objects remaining count but that is just a housekeeping function and nothing to do with any actual pain the server might be feeling.

Comparisons between SL and Opensim servers are also tricky because of significant differences, for instance SL implements a time-slicing function for scripts., Opensim doesn't; OpenSim doesn't give top-collider measurements and shows script times in a different form.

There are a few possible things to try, for example, timing the rezz-time for a prim build and an equivalent mesh build, moving both objects around using KFM/Puppeteering/Move to target and seeing if one is faster.

[arton Rotaru]

Lets face it, even if prims would be 10 times as performant as mesh, nobody will go back to prim building regardless. That train has left the station.

 

[RubyPassion]

This topic is of interest to me from a display HUD point of view. For me it is much more convenient to script a prim HUD. Does it make a different if I have a HUD of 78 prims or is it better to create a mesh HUD with different faces? Did anyone research that?

[ChinRey]

1 hour ago, RubyPassion said:

This topic is of interest to me from a display HUD point of view. For me it is much more convenient to script a prim HUD. Does it make a different if I have a HUD of 78 prims or is it better to create a mesh HUD with different faces? Did anyone research that?

I haven't researched it but I can't imagine it would make much difference. If you have 78 faces, presumably with 78 different textures, the load caused by the geometry is a drop in the ocean compared to what the textures cause. So choose whatever suits you.