Sculpted prim level of detail changes.

I love sculpties, but I heard they cause lag because of the high resolution textures perhaps if the resolution of the textures was less it would cause less lag ? Wouldnt that be a good thing ? Is that what you are referring to ? I dont understand what are the lindens doing ? Also I noticed on my older computer they never seem to rezz especially if there are a lot of them in one place ,they just continue to stay round balls . Being on the new computer I can see them perfectly but I wonder how buildings made of sculpties would look to someone on an older computer? It may be too much for them.


Elinah

Great information Hypatia and everyone...

Following this thread with some interest as sculpties have been my bread and butter the last few months.

I use alot of planes too and am typically quite happy with the results, there are more vertices to work with when only considering one visible side of the object. Also no distortion along seams etc, which make planes very suitable for detail work.

I have found that proper spacing and alignment of vertices minimizes LOD issues, even with the recent aggressive RC viewer only a few of my sculpties showed significant popping.


-whyroc

The word "texture" can be a little deceiving when it comes to sculpties. The sculpt map is often referred to as a "sculpt texture", a phrase I really wish people (Lindens included) would stop using. It would be a lot less confusing to use "texture" only to refer to color/transparency imagery, and to use "map" for the sculpt geometry data sheet. It's probably unlikely that that change will happen though, so just do your best to try to figure out from the context what people mean by each instance of the word "texture".

What people probably mean when they say "resolution" in regard to sculpties is the amount of verteces and/or polygons in the sculpt surface mesh. With the exception of avatars, sculpties and toruses are the most vertex-heavy objects in SL. Allowing sculpties to use less verteces would indeed lessen the graphics load, and that's what much of this discussion is about.

If people are indeed saying that a large texture applied to a sculpty somehow causes the texture to be more laggy than if it were applied to something else, that's not true, strictly speaking. A 1024x1024 will always use precisely 3MB or precisely 4MB (depending on bit depth) of video memory, no matter what kind of surface it's on.

However, since sculpties use a lot more polygons than most regular prims, they eat up a lot more graphics horse power inherently. So, taking an already laggy item and applying a large texture to it adds just that much more to the more load.

I would sum it up like this:

Sculpty + large texture = big load
Sculpty + small texture = medium load
Regular prim + large texture = medium load
Regular prim + small texture = small load

Make sense?


No one can argue that "less lag" would not be a good thing. However, there are lots of ways to acheive "less lag" and the issue here is whether or not LL is making the right move by forcibly degrading the visual advantage of sculpties. My personal feeling is that they're not.

I believe education would be a much better solution. Teach people how to use sculpties responsibly. If they choose not to listen, that's their problem, but sooner or later, natural forces will persuade them to make better decisions. Those who are causing tons of lag by abusing sculpties will find themselves with less visitors. If they want more visitors, they'll need to learn how to do things with less lag. If they don't learn, they'll go away. Natural selection always works, even in an artificial world.


Turn up your max bandwidth in your SL preferences on that machine. What's happening is that you're not downloading the sculpt maps fast enough. If the machine has a poor network card, it might be stuck the way it is, but chances are it can be improved by tweaking the settings.


Making a whole building out of sculpties would be irresponsible, in the same way that the tree we've been discussing in this thread could be described as irresponsible. Sculpties were never meant to replace regular prims. They should be used sparingly and strategically, just like heavy scripts, large textures, and any other resource-intensive asset you could think of. Use them, don't abuse them, and everything will be fine.

Lindens, I hope you're listening. As I said on the Jira thread, give the abusers a chance to learn how to be more responsible before nurfing everyone else's ability to enjoy sculpties at full visual quality.

Some people are using textures that are too big for sculpties nowadays, tis true. Back before lossless compression, people often uploaded maps that were 256 or higher to average out compression errors, along with tricks that often made them horrifically slow to load. No reason for this anymore with the release candidate client, which can upload up to 128 compression free.

