When does a sculpty work better than mesh for land impact?

[Elinah Iredell]

Hi everyone. I have ideas to landscape my new land but will need to use large objects so mesh would bring up the land impact too high . That leaves sculpty  as the only choice because you can stretch them very large and not increase land impact. The question I have is will they create too much lag? I have read that some sculpty creations are very lag intensive and create a lot of lag,while some others  that are made better do not.  How do you evaluate a  sculpty to know if it is made well or not, and is there a way to test how much lag it will  create?Are there creators that make sculpty landscaping items that are made better and do not cause lag? Thanks

[OptimoMaximo]

The evaluation done solely on land impact is a big mistake: what really should be accounted for is the triangle or vertices count. Being lower or fixed LI doesn't actually mean that they're more efficient.

However, to have the most efficient sculpty, the lower lag ones, you must make sure that the sculpt maps comply to a specific number of pixels, 4096. So whatever sculpt map dimension in pixel that gives you as final result 4096 pixels is efficient (example: 64*64 pixels or 32*128 and so on down this line), if above this number, those are "the laggy ones". Note also that you can go lower than total 4096, for low detail objects a 32*32 works as well, as the total number of pixels is below 4096 (the max it should have). Anything above a total amount of 4096 pixels is wasted resource and doesn't give any higher detail

[ChinRey]

7 hours ago, Elinah Iredell said:

How do you evaluate a  sculpty to know if it is made well or not

First look at the sculpt map. If the total number of pixels is 4096 (64x64, 32x128 etc.) or less, it's an optimizied map and should be reasonably low lag. If it is higher (128x128 is the most common) it's an oversampled map and likely to cause serious issues with lag, load time and render failures.

Next, look at how well the map is utilized. Except for some extremely rare low poly ones, a sculpt will always have somewhere between 1922 and 2048 triangles. How many of them are actually used for something that adds to the look? I don't think it's ever possible to achieve 100% efficiency with sculpts but they will always have much lower streaming cost than mesh so it can be a good alternative even if some triangles go to waste. It's hard to give a specific limit but as a rule of thumb, for an item that needs - say about 00 - triangles or more, a sculpt is likely to outperform regular SL mesh. It will never perform as good as optimized mesh but optimized mesh is rare in SL and once we get close to 250 triangles, the difference may be small enough it's worth it for the land impact you save.

Third, look at the LoD, how well the shape holds up at a distance. LoD and lag are closely related since poor LoD models will force you to increase the LoD factor of your viewer and contrary to what many claim, this can add a lot of load on your viewer. A well laid out sculpt map will usually have better LoD than the average SL mesh (although hardly ever as good as well made mesh), a poorly laid out one may be a LoD disaster.

Fourth: textures. Even though I keep reminding @Penny Patton that geometry is important to lag too,  she's certainly right that textures are the most important factor in SL as it is today. Sculpts often require custom made baked textures and if they are many and high resolution, they can add considerably to the lag. On the other hand, texture abuse is depressingly common among mesh makers (especially among the best known mesh landscape item makers) and the commercial mesh alternative(s) may well be far more texture heavy than the sculpt. The latest version of Firestorm has a really handy VRAM measuring feature (VRAM use is a very good indicator of texture density). Right-click on an object and select "Inspect" from the "Object" submenu and you get something like this:

 

One final factor to consider, is the load balance. Sculpts' huge advantage over mesh is that they have an exceptionally low streaming cost. Meshes of the complexity where sculpts become an option at all, will always require far more data to be downloaded. The viewer code processing sculpts is horrendously poorly written though (the mesh code is just dodgy) so the viewer has to spend quite a lot of time figuring out the data. Prims mainly load the gpu. Unless you have a lot of them, the streaming cost is even loeer than for sculpts and the viewer was specially made to handle them right from the start. So, the main bottleneck for mesh is usually the bandwidth, for sculpts it's the cpu power and for prims the gpu. By mixing them intelligently (of course using well made optimized meshes and sculpts and efficiently built prim items) you can balance the load between the different links in the render chain and achieve a far more efficient complete scene than any of the three can deliver on its own.

To sum it up: Sculpts have some serious performance issues but so do fitted mesh and even regular mesh if it isn't well made. If used well, they can be a very good low lag alternative.

There is a bit of hysteria about sculpts these days though. I went to a well known rp area yesterday. The moment I arrived, I got a message telling me to check if I was lagging the place down by wearing any sculpted objects. It was a cluster of sims loaded with poorly optimized, heavily textured mesh and full of poorly optimized, heavily textured mesh avatars and the owner was frantic about a few sculpts that would have been so small they'd be LoD'ed down to lowest level anyway. It's ridiculous of course but unfortunately this kind fo fuzzy thinking is all too common in SL.

