Is it worth rebuilding my house using (simple) mesh?

[Vulpinus]

I built a mansion from prims and at a rough guess it's probably around 1000 LI. Most prims are linked, so say around 1500 cuboid prims. Furniture not included, this is just the basic structure.

I've recently discovered that a prim cube uses an awful lot of triangles for what it is; 120 if I've read correctly. So that's 180,000 triangles for my 1500 prim house.

I'm an obsessive optimizer, so I took the plunge into Blender and made myself a mesh 'wall' with just two texturable faces and four triangles, and a couple more with an additional face or two.

Using these would give me a house with around 6000 triangles.

Is it worth rebuilding my house with mesh walls like this, or is it really not worth the effort to save 174,000 triangles? (realigning all the textures on the inside will be a pain in the backside, but it would keep me off the streets for a while.)

I don't get any problems looking at the house, btw, unlike looking at my fountain which has a load of statues in white marble, which look almost exactly the same in wireframe view because the triangles are so densly packed, and drop my FPS by 50%.

[Drongle McMahon]

No doubt you can save a lot of LI. You will have to do more than just replacing boxes one-for-one though, even if you eliminate hidden faces, because each mesh will be at least 0.5LI because of "server weight". So you will need to do some  joining of pieces together into single meshes. If you stick to walls, you will be ok with physics (doors apart), but with more complex shapes you will have to learn about physics shapes. The other essential will be some effort in UV mapping, to make the texturing simple and effective. Then there's LODs. I would say it depends on whether you like learning stuff. If so, you will get lots of enjoyment from progressively optimising your palace, even if the learning is a bit hard.

PS - a cube is 108 triangles.

[Vulpinus]

108 - that's what I calculated, but then I read 120 in a couple of old posts from here, lol. Thought there must be some hidden that I hadn't seen in wireframe.

Yeah, I know I won't save much LI doing it the simplest way. I've already optimised my prim linksets. I was more wondering, from a rendering point of view, if it would be significantly better.

It did take me a couple of hours to figure out how to do my wall, most of which was wondering why I couldn't apply a texture once I uploaded it to SL (have to unwrap it...). Actually, no, most of it was trying to figure out Blender's user interface. I thought my biomolecular simulation software was complex... Blender makes Discovery Studio look trivial.

I understand the basics, but I'm getting the impression that a lot more than that is needed. I think the key is 'progressive', like you said, and doing a better job of it. I enjoy building stuff, so it's about time I learned to do it properly. Time being the only issue really... but such is life.

[Rhys Goode]

When I was learning Blender, I decided to make a model that closely duplicated  my conventional prim/sculptie shop. With a fair bit of fussing, I was able to get LI from 58 down to 8. Also. I have a number of sky platforms that used to go for 4 or 5 LI, now just 1 each.

So, for me, it freed up a bunch of prims.  But the really valuable thing, was that it kept me focused on learning the ins and outs of using blender to make things in SL.

[Dree Eames]

Hmmm.  You should have a chat with the sculptor of that fountain.  

[ChinRey]

---

Vulpinus wrote:

Yeah, I know I won't save much LI doing it the simplest way. I've already optimised my prim linksets. I was more wondering, from a rendering point of view, if it would be significantly better.

---

That's a tricky question and I'm not even sure if there is a clear answer. Rendering load depends on a lot more than the number of tris, that's for sure. For a start, textures nearly always add far more load on the gpu than geometry does. But even if we look at geometry on its own, there are a lot of factors that play in.

Standardisation of data seems to be one important factor. Prims, sculpts and "SL mesh" are all simplified and standardized version of the general mesh we see in many other virtual environments. How they are standardized is very different though.

The prim system uses a few basic shapes and a few relatively simple algorithms to modify them. This is of course easy work for a computer to deal with but usually you have to include lots of superfluous data simply because there's no way to remove it.

A sculpt map is a mesh grid where the number of vertices and tris and the relationship between them are fixed. The only variable is the position of each vertice. Again, the standardised system makes the work easier for the computer but it also gives it a lot of extra work calculating the position of vertices that aren't necessary for the model.

