Prim vs mesh performance

[ChinRey]

A friend of mine has this lovely old prim house. It's rather heavy though - 1804 prims - so he asked me for help converting it into mesh. Yesterday I had finished replacing 275 of the prims with 25 highly optimized meshes, including 21 copies of the same six prim (originally) object and I thought it was time to check how much performance improvement I had achieved so far.

There was none whatsoever. In fact both server and viewer performed marginally worse when dealing with the partly meshed house. The difference wasn't big enough to matter and well within the margin of error I should expect but it was consistent through several tests and the meshes certainly didn't improve performance:

The graph on the Kitely web site showed a similar story but it's not really detailed enough to be useful for this; the server load it showed stayed at 1% throughout all the tests.

I decided to do another test so I went over to Second Life Beta, made a linkset of 256 prim cubes and converted it into a 6 LI mesh. Here are the results:

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.

I really need some advice on this. Right now it looks as if converting prims to mesh is just a waste of time unless of course you're really struggling with the prim limit or want to add details that just can't be done with prims. But we need more info before we can draw a conclusion. What do you think? And has anybody else done similar tests?

Edited September 16, 2022 by ChinRey
Just improving the formatting and correcting typos

[Candide LeMay]

I don't understand what performance you're trying to measure. Why are you showing us server stats? Unless there's a bunch of avatars jumping around the builds and engaging the physics engine, why would the server stats be different between a prim and a mesh build?

[arton Rotaru]

Yeah, I also would assume that the server hasn't a problem to handle 256 prims, or a handful of meshes. It boils down on the client side. Draw calls, state changes, batching etc..

2 hours ago, ChinRey said:

1% throughout

 

[ChinRey]

5 minutes ago, Candide LeMay said:

I don't understand what performance you're trying to measure. Why are you showing us server stats? Unless there's a bunch of avatars jumping around the builds and engaging the physics engine, why would the server stats be different between a prim and a mesh build?

Good point but the sim server still does quite a bit of work on each object even if the physics engine isn't engaged. I don't know why but it does and that's what the server weight part of the land impact calculation is supposed to represent.

Then there's the frame rate. The second test from SL Beta is the clearest on here. The prim build to the left has 49,152 tris and 18,432 vertices. The mesh build to the right looks exactly the same but only has 3,072 tris and 6,144 vertices. And still the prim version renders considerably faster than the mesh. Of course, there's no practical difference betwwen 530 and 500 fps but this is only one fairly simple object rezzed on a platform high up in the sky, well away from everything else.

[ChinRey]

3 minutes ago, arton Rotaru said:

Yeah, I also would assume that the server hasn't a problem to handle 256 prims, or a handful of meshes.

There's always a question to what degree the minute differences in a smal, scale test like this relate to a real scenario. That is the main reason why I post here. It would be great to hear if others have some experience with this.

When it comes to the server, there's also a question how relevant data from opensim and even from SL Beta are for the main SL grid. I'd love to do a proper full scale test on the main grid but that's not possible of course.

 

13 minutes ago, arton Rotaru said:

It boils down on the client side. Draw calls, state changes, batching etc..

Yes but those factors should favour mesh over prims in these tests yet the results show exactly the opposite. When it comes to the client side I think the conclusion is already quite clear: replacing prims with identical looking meshes will never improve viewer performance. At best the performance reduction is small enough to be ignored, at worst it can be considerable-

That doesn't mean prims are always preferable to mesh of course. There are things we just can't build with prims and besides, even I'm not so obsessed with performance I'd say we we should always prioritise real gains over imaginary (ie LI reduction) ones in cases like this.

[Candide LeMay]

39 minutes ago, ChinRey said:

Good point but the sim server still does quite a bit of work on each object even if the physics engine isn't engaged. I don't know why but it does and that's what the server weight part of the land impact calculation is supposed to represent.

The sim has to manage interest list and object updates for each of the connected clients. Again, I don't see why the time spent on these tasks should be different between prim and mesh objects. Maybe if you could get 100+ agents into a sim and compare the server times with different set of objects that fill the sim you'd see some differences, but that seems like a difficult (and probably pointless) test to execute

[Profaitchikenz Haiku]

 

 

3 hours ago, ChinRey said:

Second Life Beta, made a linkset of 256 prim cubes and converted it into a 6 LI mesh.

I'm intrigued by the great difference between packets in and packets out on the SecondLife Beta test. I can't work out the significance of it, but it's a big change.

The only real advantage I can see to using all mesh or mostly mesh for things like houses would be to try and reduce the drift or creep that happens at high altitudes, in that it would perhaps result in fewer items having to be teased back into place.