as a side note, I would not recommend building an entire structure from sculpties. A house really should be built primarly from regular prims, and use the occasional sculpties as accents (stairs, door handles, etc) Anyone who models a house entirely from sculpted prims, I would wonder about as a builder. Sculpties are not the be all end all of modelling - we still need the regular prims for things that work better with them, and that certainly still includes buildings.

Firstly, I really like the perspective presented in Hypatia Callisto's comment on the JIRA issue (http://jira.secondlife.com/browse/VWR-2291). Sculpties do require a little higher degree of skill to form effectively. Much attention should be paid to the vertices, in particular those few that remain as level of detail drops.


But actually, we SHOULD have 32×32 quads, which is why Qarl is fixing it to be able to carry 33 vertices (at least, where useful; I believe a torus with 32×32 quads only needs 32×32 vertices). Unfortunately this leads to a sort of debate over inefficiency: in the JIRA comments, Domino Marama complains of this "other performance basher", while Seifert Surface proceeds right afterward simply to explain why we need that last vertex. (While Domino does have a point that we could sorta do without it, I agree with Seifert's claim that to do so is inelegant in effect.)

However, they were designed to have roughly the SAME polygon count as the most polygon-heavy regular prim that can be made. So my opinion on all of this is that we should simply make sure that at all distances, we show hardly if any more polygons than the comparable poly-heaviest prim (when set to the same scale). By this we maintain the same system of polygon-responsible control we had, so that – at least this much is sure – sculpties don't carry any truly uncommon capacity for abuse. Likewise if the current changes are taking sculpties well below this level (OK so I haven't checked…), then I agree that we could turn it up a bit.

After assuring that, I think there should be a pair of max-detail settings – one X, one Y – for each sculpted prim. This would handle 2 issues, as not only could you set your simpler sculpties to, say, 4×16, but you could set your long, winding sculpties to something such as 16×64 (just as long as you always take one dimension down as many steps as you take the other up).