Mesh that is optimized for SL can have far fewer tris and vertices than a similar model made with prims or sculpts. But with no clear system the computer has to do a lot more work on each vertice to get it right. In other words, it tends to give the computer less but harder work than prims and sculpts.

Mesh that in not optimized for SL has the worst of both worlds of course: lots of superfluous data and no clear system for the computer to work on to but we don't do that kind of mesh - not in this forum! :matte-motes-wink:

[Drongle McMahon]

"But with no clear system the computer has to do a lot more work on each vertice to get it right."

I don't think that's strictly true for really like-for-like replcements. For both prims and sculpties the computer has to generate all the vertex, normal and UV map data from parameters or sculpt map, producing the mesh data, before it can start rendering. For mesh, that data is already there in the downloaded data, so that the calculation step is eliminated. So, for the same vertices etc., mesh is less work for the cpu and the same work for the rendering engine. Given that mesh can generally specify the same shape with fewer vertices, well made mesh replacements should usually be less burdensome for the rendering engine.

However, the simple prim parameters, and the small sculpt map, mean that the amount of data downloaded is generally much less than for prims and sculpties than the equivalent mesh (not always true for sculpties if they waste a lot of geometry to get sharp corners etc.). So it is the download system, connection and asset server loads, that suffers with mesh replacements.

Of course, that is assuming everythng is identical in the final geometry. Unfortunately, it is very easy to succumb to the temptation for mesh to be over-detailed, poorly optimised and over-textured. Because of that, mesh replacements do very often end up putting more load on all systems, including the rendering engine, than the simpler assets they were supposed to replace. So your overall conclusion is, sadly, usually correct.

[ChinRey]

---

Drongle McMahon wrote:

"But with no clear system the computer has to do a lot more work on each vertice to get it right."

I don't think that's strictly true for really like-for-like replcements.

---

You're right, it's a very simplified explanation - more an illustration really - and yes, well made mesh should be easier, not harder on the rendering engine than prims. But you don't have to travel much around SL to notice it isn't so. Or just copy-drag a linkset with a few relatively complex meshes in it and watch how long it takes for the copy - which will only contain cached mesh assets - to render properly.

Mesh do tend to render a little bit slower than prims. I don't know why although I do have a few theories.

[Drongle McMahon]

"which will only contain cached mesh assets"

Indeed. I suppose that would be because retrieval from the cache is as much dependent on the size of the data as is download, albeit on a different order of magnitude. So for many cases, the reading of the mesh data from disc will take more time than the prim's geometry calculation in the cpu.

"well made mesh should be easier, not harder on the rendering engine than prims"

I would suggest that if it isn't easier, then it isn't well made (for identical geometry, that is).

 

[ChinRey]

---

Drongle McMahon wrote:

I would suggest that if it isn't easier, then it isn't well made (for identical geometry, that is).

 

---

Or that the geometry will hardly ever be exactly the same. But that's not the whole story. Make a basic wall with a window opening from four prims. That's 768 tris in high LOD. Make the same shape as mesh, remove all those superfluous tris and reduce it down to just the outer and inner wall - 16 tris. It still renders slightly slower than the prim version. Of course, this can't be ecplained by the gpu's capacity or lack of capacity, it has to have something to do with how the SL software manages the gpu. But the end result is the same in eitehr case.

[Drongle McMahon]

Speed to render is not the same thing as load on the gpu, of course. So I think the load-on-gpu argument still always favours mesh. Other factors may contribute to a different outcome for the rendering speed, as even identical meshes from eaither prim or mesh asset have to be presented to the gpu by the cpu, and the timing of that may depend on all sorts of other factors.....which is just another way of saying the samething.

[ChinRey]

---

Drongle McMahon wrote:

Speed to render is not the same thing as load on the gpu, of course. So I think the load-on-gpu argument still always favours mesh.

---

Oh yes it does but I'm beginning to wonder if raw gpu power is as important to render speed as we usually think.

The explanation to my wall example is simple of course - I realized that right after I hit the post button: the prim shapes are stored in RAM, hardwired into the viewer's code while the mesh asset has to be retrieved either from harddisk cache or from a CDN server. Does the SL viewers cache mesh assets in RAM at all? What would hapen if we used a RAM disk rather than harddisk for the main cache?

