Sculpted prim level of detail changes.

Linden labs has been progressively lowering the sculpted prim level of detail to the point where they're basically becoming useless for any purpose beyond basic organic shapes. If you like the idea of sculpted furniture, sculpted fencing, sculpted stairs, PLEASE, PLEASE, PLEASE express your displeasure and vote for

http://jira.secondlife.com/browse/VWR-2291

The newest release of the RC viewer, Second Life 1.18.3 (5), has made this problem even worse.

Linden Labs is capitulating to sims like Luskwood, who have modelled giant structures out of hundreds of sculpty blobs, and then complain about huge frame rate drops. This doesn't seem to me like a prudent use of sculpties, and feels unfair that sculpty artists have to lose a good amount of the potential of sculpted prims in order to enable people to build entire sim-sized objects out of blobs.

If you stacked up 1000 torii on your sim, nobody would expect Linden Labs to change the torus level of detail across the whole grid to accomodate you. *You* would be responsible for your sim's atrocious framerate. I don't see why this should be any different for sculpted prims.

Thoughts?

Thanks for the heads up on this, Daniel. I completely agree with you. LOD on sculpties should be improved, not worsened. There is absolutely zero reason we can't have high detail sculpties and high frame rates at the same time, as long as people don't abuse.

Managing sculpties is just like managing textures, managing physics, or managing anything else in SL. Everything can be abused, and it's up to us as users to make sure we keep things reasonable.

If people were to flood a sims with hundreds of 1024x1024 textures, FPS would grind to a halt too, but you don't see LL trying somehow to shrink people's 1024's. The same logic should apply to sculpties. Just because a few people see fit to abuse the system by building a million+ polygon tree doesn't mean the rest of us who actually act responsibly should have our work degraded.

Please, everyone, vote for this. Keep our sculpties looking good.

I haven't got the new viewer myself. But if it's true that LOD has changed for the worse, then this is VERY dusturbing. I use sculpties prudently in my designs, but I need the LOD to get the job done. A lower LOD is unacceptable and indeed would make sculpties pretty useless.

I find it hard to believe that LL would do this on the basis of Luskwood's tree. Luskwood is an AV maker and kowtowing to one group in that way, in a fashion that reduces the quality of sculpties, would directly affect most of the other AV makers out there who do use sculpties. I'm pretty certain that LL would have considered that beforehand and there must be other reasons for the LOD changes as well.

Jeff of course you're probably right and I don't mean to single out Luskwood except for the fact that it seems the most particularly egregious example.

As Qarl Linden said in the JIRA entry, "something has to give"; and I think that something is designers and builders have to give a flying hoot and realize that sculpties are not exactly the best thing to build 200m tall objects out of. The corresonding perfomance issues should be their responsiblity.

This in indeed an important issue. However, i should point out that in the latest RC viewer, if one turns their object detail slider all the way up, theres no visible difference between the RC viewer and the standard viewer.

The tree is just one example. You're right that it wouldn't make sense for any decisions to be made just on that. I don't think anyone's trying to say that it's all about the tree.

However, since the tree is a prime example of how abuse of sculpties has a huge impact, it does make sense to talk about it. I'm sure there are lots of other examples across the grid with just as much abuse.

Qarl's wording was "there are a LOT of old video cards out there - and people are starting to complain about sculptie lag. it's gotten to the point where something has to give."

I have no doubt that a lot of these "complaints about sculptie lag" stem from people in areas where sculpties are being abused in much the same manner that that tree is abusive. Again, no disrespect intended to the creator(s) of the tree.

I also think that sculpties are simply a convenient scapegoat since they're relatively new. People used to complain about bling scripts and hoochie hair and all sorts of things. Now it happens to be sculpties.

The difference now is that for whatever reason, LL seems to think they can silence the complaints if they nurf sculpty LOD far enough. Trust me; when people stop singling out the sculpties as the reason for poor performance in SL, they'll pick something else. The truth is everything adds up and we all have to do our part as content creators to balance visual quality with performance. LL absolutely should NOT be trying to force a technical solution down the throat of what is essentially a social problem.

There's also the question of whether it is sculptie lag or whether it is texture lag. There's no denying that sculpties tend to encourage more unique textures. Be interesting to hear whether the lower LOD actually made a difference.

I was glad to hear Qarl thinks a 4 x 4 face LOD is too low though. 8 x 8 is a more sensible minimum.

Yes, this was the wrong technical decision on the Lindens' part. I hope anybody who reads this (be it builder or consumer) and cares about improving SL takes the time to vote on the issue. Again, the link is

http://jira.secondlife.com/browse/VWR-2291

Thanks for bringing this to our attention, Daniel.

You can get around the LOD limits for sculpties, with some intelligent design. I've done it and it works well. I'm having few to no issues with LOD, because I keep it in my mind when making my designs. I test my designs to be sure I have taken care of the issue. I really don't see appreciable LOD issues with the last version of the RC client, unless the mesh was maximising its vertices at full LOD. I get around this problem a lot by designing meshes from a 16x16 patch of polygons, then using subdivision up one level to know how it will look in 32x32.