[ChinRey]

11 minutes ago, Profaitchikenz Haiku said:

I'm intrigued by the great difference between packets in and packets out on the SecondLife Beta test. I can't work out the significance of it, but it's a big change.

Yes, you see that in the net time too. I'm not sure why. Mesh is of course far heavier than prims when it come to bandwidth but I did wait until things seemed to have stabilized before I took the snapshots.

I hope this discussion will continue for a bit, it's quite intriguing and I don't think we have all the answers yet. But it seems to me there are three conclusions we can draw right away:

1. When it comes to actual performance, there is nothing to gain from converting prims to mesh neither for server, bandwidth or client.
2. In his blogpost "How Second Life Primitives [Really] Work" Avi Bar-Zeev Mentioned that it's generally much easier for the client to draw algorithmically generated shapes with all their inevitable extra geometry than fully optimized (polylist) meshes. It seems this is an even more significant factor than I (and probably most others who thought of it at all) realized. It seems that as a rule of thumb we should expect one mesh triangle to be as render heavy as 20-30 (or even more) tris generated from prims.
3. The land impact system is even more broken and unbalanced than we thought. It's supposed to measure the work load on various parts of the system but when it comes to actual performance it seems that 1 LI of mesh can easily be as heavy on all parts of the system as 20-30 prims and even that may be a gross underestimation.

[Profaitchikenz Haiku]

4 hours ago, ChinRey said:

When it comes to actual performance, there is nothing to gain from converting prims to mesh neither for server, bandwidth or client.

The main advantage in that case comes from build-simplification for the purposes of scripting items to be moved around.

For example, when puppeteering a railway engine, a single set of driving wheels built from prims comes out at about 60-odd prims (spokes, wheels, flanges, crank pins...) so rotating those around the axle is a lot of scripting, but meshing those 60-odd prims into an 11 LI mesh object means only a single item to be rotated. And of course, railway engines will have two or three such sets of driving wheels...

So the next test to try and make is to see if it is easier on the server to move a linkset of mainly prims, compared to a linkset of mixed mesh, sculpts and prims? I'll see if I can get some metrics on a couple of my in-hand projects.

[arton Rotaru]

21 hours ago, ChinRey said:

Yes but those factors should favour mesh over prims in these tests yet the results show exactly the opposite. When it comes to the client side I think the conclusion is already quite clear: replacing prims with identical looking meshes will never improve viewer performance. At best the performance reduction is small enough to be ignored, at worst it can be considerable-

That doesn't mean prims are always preferable to mesh of course. There are things we just can't build with prims and besides, even I'm not so obsessed with performance I'd say we we should always prioritise real gains over imaginary (ie LI reduction) ones in cases like this.

Yeah, IDK. Maybe put a couple of unique material textures onto the prims, instead of having them all the same default plywood map. I could imagine that batching does play a role.

[ChinRey]

18 minutes ago, arton Rotaru said:

Yeah, IDK. Maybe put a couple of unique material textures onto the prims, instead of having them all the same default plywood map. I could imagine that batching does play a role.

But then I would have ahd to do the same with the mesh to have fair comparasion. 😉

[arton Rotaru]

7 minutes ago, ChinRey said:

But then I would have ahd to do the same with the mesh to have fair comparasion. 😉

But the point is, the mesh is much less pieces. If the prims can't be batched as efficient as they might be when they are all the same, the mesh would be beneficial. Playing that game with just a single build doesn't fill the picture probably. But in a full sim build, it might make a difference.

[Love Zhaoying]

I am confused - I did not know mesh - even if fewer "pieces" - was actually supposed to result in higher performance than prims.

[ChinRey]

1 hour ago, Love Zhaoying said:

I am confused - I did not know mesh - even if fewer "pieces" - was actually supposed to result in higher performance than prims.

It's about tri count. Prims are standardized multi-purpose shapes which means they will nearly always contain some tris and vertices that aren't actually needed but still keep the gpu busy. With well made mesh you reduce the gpu workload by eliminating all that extra geometry. If you look at the second test of mine, the prim linkset has 48,960 tris whilst the identical looking mesh has 3,060. There's no doubt whatsoever that it was much easier for the gpu to handle the mesh than the prims in that test. (The number of faces is also a minor factor. In this test the prim linkset has 1,530 different faces, the mesh only one. The SL software does consolidate draw calls for prims and static meshes - but not for rigged/fitted mesh unless something has changed recently - so the prims still only use a single draw call but consolidating is of course a little bit of extra work for the computer itself.