Edited June 14, 2018 by ChinRey

[Penny Patton]

2 hours ago, ChinRey said:

Even though I keep reminding @Penny Patton that geometry is important to lag too, 

I've never said geometry wasn't important. It is, and excessive geometry is particularly a problem with attachments, as you're not beholden to Land Impact calculations. But there are also those content creators who try to get around LI by gutting their LOD settings, telling customers to crank up object detail to see their creations properly (avoid any content creator who tells you to do this).

I tend to focus on the problem with textures for the reasons you lay out here, and the fact that a surprising number of SL content creators take the absurd position that textures don't affect performance at all.

2 hours ago, ChinRey said:

The latest version of Firestorm has a really handy VRAM measuring feature (VRAM use is a very good indicator of texture density).

Sadly, the Firestorm developers chose to remove some functionality that was included with this feature when it was offered to them.

Originally included was the ability to Jelly Doll avatars based on their memory use, just like you can cap Avatar Draw Weight right now. I've been using this for months and it is an absolute Godsend. It only takes one excessively texture-heavy avatar to kill your framerates and send your SL client into fits of lag, stuttering and texture thrashing. Being able to Jelly Doll such avatars has given me the largest performance boost I've ever gotten in Second Life. It's really a shame Firestorm isn't allowing their users to have this feature.

Linden Lab was also given the feature and they've stated that they intend to include it in a future version of the SL Viewer. Perhaps when that happens Firestorm will include it as well.

[Elinah Iredell]

Thank you all for your replies to me. This is all very interesting. Many people think that sculpty has become outdated and obsolete now that mesh has arrived but it appears that it still has a lot of value in sl . I hope I can learn to follow all this wonderful advice .  I also noticed that sometimes prims can still work too for landscaping because they can be stretched very large ,but often they are harder to make realistic looking. I like to try to use them for large rocks  and things though. Is it true they create the least amount of  lag  compared to sculpty or mesh use ? 

I was just wondering if there are any changes or enhancements you would request from Linden in future updates for mesh, sculpty, or prim usage  in the future?  I would love if it was possible to find a way to make mesh and sculpty move and flow like prims can.  I miss that 

Edited June 19, 2018 by Elinah Iredell

[ChinRey]

1 hour ago, Elinah Iredell said:

Thank you all for your replies to me. This is all very interesting. Many people think that sculpty has become outdated and obsolete now that mesh has arrived but it appears that it still has a lot of value in sl.

A lot of value may be an exaggeration but sculpts certainly have their uses even today.