It's worth noticing that default MeshMaxConcurrentRequests is still as low as 32 and if I understand correctly they still penalize you if you set it at the level you really need in today's SL. It's quite possible other aspects of mesh handling is throttled in a similar way or simply just never upgraded to be able to handle the amount of mesh we use now.

A few observations, not related to mesh but to the question how efficiently SL actually uses our gpus' resources:

A while ago I had some serious connection problems with packet losses so bad I could hardly stay in SL at all. At one point I was standing still in the middle of a completely empty low lag water sim (Moses) wearing the test avatar with that tacky polka dot dress. In that setting, which shouldn't really require much data transfer at all, the connection problems was bad enough to seriously affect rendering - rendering of objects and textures and such all well and truly cached on my harddisk that is.

A friend of mine once took me to the store of an SL designer famous for his wonderful use of ultra-realistic, ultra-laggy baked textures. I got some serious render lag issues there of course but nothing like what my friend had to struggle with, even though her gpu is far more powerful than mine.

Some time later I took another friend to the same store. She was using SLGo at that time so I didn't expect her to have any problems but it actually got so bad the SLGo server wasn't jsut ditching textures but most of the objects. My much humbler AMD card still fought on bravely and somehow managed to render the scene with a lag level that was serioulsy annoying but never critical. (For those who don't know what SLGo is, it's a service that does all the hard rendering work for you feeding you computer a relatively simple video stream of the scene. Quite a good idea if your computer has problems coping with SL on its own althoguh of course a video stream will never be as clear and sharp as local rendering.)

A week or two ago, in a desperate attempt to figure out that horrendous Project Interesting Texture Thrashing bug I rezzed a full sim platform 4000 m above Coniston, textured it with a 4x4 pixel blank texture, removed all clothing and attachments from my avatar and stood right in the middle of it. Then I opened the txture console and wathced as my viewer loaded texture after texture after texture...

[Drongle McMahon]

"What would hapen if we used a RAM disk rather than harddisk for the main cache?"

Then, of course, there's the difference between old fashioned hard disks and SSDs. My current machine is SSD onl;y, which should be making the cache retrieval much faster (unless the cache retrieval ios cpu-bound), changing the balance again.

[Vulpinus]

Wow - this is all making me realise how much I don't know, lol. It might have been a simple question, but it certainly doesn't have a simple answer.

I added a dedicated SSD (Samsung 850 EVO) just for my SL cache a few weeks ago. My main HD is also SSD of course, but I had been using a spinning disk for the cache. I hoped it might make some difference to rendering things from the cache, but so far I've not noticed any difference.

[ChinRey]

---

Vulpinus wrote:

Wow - this is all making me realise how much I don't know, lol. It might have been a simple question, but it certainly doesn't have a simple answer.

---

Or maybe me and Drongle just talk too much. :matte-motes-wink:

---

Vulpinus wrote:

I added a dedicated SSD (Samsung 850 EVO) just for my SL cache a few weeks ago. My main HD is also SSD of course, but I had been using a spinning disk for the cache. I hoped it might make some difference to rendering things from the cache, but so far I've not noticed any difference.

---

Oh kay, so that's not where the problem is then.

[ChinRey]

---

ChinRey wrote:

...

and yes, well made mesh

should

be easier, not harder on the rendering engine than prims. But you don't have to travel much around SL to notice it isn't so.

---

Maybe I shouldn't reply to one of my own posts but I may have found at least a partial explanation why mesh renders slwoer than it should.

When the gpu draws an, it first renders a generic grid. When that is done, it replaces this gridwith the lowest LOD model and then it goes up through hte LOD models until it reaches the right one for the viewing distance, just as it does with sculpts and prims.

The generic initial gridmay explain some of the rendering speed difference. For a mesh it's usually a torus with a rather high vertice count (although I've seen a 20 vertice cube too recently) while a sculpt starts off as a sphere - or possibly the shape of whatever stitching type it has. I don't know what grid a prim begins as but most likely it's an untwisted version of the basic prim type.

The complexity of the initial grid of a mesh adds quite a bit of extra rendering time of course and it's quite possible this explains why mesh renders slwoer than it should compared to prims.