The second release of the RC client resolved too aggressive LOD issues. If you havent used it since the first version, I recommend trying it again.

What I will really like is normal mapping. That will allow us to use very simple geometry and let the textures drive the detail. I'm already readying myself for the day in textures I create for sculpties now.

What we really need is to have sculpties of various resolutions, rather than just one high resoltion base mesh and an overly aggressive LOD routine. Sculpties should come in different base densities, like 128, 256, 512, and 1024.

Hypatia, I'm familiar with the 16x16 method. I wrote a tutorial on it. It helps, but the eventual collapse to 8x8 will ruin any model. The 32x32 mesh falls off so fast that its basically pointless. I second Chip's suggestion; I'd love a choice between a 32, 16, and an 8x8 mesh, with reasonable LOD settings for each, instead of trying to stuff all sculpties into a "one LOD strategy fits all" mold.

I'm really confused, because this is pretty much the same issue as we had over the prim LOD a while back. It was initially too aggressive as well, but now its better. They've changed sculpties to match it. I'm really having very few issues and I'm very familiar with the need to keep the geometry as spartan as possible.

Actually, when you look at other games, you will see they use really basic meshes, usually they have far fewer vertices than regular prims for things such as walls. But they get their amazing detail due to the textures. Normal mapping has really upped the bar in other game engines.

Chip, with all due respect, texture size is utterly unrelated to mesh size. Sculpties maintain the same size mesh even if you make your textures larger. (I hear that it can go down with a smaller texture - but LL doesn't recommend even using smaller than a 64x64). A larger texture just gives you more pixels to average vertices from, but its important to bear in mind even a terrain in SL is only 256x256. But I'm with you on aspect sculpties, I could really use them right now, actually... often I could use those vertices more in one direction than another. (my lamp post is being a semi nemesis at the moment)

I've been testing the collapse to 8x8 and at the distance in which it collapses, its not really a visual issue anymore in most models. There's usually way more stuff in front of it, you cant really see it at the distance in which it collapses.

I think we're using very different modelling methods. Nothing wrong with wings... but I've moved on to what I feel is a better method by now for sculptie creation from polygonal objects. I bake my textures off a subdivided mesh. So my mesh at 16x16 is not that when I bake from it. It's 32x32. (sometimes its even higher)

I also model with topology in mind - I don't waste a single vertex on areas that are hidden from view. That means I often just use a plane or a cylinder, and a torus when I need that hole in the middle. I rarely use a sphere anymore unless I am really making something spherical.

I use Carrara Pro for baking textures, but you could as well use Blender, Modo works for some too, its better for organics, still working out the kinks in the Modo methods (has some trouble with nonorganic sculpts, I fall back to Carrara in such times). Modo is also brilliant for unwrapping UVs in exactly the way SL likes them (using UV Peeler) So if I have accidently borked the uvmap on a particular object, no problem. Just peel it off again.

I find Carrara gives me a whole lot of flexibility though with the shader method I've written my tutorial about. I do my modelling in a mixmash of Zbrush, Silo, and Modo. (I owned Zbrush and Silo before - but I'm migrating more and more to using Modo, only got it a month ago)

In many ways my subd method is similar to a nurbs method in general output, but I can adjust for things like creasing an edge where I need it for non-organic work, and still be able to bake from those smooth surfaces where they need to remain that way, plus I have a better feeling for how something will look at various levels of LOD. This allows me to better target my output for SL.

Hypatia, I'm not talking about texture size, I'm talking about polygon count. Right now we only have a single base mesh for sculpties which has 1024 polygons and SL uses LOD to reduce them. It isn't effective and it creates meshes that usually have far more polygons than they need. It also takes control away from us as to how the detail is distributed. What I want a different resolution base meshes in terms of polygon count. I have yet to build a single sculpty object that needed 1024 polygons. It's overkill and it's inefficient. If I can define a shape with 256 polygons I'd prefer to use a 256 polygon mesh and have me decide how those are distributed, not an LOD algorithm.

I've built things that have needed all those polygons. A 32x32 mesh is far too small for accurate display of terrain maps inworld, for example. Terrains are 256x256 in size. I've been better able to approximate a terrain mesh with four sculpties (a compromise) but if you truly wanted to be accurate to a terrain, you need 8 of them.

Actually I would truly like to see something like the sculpty technique applied to how terrains are deformed in world. Probably will never happen but we'd have a lot more ability to design natural formations than with the current method of a heightfield.

All games have LOD of some sort. Newer games actually use far less polygons, true... and make up for the detail in normal mapping. That would be ideal in my world, but of course people with older video cards may have trouble.

That's why I'd like to have a selection of different resolution sculpties to work with, and just pick the resolution most suitable for the task. One of the primary reasons for this is that when I'm building a part that would be prefectly fine with only 256 or 512 polygons, it's incredibly inefficient to have to deal with placing all those extra vertices. I could model what I need more efficiently without having to resort to subdivision tricks.

