Prims vs mesh performance

[Tess Juel]

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:

Mesh vs prims Kitely.png (131.92 KiB) Viewed 4101 times

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:

Mesh vs prims SL Beta.png (164.54 KiB) Viewed 4101 times

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?

[Ilan Tochner]

Hi Tess,

I suspect that the different LOD settings for prims vs meshes may have something to do with this as well.

[Tess Juel]

I suspect that the different LOD settings for prims vs meshes may have something to do with this as well.

I'm afraid not. If that was the case, the mesh test results would have been much better. As I said, these are highly optimised meshes, made to have exactly the tris and vertices they need at each LOD level, nothing more and nothing less. I didn't add any extra details to the meshes since the point here is to replicate the looks of the original build as closely as possible.

So their tri and vertice counts are considerably lower, not higher, than that of their prim counterparts. I don't have the exact numbers for the Kitely test but in the one I did on SL Beta the tri count for the prims were 49,152 while the mesh had 3,072. The Kitely test should be in the same ballpark so let's assume a fairly conservative 90% reduction in the tri and vertice counts from prims to mesh.

[Dot Matrix]

Thank you for doing these tests, Tess. Interesting results which could encourage those who used to enjoy building in-world using prims to return.

The push for mesh also pushed some of us away from virtual world creation, by adding barriers we couldn’t surmount no matter how many tutorials we attended.

[Tess Juel]

Thank you for doing these tests, Tess. Interesting results which could encourage those who used to enjoy building in-world using prims to return.

Oh yes, it wold be great if we could encourage people to build more with prims!

However, there is something that didn't occur to me today. The reason why prims can outperform mesh even with 30 times as many tris is obviously that prims are easier for the cpu to handle than mesh. As far as the gpu is concerned, a tri is a tri and a vertice is a vertice, it doesn't matter if it came from a prim or from a mesh. This means that the "power balance" between the two is a crucial factor. If your gpu has to stop and wait for data from the cpu all the time, prims will tend to outperforms mesh even with a higher polycount. If your cpu has to keep waiting for the gpu to do its jobs, lower poly meshes will outperform prims.
This power balance is of course different for different computers. My computer may be (I'm not sure) quite a bit more slanted towards gpu power so it may prefer prims more than most computers do. It would be really great if others could do similar tests with different hardware setups.

Even so, I think it's clear that prims are much underrated when it comes to performance these days and we really should use them more.

---

Frame rate aside, there's also the question of bandwidth/file size. If my calculations are right (somebody correct me here if they have better data), the file size of 1 LI calculated the SL way of mesh is roughly the same as 20-30 prims. A sculpt's file size can be anything from 1/10th to 100 times or more as the same shape done with mesh. Bandwidth/file size affects performance in two ways: it takes time to load of course, even if it's from SSD cache, and loading data adds quite a bit to the cpu's workload.

When I was a newbie builder, I was lucky enough to catch the attention of Aley/Arcadia Asylum. One of the most important lessons she taught me was to use all tools available. I think is the key to creating truly optimized scenes. You want a good balance between prims and mesh. Keep the gpu busy drawing prims while the cpu is hard at work loading and processing meshes. Even a few sculpts may be appropriate. They are rather hard both on cpu and gpu (not by nature btw - it's all because of dodgy programming) but if they are well optimized, the badnwidth you save compared to mesh may be worth it.

[Gregg Legendary]

Great thread!
Allow me to chime in on my beliefs on the matter whether they be wrong or right... i am often both... sometimes even at the same time lol...
The main difference is the server code and viewer code were back in the Stoneage originally written for prims (and yes prims are actually mesh as is everything in this format) However prims (and eventually sculpties) were made so the average person could manipulate and create with them easily, so they are technically dumbed down (maybe smarted up?) mesh lolz. The server code and viewer code were I believe written (mostly likely by error) to ignore certain aspects of a prim and or sculpt that are bad mesh form causing them to be less resource intensive.
I am in the process of converting everything to mesh and i think the secret to compete with prim performance is deleting every face that cannot be seen.
::takes off tinfoil hat;:

[Tess Juel]

However prims (and eventually sculpties) were made so the average person could manipulate and create with them easily,

Actually no. Prims do perform better than mesh even if the tri count is a bit higher. This is the reason why LL went for prims in the first place. They were struggling to get an online shared virtual world to work at all until Philip Rosedale met Avi Bar-Zeev who had "happened to have studied computational geometry in a college". The prim system he developed was the key factor that solved LL's performance problems. The fact that prims are easier to build with didn't even occur to them until a little bit later when one of the investors suggested they should use inworld building as a selling point.

Two interesting articles worth reading:
http://www.realityprime.com/blog/2008/0 ... eally-work (Wayback machine link since Bar-Zeev took down his blog a while ago)
and
https://modemworld.me/2022/01/25/happy- ... mble-prim/

In addition to the difference in client side load, prims also need far less data to be transferred. Any prim shape can be defined by only 15 bytes of raw data - including all LOD models. A polylist mesh - what we usually simply call a mesh - needs several thousand bytes for per vertice in each and every LOD model! (Those numbers are for the data unique to each and do not include the data both need.) In case somebody wonders, a sculpt needs about 16,500 bytes of data - much more than a prim but still far less than a mesh of similar complexity.

So I already knew I had to cut down quite a bit on the tri count to get a performance boost from the mesh; no surprise there. But in that second test I had a 94% reduction plus all the advantages of a single coalesced object and asset file and that still wasn't enough for the mesh to match the prim linkset's performance, let alone beat it! That was the big shock.

[Gregg Legendary]

However prims (and eventually sculpties) were made so the average person could manipulate and create with them easily,

Actually no. Prims do perform better than mesh even if the tri count is a bit higher. This is the reason why LL went for prims in the first place. They were struggling to get an online shared virtual world to work at all until Philip Rosedale met Avi Bar-Zeev who had "happened to have studied computational geometry in a college". The prim system he developed was the key factor that solved LL's performance problems. The fact that prims are easier to build with didn't even occur to them until a little bit later when one of the investors suggested they should use inworld building as a selling point.

Two interesting articles worth reading:
http://www.realityprime.com/blog/2008/0 ... eally-work (Wayback machine link since Bar-Zeev took down his blog a while ago)
and
https://modemworld.me/2022/01/25/happy- ... mble-prim/

In addition to the difference in client side load, prims also need far less data to be transferred. Any prim shape can be defined by only 15 bytes of raw data - including all LOD models. A polylist mesh - what we usually simply call a mesh - needs several thousand bytes for per vertice in each and every LOD model! (Those numbers are for the data unique to each and do not include the data both need.) In case somebody wonders, a sculpt needs about 16,500 bytes of data - much more than a prim but still far less than a mesh of similar complexity.

So I already knew I had to cut down quite a bit on the tri count to get a performance boost from the mesh; no surprise there. But in that second test I had a 94% reduction plus all the advantages of a single coalesced object and asset file and that still wasn't enough for the mesh to match the prim linkset's performance, let alone beat it! That was the big shock.

Great Info I never knew!