Could that make a good JIRA issue?
(I can just see the setting reading something like "Quadrilaterals" (okay maybe that's an unnecessarily big word, but there'd be the space for it ) with "X" and "Y" below it, and drop-down menus – or whatever works – for each for selecting 4, 8, 16, 32, or 64, maybe 128 and even 256 too. …But that's just an example.)

Trust me. I'm right on this one. It's the bug that's inelegant not the fixed version I posted.

Remember I've written a sculptie implementation in Python for the Blender scripts. I'm speaking from experience.

I'm talking about changing two lines of code that will improve sculptie performance by about 5% and give the correct UV mapping instead of the silly cram an extra row on the end thing.

Anyone worried about this affecting LODs should take a look at the picture attached. This shows a before and after picture of the effect the fix has on importing a plane in Blender.

Chosen, only because I know you are a stickler for detail, I want to question that. Looking at the SL client code, I see the sculpt() function in LLVolume.cpp creating a 33x33 vertex mesh for any sculpty at the highest LOD. That is 32x32 rectangular faces or a total of 2048 triangles. Why do you believe otherwise?

That's interesting, Omei. What you're seeing is the way things are supposed to be. Toruses, for example, have 32x32 quads, and sculpties were meant to be the same.

However, my understanding was the way it's supposed to be is not actually the way it is, and that sculpties only have 31x31 quads. The fact that the maps can only be uploaded in power-of-two sizes, just like all other textures, is what I think is the limiting factor. What do you do with the 33rd row of vertexes when the map can only tell you where to put the first 32?

If things have changed, and we are indeed now using 1024-quad sculpties, that would be good news (although it would of course make the polygon load even higher for all those poor under-powered graphics cards out there). I'll have to ask Qarl for some clarification on this.

EDIT: I just went ahead and counted in wireframe mode, and you are absolutely correct, Omei. Sculpties do indeed have 32x32 quads. Now I definitely need to ask Qarl some questions.

*edit, please disgrard the following as innaccurate, provided only for contextual benefit*
A sculpt map specifies 33x33 unique vertices in plane stitching mode!
---------------------------
Chosen, its true that the sculpt map only specifies 32x32 vertices. I think there's some confusion here because its is logical that 1024 vertices (ignoring poles for the moment) is all we'll ever get from a sculpt map. So where is the 33rd column of vertices? They are not unique vertices, they are simply the first column again, and faces wrap around depending on your selected mapping mode.

So although a sculpt map contains 32x32 vertices, describing 31x31 faces, depending on what mapping mode you have chosen, SL can generate a mesh of 32x32 faces. Whether you consider that 33x33 vertices or 32x32 vertices is just a rendering detail. We have 32x32 faces. Even in plane mode, where no wrapping takes place, SL will still gobble up a row and column of your texture map as if it were texturing 32x32 faces.

Ok, that makes perfect sense. I'm confused how it works out for planes though. I see that on a uniform plane, the width of the 32nd row of quads appears to be half that of all the other rows. It looks like the 32nd row is just tacked onto the end, the vertex coordinates kind of guessed at as maybe an average added to the others. Now I definitely need to talk to Qarl. I'd like to know how this really works.

I've got an awful lot of posts to correct now in which I had said that sculpties had 1922 polygons. Oops. Thanks for pointing it out, guys.

-- snipped for innaccuracy --

My understanding is the way it works is that there are 33 vertices, with the 33rd coming from the last row. So on a 64 x 64 sculptie map it's 0, 2, 4 ... 62, 63

If the sculptie has wrapping in that direction, the actual value at the 63rd pixel is ignored and the vertice is set to the position stored in pixel 0.

If it's a pole then all vertices on that row are read from (sculptie_width / 2), so pixel 32 on either the first or last row depending which pole it is.

This gives a UV texturing map which always has an even number of faces, the UV map is generated seperately so has 33 points equally spaced from the beginning to end of the texture.

This behaviour is why there is currently a recommended minimum sculptie map size of 64 x 64, as at 32 x 32, the last row reads the same vertex position as the 32nd vertice. This leaves 1/32th on two edges of the texturing map unused.

Domino is correct. Doing some experimenting I have made a plane of 33x33 *unique* vertices. The extra rows and columns are sampled from the top and right edge, respectively.

If you'd like to peep at it in-world,

llSetPrimitiveParams( [PRIM_TYPE, PRIM_TYPE_SCULPT, "d99d09c4-27fd-5907-7f4e-75250daca706", PRIM_SCULPT_TYPE_PLANE ] )

I should point out this is the behaviour I described as buggy above. Basically it's a deliberate thing introduced to make texture mapping easier, so perhaps it was a little strong to call it a bug. I still prefer the alternative way of fixing this which is by correcting the texturing UV map to 31 or 32 faces depending on whether there is wrapping or not. Hopefully my suggestions on jira about implementing both behaviours so we can use 32 x 32 and smaller maps without losing that 1/32nd of the texture will be popular enough to get done.

I hope to redo the "Technical Explanation" section of the Wiki with some of this information, it seems woefully outdated now

No, it just means that it would need to support upload of odd sized sculpties, and that some sizes wouldn't give whole numbers of pixels per face. The sculptie UV map would behave as it does now when you upload a 32 x 32 sculptie map. The extra row would either be removed (zero size face), or set the same as row 0 with wrapping.

The difference is in the texturing UV map. Without wrapping there are 31 faces, with wrapping 32 faces. Well actually sculptie_width (-1 for no wrap) faces. So the code for this would need to change for sculpties sized 32 x 32 and smaller.

So for example a 9 x 9 sculptie map with no wrapping would give 8 horizontal faces with pixel perfect texturing. An 8 x 8 with wrapping would also give 8 horizontal faces with pixel perfect texturing, however 8 x 8 with no wrapping only gives 7 faces, so the edges would fall on subpixels rather than nicely aligned.

I think this is something that could be used to creative advantage and not worth the hack of using a 64 x 64 map to fix, particularly when it's a barrier to managing our own face count during the design process.