As for lag, I don't know if you ever saw Aley's Pirate Town at Blake Diego (it's gone now unfortunately). It was a quarter sim filled up almost entirely with sculpts of the worst kind - oversampled maps and horrible LoD - but I never heard anybody complain about the lag there.

[Chic Aeon]

Also keep in mind -- in the bigger picture -- that we will have new land impact (rules, criteria, measurements etc) in the not too distant future. So THAT will likely change this discussion a bit. Not so far as the actual use of sculpts and mesh and lag --- but in the LAND IMPACT department which was in the OP.   

This mostly to the OP as I know the others are well aware :D.

[Callum Meriman]

On 20/06/2018 at 12:45 AM, ChinRey said:

As for lag, I don't know if you ever saw Aley's Pirate Town at Blake Diego (it's gone now unfortunately). It was a quarter sim filled up almost entirely with sculpts of the worst kind - oversampled maps and horrible LoD - but I never heard anybody complain about the lag there.

It's still there, moved one sim to the South West.

[Luna Bliss]

On ‎6‎/‎14‎/‎2018 at 3:40 PM, ChinRey said:

If the total number of pixels is 4096 (64x64, 32x128 etc.) or less, it's an optimizied map and should be reasonably low lag. If it is higher (128x128 is the most common) it's an oversampled map and likely to cause serious issues with lag, load time and render failures.

Is a sculpt texture apt to cause more lag than a typical texture because it manifests into a form?  The usual 512x512 texture has 262,144 pixels, so am wondering why a sculpt of say, 128x128 with only 16,384 pixels would be so bad.  Is it only inefficient and so have a minor contribution to lag, as you say Optimo, or would it really cause major lag as you say, ChinRey?

[ChinRey]

9 hours ago, Luna Bliss said:

Is a sculpt texture apt to cause more lag than a typical texture because it manifests into a form?

Yes and no. That is, yes, it causes a lot more lag but no, in theory it doesn't have to. Sculpts are a classic example how an absolutely brilliant idea can be ruined by poor execution.

Downloading a sculpt map is very fast, just as fast as a texture with the same resolution. But then the viewer has to interpret the data and the code the viewer use to translate the sculpt map into a shape is very, very clumsy, awkward and backwards.

Sculpts take very little bandwidth (which is its saving grace and the reason why it can still be a good alternative) and if they are well made, they don't cause too much excessive load on the gpu either. But they can be very hard on the cpu and the graphics processor can't even begin to render the shape until the central processor has figured it out.

For comparasion (I know I'm repeating myself here)

Prims require even less bandwidth than sculpts and thanks to he genius of Avi Bar-Zeev, who developed the prim software for LL, they are also quite light on the cpu and generally not too hard on the gpu either. The weakest link in the prim rendering chain is usually the assets server. Complex prim builds tend to consist of a lot of prims and the server has to find each an every one of them in its bloated database before it can send them to the client.

Regular mesh require a lot more data to be transferred than prims and sculpts. They seem to be fairly light on the cpu though and the gpu load is mostly up to the creator's skills.

Fitted mesh is heavy all the way (except for the assets server). It's at least as heavy on bandwidth as rigid mesh, very heavy on the cpu (possibly even more so than sculpts) and because of the LoD bug and the general poor optimization skills of fitted mesh creators also very gpu heavy.

-------

A simplified - but still rather complex and longish - explanation why sculpts are so gpu heavy.

Linden Lab was one of the pioneers in procedural 3D rendering, that is shapes and scenes generated from fairly simple mathematical formulas rather than a list of raw data. Done well, procedural rendering can speed up the whole process immensely and that is one of the main reasons Second Life could work at all back in 2003. (Ironically, it is also one of the reasons why SL and Sansar are struggling to keep up today. These days everybody else are using more and more procedural techniques while LL seems to have forgotten all about it.)

A sculpt is not procedural. If we look behind all the color/texture mumbo jumbo, a sculpt map is nothing more than a list of the vertice coordinates for a mesh. In theory it would be fairly easy to have a mesh template with all the other data hard coded into the viewer and then simply move the vertices to the correct locations to generate the shape.

The problem the LL developers faced back in 2008 was that the SL software wasn't made for that kind of things, it is all based on procedural shapes. They weren't going to spend the time and effort needed to upgrade the code to handle something as marginal as sculpts properly, so they came up with a quick-and-dirty solution: rather than use the vertice coordinates from the sculpt map directly, the viewer attempts to make a mathematical formula that matches and then it uses that formula to generate the shape (by distorting a prim). Needless to say, this is hardly the most efficient way to do it and for reasons I don't understand, even though Optimo tried to explain it to me, it is especially bad if the sculpt map is "oversampled" and contains excessive data.

---

It is also - quite counterintuitively - harder the more regular the shape is. With a well made and optimized sculpt map, the viewer doesn't usually have much problems handling an oddly shaped rock or rock pile, but it can struggle with regular, symmetric shapes such as staircases, windows and those prim linksets converted to sculpts only to save on the prim count.

I have a rather extreme example of that. I don't know if anybody remembers my big fern field. It's a very symemtric sculpt with 1024 identical but individual plants - just simple two-crossed-sheets plants but still quite realistic with the right texture. When I made it, I noticed it wasn't quite as low lag as I expected it to be. It's still by far the most effective way if anybody actually needs that many plants in a symmetric pattern but it was noticeably slower to load than my more practical 87 and 164 plants sculpts.

Then I took it to the extreme: a sculpt an even more symmetrical shape with even more plants (can't remember how many) and four sheets to each plant for more details. It is possibly the only sculpt map ever made to put every single vertice and triangle to good use. The viewer couldn't figure it out at all. No matter how long I waited, the sculpt never rendered, it was stuck in pre-processing. It would be interesting to see if a stronger computer than mine could handle it but I don't think I kept the map since it obviously wasn't useful for anything and I'm certainly not going to recreate it.

 

Edited June 26, 2018 by ChinRey

[OptimoMaximo]

20 hours ago, Luna Bliss said:

Is it only inefficient and so have a minor contribution to lag, as you say Optimo, or would it really cause major lag as you say, ChinRey?

It is just a resource waste, since the color on each pixel is what positions one vertex on the final sculpt shape. It doesn't deliver any increased precision, it's actually the reverse: this may induce color degradation and a mis-location of vertices, resulting in a irregular and not smooth surface. Continuous attempts to recalculate the shape from a oversampled texture leads to shape update attempts that aren't necessary and that may cause lag

[OptimoMaximo]

18 hours ago, ChinRey said:

Needless to say, this is hardly the most efficient way to do it and for reasons I don't understand, even though Optimo tried to explain it to me, it is especially bad if the sculpt map is "oversampled" and contains excessive data.

I'll try again for everyone's benefit.

Sculpts in general are an attempt to use NURBS surfaces into SL. The problem is that a NURBS uses 1 single UV map that covers the whole UV space 0-1, which is what we're used to about textures in general, while the sculpt OBJECT inworld is a "converted" prim. Now, what happens in principle: 

1) Take the prim, made of multiple texture faces. Each of these faces is a mesh with boundaries' vertices that overlap the adjacent ones, unstitched, each of them with their own 0-1 UV to get a square texture (save a prim cube with firestorm's save to collada and bring that into a 3D software to see it)

2) rearrange all of these UVs in a specific pattern, governed by the "stitching type" rule to achieve the basic shape you want, so to cover a new 0-1 UV space (the sculpt map image), pretending that it is now a solid surface (and then someone exploited this behavior with the multi-texture sculpt trick...)

2_1) recalculate the UV/vertices to comply to the required subdivisions to get 4096 vertices 