However, the gpu can't draw all those tris before they have been loaded and processed by the cpu. Prims have considerably lower file sizes than meshes and are also easier to handle for the cpu in other ways.

There's is no doubt that prims will outperform mesh if the tri and vertice counts are the same for both. But with a mesh you can improve the performance by cutting down on the tris. The question is how much do you have to cut before it beats them prims? The way land impact is calculated suggests that 24-50% is more than enough. That's obvioulsy not true, the land impact system is made to strongly favour mesh over prims, but 75% should do, right? This test suggests that even 95% is not enough.

Oh, and there's also no doubt that prim builds outperform the kind of quick-and-dirty unoptimized mesh we see far too often in SL. But I never do that kind of mesh (Note to self, remember to remove this link before submitting the post.)

I have one important reservation though: This is a single test only. Both the scene as a whole and the client hardware are important factors here so is we want to determine an average optimal prim-to-mesh ratio, we need to perform such tests in different places with different hardware.

Edited September 20, 2022 by ChinRey

[Love Zhaoying]

2 minutes ago, ChinRey said:

(Note to self, remember to remove this link before submitting the post.)

Thanks for including this!

[ChinRey]

Just now, Love Zhaoying said:

Thanks for including this!

Woops!

/me blushes.

[Love Zhaoying]

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

I decided to do another test so I went over to Second Life Beta, made a linkset of 256 prim cubes and converted it into a 6 LI mesh. Here are the results:

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???

I notice the Packets In/Out is much worse with the Mesh in your second example..

ETA: Sorry! I see someone did mention that above, and you replied!

Edited September 20, 2022 by Love Zhaoying

[Love Zhaoying]

On 9/16/2022 at 12:35 PM, ChinRey said:

In his blogpost "How Second Life Primitives [Really] Work" Avi Bar-Zeev Mentioned that it's generally much easier for the client to draw algorithmically generated shapes with all their inevitable extra geometry than fully optimized (polylist) meshes.

The above does not surprise me, it was my guess when I first started reading your post!

I wonder how Sculpties compare, except for the initial rendering of course (BlobSphere => PrettyThang).

[ChinRey]

43 minutes ago, Love Zhaoying said:

I wonder how Sculpties compare, except for the initial rendering of course (BlobSphere => PrettyThang).

Sculpts are heavier for the cpu and to some extent the gpu than comparable meshes. This is not because sculpts are inherently heavy, it's mostly about poor implementation. Meshes also often require less heavy texturing than sculpts although it's very rare for SL mesh makers to take advantage of this nowadays. However, well made and properly optimized sculpts will usually have much smaller file sizes than the same shapes as mesh and that affects performance in several ways. How the LOD models end up is also also an important factor for the performance difference between sculpts and mesh and. That's a topic for a big discussion in itself and it depends a lot on the creator's care and technical skills.

There is no absolute answer. Well optimized mesh will usually be better than even the best optimized sculpts but there are exceptions and when it comes to the usual poorly optimized sculpts and meshes, I'm not sure if we can even come up with a rough guideline.

Btw, I have to add that I don't entirely blame the LL developers for the poor implementation of sculpts. They were obviously under a lot of pressure to finish the task with limited resources and time so they were forced to take some regrettable shortcuts. They really should have done a better task analyzis though and that's their responsibility.

Edited September 20, 2022 by ChinRey

[Love Zhaoying]

Just now, ChinRey said:

Sculpts are heavier for the cpu and to some extent the gpu than comparable meshes. This is not because sculpts are inherently heavy, it's mostly about poor implementation. Meshes also often require less heavy texturing than sculpts although it's very rare for SL mesh makers to take advantage of this nowadays. However, well made and properly optimized sculpts will usually have much smaller file sizes than the same shapes as mesh and that affects performance in several ways. How the LOD models end up is also also an important factor for the performance difference between sculpts and mesh and. That's a topic for a big discussion in itself and it depends a lot on the creator's care and technical skills.

There is no absolute answer. Well optimized mesh will usually be better than even the best optimized sculpts but there are exceptions and when it comes to the usual poorly optimized sculpts and meshes, I'm not sure if we can even come up with a rough guideline.

Btw, I have to add that I don't entirely blame the LL developers for the poor implementation of sculpts. They were obviously under a lot of pressure to finish the task with limited resources and time so they were forced to take some regrettable shortcuts. They really should have done a better task analyzis though and that's their responsibility.

Ironic that Sculpts have the lower LI...

I guess that goes along with your previous analysis, that LI is not based very well on performance impact.

[Frionil Fang]

For what it's worth, I got curious enough to do the same-ish test:

• 256 cubes linkset object
• only 1 texture used, 50% transparent blank (transparency to ensure they're less optimizable)
• exported, cleaned up to minimum (256*6*2 = 3072 triangles)
• uploaded at highest-highest-1-1 triangles LODs with simple box physics, resulting in 33 LI because I wasn't gonna bother logging on to the test grid or pay a lot for a test object

Performed the test at a completely empty sandbox with no one but myself present but not on camera, no other objects in draw distance or even remotely nearby.

The basic statistics floater didn't give me anything to even begin to guess which was better: there definitely was no reliable difference in packets in/out regardless which object was being viewed. No sim performance value was different to any noticeable degree.

Fast timers told me (objects multiplied by 28, to get any kind of measurable numbers) rendering the prim version took 12.6 ms with 0.2 ms swap time; rendering the mesh version takes 10.6 ms, with 7.4 swap time. Other numbers not different enough to be noticeable. For the record, the scene without the objects in view had a frame time of 4.5 ms with swap time 1.5 ms (why swap would be higher on an empty scene... don't ask me). No frame limiting or vsync in use.

So my conclusion: I've no idea what would be better, but I wouldn't deem an optimized, equivalent mesh useless since it *does* seem to render faster at least for me -- though this again probably depends a whole lot on the object, the scene it is in, how much of it is visible, and not just the triangle count. Would really need a mass test in a highly active location to start getting better values, I suppose.

2 hours ago, Love Zhaoying said:

I guess that goes along with your previous analysis, that LI is not based very well on performance impact.

When people can make sugar cubes with 100+k triangles and 64 MB of textures while still probably cheating it down to 1 LI? No, I'd imagine LI (like rendering complexity) is not exactly a perfect measure.

Edited September 20, 2022 by Frionil Fang

[Love Zhaoying]

13 minutes ago, Frionil Fang said:

3 hours ago, Love Zhaoying said:

I guess that goes along with your previous analysis, that LI is not based very well on performance impact.

When people can make sugar cubes with 100+k triangles and 64 MB of textures while still probably cheating it down to 1 LI? No, I'd imagine LI (like rendering complexity) is not exactly a perfect measure.

In case you did miss it,@ChinRey's post about the sugar cube was a joke - not real, not representing an actual thing, but in jest. Per my understanding. But the Jewelry example was "real" (does not mean that jewelry was 1LI though, I didn't look).

[Frionil Fang]

1 minute ago, Love Zhaoying said:

the sugar cube was a joke - not real, not representing an actual thing, but in jest. Per my understanding. But the Jewelry example was "real" (does not mean that jewelry was 1LI though, I didn't look).

It's entirely possible I may have missed something, I do that a lot, but sadly the sugar cube really represents objects I've seen out in the wild so I felt it's still a good bad example!

[Love Zhaoying]

3 minutes ago, Frionil Fang said:

It's entirely possible I may have missed something, I do that a lot, but sadly the sugar cube really represents objects I've seen out in the wild so I felt it's still a good bad example!

Understood. Here's the part you may have missed:

 

[Profaitchikenz Haiku]

3 hours ago, Love Zhaoying said:

Ironic that Sculpts have the lower LI...

As far as I understand the process, sculpts and prims have a default LoD behaviour that is built-in, whereas mesh, as we know, either needs specific LoD models crafting or a default process during upload creates them.

Sculpts also have a fairly basic physics shape. Leaving aside the tricky subject of trying to texture them, I find they are most useful because you know they're just 1 LI per map with predictable LoD behaviour and so require far less work to use.

Ages ago, I remember reading a post by somebody explaining that sculpts are turned into the collection of triangles by a process that was admitted to be "a bit of a hack", but I haven't been able to locate this. The main point I take away from this is that prims and sculpts are more "native" to the SL object rendering methods than Mesh, but whether this is because they are older, or because they are essentially simpler and easier to implement that mesh I don't know.

All of my explorations regarding efficiency have been to do with puppeteering prims/sculpt/part-mesh objects and as such I have always been focused on the script load, not any other server loads such as physics. Partly this is due to my trying to achieve smooth motion. but also it is laziness on my part in that many of the stats and metrics available via the stats floater don't seem to mean anything obvious to me. The increase in packets in/out Chin showed on the beta grid is a prime example, I would not usually have paid much attention to it, and it may well be that it is one of these "doesn't matter" (*) cases where a stat that is available has no real meaning as far as our experience in-world goes.

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.

 

(*)

"Doesn't matter, Vic"

"Doesn't matter, Bob"

DC Al Capo