I'm with Omei and Chip on the ability to use different sculptie sizes. One obvious example is exhaust pipes for bikes. There I don't want the section to be less than a ring of 8 vertices, but that's also acceptable as a maximum. But lengthwise, I need at least 16 vertices. So being able to upload a 16 x 8 sculptie and get a sculptie with that topology would be great. Even having the 16 reduce to 8 for LOD would be acceptable (at sensible switching distances).

At highest LOD I'd have to use eight of the 16 x 8 sculpties to get the same triangle count as a single 32 x 32. It makes a lot of sense to allow this as it's pretty simple to implement, just means basing vertice max count off the texture size rather than hard coding to 32.

Just because you know I'm a stickler for detail, that's 1024 vertices, not 1024 polygons. The poly count on a sculpty is actually 1922. (32x32 vertices is 31x31 quads, which is 62x31 tris)

Anyway, I like your idea, Chip. Allowing variable mesh size would go a long way. I've got no shortage of sculpties that don't need the full 1024 vertices. Of course, I've got others that I wish could have MORE vertices, but I can live without them.

Another thing that would be of tremendous benefit would be non-square maps. Lots of vertices are wasted now by the fact that everything is square. If we could use configurations like 16x64 or 8x128 instead of always the perfect 32x32, we could get a lot more bang for the buck on lots of different types of shapes.

You're absoltely correct. I don't know why I keep switching that in my head. Probably because I'm used to thinking in terms of polygon count rather than number of vertics.

And yeah, I completely agree about non-square maps. And not just non-square. I'd like to see several different topologies. Or at least the addition of a sculpty plane. That would be so much easier to work with than a spherical topology and would be perfect for many applications where trying to wrangle a sphere into the proper shape and deal with the poles results in much wasted time and lost hair.

Sculpty planes do exist, as do two other non-sphere forms (torus and cylinder). They're just not official yet. I wouldn't rely too heavily on them yet, as I think Qarl's still ironing out some tesselation problems, but if you want to play with them you can. Just be prepared that anything you do with them now might break later.

If you want to play with them, drop this script into a prim:

default
{
state_entry()
{
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_PLANE, "sculpt map uuid", PRIM_SCULPT_TYPE_SPHERE]);
llRemoveInventory(llGetScriptName());
}
}

To use the torus or cylinder, change PRIM_SCULPT_TYPE_PLANE to PRIM_SCULPT_TYPE_TORUS, or PRIM_SCULPT_TYPE_CYLINDER

I don't use spheres that much for a while... my favourites are the plane and the cylinder I also make regular use of the torus.

Modelling with your topology in mind can make for a better sculptie. I mentioned that in a previous posting. In regards to what Chosen has said, I don't think Qarl is ironing tesselation problems with them now, I attend his office hours regularly and as far as I know, the topologies are finished work now. If someone can refer me to where he says they're not finished, I'd appreciate it. The user interface is what hasn't been finished yet AFAIK. You have to set it via script and UUID.

Aspect sculpties were mentioned as something LL wants to implement though, by Qarl. I really could use them _right_now_

I don't see the subdivision modelling method as being hard. I find it absolutely ideal as subd modelling is what I am good at, and Qarl concurred about my workflow being a good one. So I'll just keep on at it as I usually do. Results are good for me doing it that way.

Chosen, thanks! I thought I'd heard something about that a while back but then couldn't find any info about it when I looked and I've been out of the loop for a while.

Hypatia, agreed about subD modeling. It makes for a good workflow, and my complaint isn't that it's hard (it's been my primary modeling method for years and years). It's just superfluous when the undivided mesh is actually what I want, and on the SL end, the additional resolution is just a lot of unnecessary information.

Not really. I do it for a reason... and this is pretty much standard in the games industry.

I deliberately model from very low res geometry, as few vertices as possible for the type of item I'm creating. (I'm a zbrush user for this type of thing) In zbrush, you can then take it up to astronomical levels, and sculpt in the relief details you wish your sculpty to have. For items with a lot of texture relief (and this is becoming more and more stuff I'm working on these days), this is an ideal way to work. Dump to normal map, apply to low res geometry with materials, then bake out textures. Which end up being far more detailed and fitting exactly to the lower res object.

When I bake out for the sculpty itself, I up the resolution to approximately where the sculpty will be in world, but usually my original mesh is even lower than that. I like to keep the cage to just as many vertices as I need, gives me more control. Its how I work all the time, before I even started with SL.

Qarl has mentioned he wanted to bring normal mapping in world one day... so I can see a possible day in the future where I may be able to apply those normal maps to my geometry. And if not... I can surely reuse the asset again in another game engine or 3d project.

That's very similar to the way I do sculpties. I build a high resolution model with as many parts and whatever modeling methods are most suitable, then I create a low poly shell (the sculpt object) around it and use Max's projection modifier to bake texture maps from the detailed model. I'd love to see SL incorporate normal maps some day soon.