3) rearrange the object's vertices accordingly to point 2/2_1

4) decode the colors from the sculpt map and move the corresponding vertices into place, including the overlapping ones. Colors should be encoded in RGB 0-255 and therefore only a selected range of colors is recognized as valid vertex locations (read further below)

5) precalculate the UVs/vertices for LoDs degradation (i don't know whether this steps happens earlier though)

Symptom of this inefficiency is that a so small texture takes a very short time to be downloaded, but the time we wait for them to be displayed on screen doesn't reflect this "efficiency" because of the prim system hacking that the viewer has to perform. Over-sampled sculpt maps make this process from point 4 more unreliable (object-shape-wise) and intense, because the system expects each UV point to be at the exact center of a pixel, 1 specific color, but it can't. It may find a pixel border (so what's the color here?) or a gradiented transition between two colors, which doesn't belong to the specified 0-255 color range.

Hopefully it makes more sense now as per why i personally think sculpts are a genius idea that shouldn't have been implemented in SL the way they are.

[ChinRey]

1 hour ago, OptimoMaximo said:

Hopefully it makes more sense

Not much, maybe a little.

But as a practical builder who has studied and experimented with how sculpts actually work in SL, I can confirm that the diagnosis fits the symptoms.

[ChinRey]

On 25.6.2018 at 5:36 PM, Luna Bliss said:

Is it only inefficient and so have a minor contribution to lag, as you say Optimo, or would it really cause major lag as you say, ChinRey?

I'm doing a quick test here now. I have a sculpt with a 1024x16 map. It takes seven seconds to load form cache and the fps I get with it in view fluctuates between 28.8 and 29.6.

Switching to a 512x8 version of the same map...

Six seconds to load - I had actually expected more difference but add that extra second to dozens of sculpts and it becomes a serious problem.

But fps varies between 32.0 and 33.5. That surprises me. I didn't expect oversampling to affect frame rate, only load time.

Testing a few other pairs of optimized and oversampled versions of the same sculpt map gives similar results.

There is hardly any difference between cached and uncached maps. That indicates that download time is all but insignificant, it's all about the processing.

This is not a scientific test of course but it should be a good indicator of the efect oversampled sculpt maps have.

Tests done in an empty sandbox on the beta grid, using the standard SL viewer and the sculpt maps are grass fields of different shapes.

---

Edit: It would have been interesting to compare these figures to how the same shape would have worked as a mesh but that's a bit too much. However, judging by a sculpt-vs-mesh test I did earlier and on SoaS, I would expect a mesh to give an fps about 0.5-1 higher than the optimized sculpt, load time would mainly depend on bandwidth and land impact (with proper LoD) would be about 10-20.

That is one answer to the original question btw. There are actually mesh grass fields on the market now. Some of them are only 1 LI but these suffer from poor ground coverage, horrendous LoD or - as often as not - both.

Edited June 26, 2018 by ChinRey

[Luna Bliss]

On 6/25/2018 at 1:09 PM, ChinRey said:

Yes and no.

Wow you and Optimo sure have a wealth of knowledge in this area. Did you work in game design as Optimo did?

It's a little difficult to parse what you've explained without reading a lot of background info, but I think I know better what to do. I'm wiping out any sculpts over 4096 on my 2 new sims, and checking for excessive triangles in both mesh and with sculpts. Decided to rezz non-phantom without the unphantom scripts going off. Still unsure about the mesh though (how much to incorporate into these new builds).

I've always been very careful with these full sims...using repeating textures with both sculpts and regular low-res textures, even tinting to give variety. And more recently using more mesh planes for plants that utilize alpha masking.