Everything looks much better on the previous version. Also I have too much aliasing effects on most screens, compared logging in on exactly the same locations (coordinates) with the RC and the previous stable version.

Text is better readable in the RC (ex. in the scripting window), graphics and the world looks much better in the stable.

Geforce 7600 GS, 256MB
Windows XP SP2

here's what changed in the code. in the past sculpties had the following resolutions depending on screen size:

32x32, 16x16, 16x16, 8x8.

this was recently adjusted in the RC viewer to:

32x32, 16x16, 8x8, 4x4.

the reason for the change was that several of the sculptie-heavy sims were showing poor frame-rate performance.

I hate to say it but this change really sucks. I remember reading your blog and something about you trying to raise the bar on visual quality in sl.... well this is going backwards :/

My partner makes hair, and all of it displays bald spots once you zoom out a little now

ouch.

ok, here's the thing: 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.

that said, this is an RC viewer - it's meant to be a test. for the next RC, we've bumped the values back up: particularly the 4x4 level was troublesome. a four sided object looks "square", not "round". add a couple verts and it flips back. i haven't yet had a chance to test your hat/shoes, i will soon and send you a screenshot.

(this is probably not much consolation: but you can get the resolution back by adjusting the "object detail" slider in graphics preferences.)

K.

I have tried to go to a few sculpt heavy sims too and don't see much of a difference in my frame rates. I think this is an unnecessary optimisation.

It "breaks" content in a way. When I created my sculpties, over those very frustrating months of hair pulling, experimentation and constant tweaking, I took the different LODs into account, pushing and pulling vertices to get it looking acceptable at different distances. This change throws away all my hard work. I really spent an insane amount of time getting this stuff to look the way it does (and I'm sure Im not the only one).

Please dont keep changing the goal posts. I have had this happen to other content in the past too (several times with cylinder cuts etc) and rebuilt lots of my items several times until I finally gave up.

My main problem is that I sell this stuff, and when it changes in the next client version I start getting IMs that my items are "broken" or that Im ripping someone off because my build quality is bad.

I propose one solution would be to provide a 16x16 sculpt that would not LOD at all, it wouldas dropping to 8x8 or 4x4 is basically useless to attempt as it no longer looks anything like what it should be. Perhaps you should be able to specify a replacement primitive that takes its place. Or if thats impractical, just don't show it at all. Sometimes seeing nothing is better than seeing a mangled blob. The current method to fight LOD in a sculpt that needs to keep its shape like a staircase involves modelling at 16x16 and uploading at 128x128, this is also a waste of bandwidth and triangle counts just to fight LOD effects.

The sculpties are coming. Triangle counts are going to skyrocket. Pandoras box is open. Oh dear!

In Luskwood here we've recently joined the ranks of the "sculptie heavy sims" with our 'remodeling'. And regulars with older video cards (and even myself with 'only' a 7900GTX) have noticed the difference - many folks complaining of "sculptie lag".

The performance/client framerate difference between 1.18.1.x/1.18.2.x and RC 1.18.3.2 in this situation is marked and dramatic. Folks who were getting 0.7 fps were suddenly getting 5-6; systems that were getting 10 fps were suddenly getting 17-18.

Now, on this same note, we're also avatar designers and sculpted prim detail is of utmost important to us as well – I've been one of the loudest proponents for a high maximum LOD in the past.

However, a few suggestions that I think would be a good compromise:

1) Optioning sculptie LOD detail and basing it on distance.
-Basically the introduction of a sculpted prim LOD slider. It could have several settings i.e., (32x32 foreground, 16x16 distant) / (16x16 foreground, 8x8 distant) / (8x8 foreground, 4x4 distant).

2) This i think would be the most important: The ability to create 8x8 sculpties from the get-go for "general shapes" that don't NEED high detail. In other words, some sculpties, if uploaded as 8x8 would remain at 8x8 at all times. This could be used for organic and structural shapes that don't need that accuracy, conserving the triangle count so that 32x32 shapes could be used where appropriate and 8x8 shapes could be used where appropriate.

#2 i think really would help. Our new tree could easily have been composed of 8x8 sculpties, but the only option is 32x32 detail. For some of our new avatars coming out, I definitely no doubt would want to use the full 32x32 detail.

I just think that adding such options, if possible, might mitigate a lot of the 'increase visual quality' vs 'what-about-the-folks-with-old-cards' dilemmas.

In their initial inception it seems like sculpties were targeted primarily at 'detail' objects and things... stuff like cool lamps, statues, and the like... and for those, these relatively high triangle mesh defaults are fine, absolutely...

It has become a more and more common practice however, to use sculpties as actual 'building' blocks, when other shapes simply will not work, specifically in things like complex organic builds, designing really nice one prim rocks, trees, using them as 'beams' in naturally curved ways in houses... etc...

In that second use, in all honesty, we do not need 32x32 sculpts, heck, we don't even necessarily need 16x16.... all we want are decently shapable prims for basic building materials and 8x8 would be more than sufficient. and would push literally 1/16th the amount of triangle load per prim on the clients... that would be a HUGE savings, and really open up the use of these 'reduced' sculptie prims as major construction building blocks for pretty much all organic builds.

(it would also save texture bandwidth as those reduced sculpts could be easily oversampled from 16x16 or 32x32 textures)

Heck, we have a large sculpt tree now in lusk, and with 8x8 sculpts, it would literally not look even the tiniest bit differnt to people, but would use less triangles than the older tree it even replaced. We would have the benefits of the sculpt shapes, but they would come with a frame rate boost no a frame rate hit.

Maybe you can meet me in game so we can compare.

I noticed that if I reduce my sl client window size to roughly 1024x768, by the time the lowest LOD is used, the avatar is too small to even notice this stuff.

What screen resolution are you testing with?

That said, an 8x8 mesh size would certainly make such a 'additive blob' modelling method more reasonable for huge builds.

If its Linden Labs' intention to support people who model their entire sim out of sculpties instead of those who are making carefully constructed, highly detailed objects for occasional placement throughout a sim, then geometric artists like Aminom Marvin and myself might as well find a new hobby.

In other words, this isn't a problem with the system; it's a case of ill-considered use of available resources. Managing sculpties is just like managing anything else in SL. The onus is on the user to keep things reasonable.

If I were to abuse the system in another, more commonly understood way, like say, if I were to flood a sim with hundreds of 1024x1024 textures, I'm pretty sure everyone would agree it would be my fault, not the system's fault, that FPS in the area would be glacial. Sooner or later someone would need to come along and explain to me what I had done wrong to create the situation, and how to resolve it by using less textures or smaller textures or both. No one would try to claim that LL should somehow step in and forcibly transform my huge textures into smaller ones.

That same exact logic should absolutely apply to sculpties. With all due respect to the creator(s) of that tree, as Daniel said, it's an extreme example and it's not the type of thing that any decisions should be based on. A few tweaks to the building technique, and it would be a non-issue.

The solution here needs to be social, not technical. Content creators need to be educated about the impact of their decisions. This sort of anti-lag education has happened with texturing, with scripting, with physics, etc. As SL has matured, people have learned what works and what doesn't with all of those things. Time needs to be given for the same to happen with sculpties. I'm sure that given the choice between a 500 prim tree that lags, and a 150 prim alternative that looks just as good (or better) but doesn't lag, every single person would opt for the 150 prim version. People just need to be educated on how to to build the replacement.

So, give it a little time for people to learn. Don't hit the panic button and kill the LOD just yet. Make sense?

Before flexprims, the classic example was "torus-hair". Curly hair made of hundreds of torus prims twisted out to 4 revolutions was known as a classic source of lag because of the ridiculously high amount of triangles such hair required to render.

With the advent of flexprims, we now see content creators making hair, skirts, and what not out of hundreds of flexprims, which results in all flexprims in view animating at about 1 frame per second. It's hideous, and ruins things for everyone.

Yet another example of this kind of excess is local lighting. People love that local lighting became available to the masses a year or two ago, and so they started using lights everywhere. Many people wander around with a 20m-radius light attached to their avatar, blanketing their surroundings. Few people realize that the client is currently limited to rendering at most the 6 nearest lights, so many content creators fill their creations with 6 or more lights. Just one avatar attachment with 6 lights causes someone's avatar to become a local black hole, totally drowning out carefully, sparsely placed lights in a build.

In each of the cases above, and now with sculpt prims as well, people jump on the new content creation options they've been given without regard for the performance impact their creations will have. This is made worse by the fact that more and more powerful graphics cards are coming available; many content creators seem not to be aware that just because THEIR system can handle rendering a ridiculously high-triangle scene at 15fps doesn't mean the average visitor's system won't grind to a halt.

In short, there are content creators in SL who aren't playing nicely and considering how their creations will impact performance. Because the average content creator in SL isn't very tech-savvy, they likely aren't even aware of the performance tradeoffs involved in various building choices and only build with visual appearance in mind. LL then takes the blame for the lag resulting from willy-nilly inefficient building. Everyone immediately blames LL for producing a "laggy horribly-programmed client", when, in fact, SL is amazingly efficient considering what most content creators are asking it to do.

So LL, in turn, tries to optimize the viewer yet more to salvage at least some kind of reasonable framerate. Features like sculpties get nerfed, and those of us who use them WISELY, SPARINGLY, and TASTEFULLY find that we're no longer able to use them at all because they've been optimized into uselessness. In short, high-sculpt builds are ruining it for the rest of us[1] that take great care about the performance impact of our builds.

I see two solutions to this:

1. Make it so that it's impossible for builds that horribly abuse features like sculpties (such as the nearly 1-million triangle Lusk Tree mentioned above) to actually lag systems. Assume that content creators have no discipline and cannot see that some types of content should be used sparingly. Perhaps features like sculpties shouldn't be introduced at all, because people WILL abuse them.

2. Don't worry about it. Make reasonable attempts to retain efficiency through the LOD system, but don't attempt to cater to outliers. It will probably ALWAYS be possible to design a build in SL that makes gratuitous use of every available resource-intensive content option we've been given to create a build that grinds every single visitor's viewer to a halt. Attempting to limit content creation/rendering in such a manner as to always preserve framerate will likely result in EVERYTHING in SL looking hideous and the above-described content creators working ever harder to ensure that their creations look good no matter the cost. Remember the way people used to twist cylinders to ensure that they didn't LOD?

I vote for #2 above. It's ridiculous to punish the rest of us because certain content creators have no restraint. It is absolutely possible to create a build in SL that looks beautiful and immersive and yet still loads and renders efficiently.

One more possible solution comes to mind:

3. Only take drastic LOD steps if framerate dips too low. In other words, be conservative about LOD, but if the client is faced with a scene that contains 500 sculpties, something's got to give. When the framerate drops below a certain threshold, start trying ever harder to cull triangles in the scene by dropping the LOD on ever-closer prims. Also drop the detail on flexprims and drop their animation rate in a similar manner. This way, the client won't "lag" as much, but builds in which SL client performance is not taken into consideration will look ugly to many viewers. This will send a clear signal to content creators: if you don't pay attention to performance, your build will look ugly. If you do, things will look fine. LOD is in your hands.

[1] For an example of a build where performance considerations are taken into account, please teleport to Suffugium. My group has built an immersive, detailed, celebrated build that tends to load and render fairly quickly for most viewers.

Your suggestion for 3. is intriguing. I've seen suggestions that sculpty detail should be a separate slider, but the problem with the slider approach is the majority of users won't ever touch it, so you end up having to model for the worst case. Something that automatically gave the best results dependent on framerate is a good idea, but at a certain point, I think you want to have a reasonable minimum detail level. There's no use reducing a build to a Dali painting just to go from horrible performance to just mildly awful performance ...

From personal experience - until giant sculpty builds - I've noticed the biggest hit to my framerate has been avatars with high prim attachments, elaborate prim boots, backpacks, prim hair and jewelry, chains all over made out of a billion torii. This might be ironic coming from someone who made a tutorial on making chains out of sculpties but I'd much rather LOD every avatar's useless, prim-heavy bling before the world around me. I don't care if that avatar with the giant furry ears with 800 piercings in each renders right. But of course if you're not a builder, you're going to scream bloody murder if your avatar doesn't look perfect. Most people are after all concerned with the look of their avatar first and foremost.

But it seems if we want to start improving the framerate for SL users, LL would have to limit the prim count of avatar attachments. An avatar gets 7,650 prims to wear by rough count and theoretically if all of those were torii one avatar could march around with 7.6 million triangles in view. With enough prim heavy avatars in one spot, it almost doesn't even matter what is in the background at all. The sim could be blank and you'll have terrible performance. So if you want to find SL's biggest performance drain, where should we look first? If the avatars prim counts are "untouchable", dont touch our sculpties either. Maybe we'll have a slide show, but at least each frame per seven seconds will look good.

"ok, here's the thing: 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."

Sculpties, implemented properly and used wisely, should decrease the total triangle count and increase performance for those people (for the same level of quality). Why might things be going in the opposite direction? I can think of two main reasons.

1) JPEG artifacts. This has forced people who purposely do their modeling at lower resolution to convert to 128x128 when they upload. It has also prevented people from replacing multiple legacy prims with a single sculpted prim.

2) Builders not knowing any better. Where's the Wiki and building forum discussions about the drawbacks of modeling at high resolution when you don't need it? There aren't any. And why is that? Well, until today, I hadn't been aware that we were approaching a crisis and "something had to give". As a sculpty tool builder, I can have a significant impact, first by simply spreading the word, but also by changing the default export options in Wings 3D to stop scaling everything up to 128x128. But it has to make sense first. (That is, the compression artifacts have to be removed, one way or another.)

"the reason for the change was that several of the sculptie-heavy sims were showing poor frame-rate performance."

If the builders of Lusk and other sculpty-heavy sims have the appropriate tools and knowledge, I think they can figure out how to solve their own problems, without LL crippling sculpties for the rest of us.

I have a thought. If I recall the code correctly, if someone manages to get a usable (i.e. unmangled by compression artifacts) 16x16 sculpty matrix into SL, the viewer will maintain that resolution, not expand it to 33x33. But if it is something like 17x17, it will rescale it to 32x32. I don't think that's actually a useful behavior. How about just keeping whatever resolution the bitmap comes in? For example, DanielFox recently posted a nifty sculpty of 4 separate and independent cubes from a single prim. He modeled that at 16x16 resolution, but 16x4 would have worked just as well. That would be a 16-fold reduction in triangles over what he actually used (assuming he doubled up all his vertices to get past the compression woes.) Is there any compelling technical reason for rescaling every sculpty bitmap to be square, or even an integer power of 2?

That's a good idea to reduce LOD and make sculpties even more useful. There is a good reason to stick to power of 2 sizes, though not for keeping them square. The ideal implementation of sculpties is as a GLSL displacement shader. However this puts even more emphasis on the sculptie maps being lossless and makes the map size even more significant.

http://www.ozone3d.net/tutorials/vertex_displacement_mapping.php

The other performance basher is the way the 33rd row is handled. This is supposed to be a fake row for texturing mapping purposes. In the current implementation it is generated from the pixels at width - 1. This is fine when the pixel count is equal or less than the number of vertices. But with a 64 x 64 map the 33rd vertices are read from 64 - 1 which is not the last row of the real model. This leads to people going above a 32 x 32 map just to get that one extra row. It should really be read from 64 - 2 and 128 - 4 etc so that the fake row duplicates existing vertice positions and is removed during a deduplication stage. The current implementation kinda encourages almost 50% redundancy in a 64 x 64 map to get that extra row. This becomes even more of a problem should someone do a client with a GLSL sculptie implementation as the sculptie maps will hit texture memory on the graphics card. So making 32 x 32 (or less) a reliable and preferred size seems like a very good idea from where I'm sitting.

The current system, with a last 33rd vertex, keeps the size of the object constant as the LOD changes, I'm not sure how you could achieve that with only 32 vertices, and have the changes in LOD be graceful.

I need 32x32 sculpties for close up detail, thank you very much. Not my fault you don't use a real 3d application. Keep yer paws off my geometry

that being said, I am not having huge LOD issues, but that's because I target my topology and design accordingly. The first RC client was pretty bad, but the second release, not so many problems for me. But this is likely due to the way I design my meshes. I use subdivision modelling and then texture bake my meshes (my tools are mainly a mixmash of Carrara Pro, Zbrush, Modo and Silo - I've recently moved to using Modo more and more, and I tell you, I dont think there is a 3d program more generally useful for SL than Modo is), not inworld tools nor nurbs in Maya. I dont make blobby things with sculpts - I have been doing 3d modelling for years, and I know how to build efficient mesh.

I plan a mesh and break it up to the number of sculpts I will need. I model at a middle LOD so I have a good idea even in modeller how things will look at 16x16 - which is the intermediate level of detail and how most things need to look at intermediate distance. I target my topology for the kind of object I am creating. If it requires a cylinder, I use one... if its a plane, torus, I use one, etc.

Follow this rule of thumb, use regular prims when they can suffice just as well, and you will do better with your sculpties.

"The ideal implementation of sculpties is as a GLSL displacement shader. However this puts even more emphasis on the sculptie maps being lossless and makes the map size even more significant."

I'm not even close to being an expert in OpenGL shaders. But don't OpenGL shaders have plenty of flexibility to handle non-power-of-2 sculpt maps? As a possible example, couldn't you use the GL_CLAMP wrap mode in a displacement mapping shader to render a non-power-of-2 sculpt map into a power-of-2 result, if you really wanted the power-of-2 result for the next step?

Since v2.1 yes, I've still got it in my head that it's a good rule of thumb to follow power of two rules. Though if someone did an optimised viewer for high end graphics cards, I guess it's a moot point.

Seifert said "The current system, with a last 33rd vertex, keeps the size of the object constant as the LOD changes, I'm not sure how you could achieve that with only 32 vertices, and have the changes in LOD be graceful."

The problem is that a 32 x 32 vertice mesh generated from a 32 x 32 image becomes a 33 x 33 vertice mesh when generated from a 64 x 64 image. The 33rd vertice should be the same as the 1st or the 32nd depending on if there is wrap or not. At lower lods this does add an extra vertice with no wrap, so the vert count for LODs would be 32 - 17 - 9 for a planar sculptie. With wrap the 17th & 9th would be the same as the first and removed during deduplication giving 32 - 16 - 8.

The current implementation is basically right as long as the max sculptie map texture size is 32 x 32.. It's when the max texture size is greater than the max LOD that it breaks down. Unfortunately everyone is working to broken sizes due to compression issues

"The extra vertice should be the same as the 1st or the 32nd depending on if there is wrap or not."

So with no wrap at lower LODs the extra 9th, 17th vertice is at the same position as the 32nd at the max LOD. As the 32nd doesn't exist in the model for lower LODs it doesn't get removed during the deduplication stage. So the extra vert gets promoted to a real one which maintains the shape. The UV map position for the extra vert is still width - 1 or you end up with jumpy textures during LOD changes, it's just the 3D position which should be read from the same pixel as the 32nd.

Once the compression issues are resolved, this would mean there is no benefit going from a 32 x 32 image to a higher one, so helps encourage smaller sizes. As it is possible to get an extra row of vertices by using a larger image with the current implementation people will abuse it IMHO. This means lots of 64 x 64 maps when 32 x 32 would have done. So I'm talking about reducing memory use by four by making people use the code as it's supposed to work rather than letting them exploit how it works

if (x == sculpt_width) // side stitching
{
// wrap?
if ((sculpt_type == LL_SCULPT_TYPE_SPHERE) ||
(sculpt_type == LL_SCULPT_TYPE_TORUS) ||
(sculpt_type == LL_SCULPT_TYPE_CYLINDER))
{ x = 0; }

else
{ x = sculpt_width - 1; }
}

--------------------------------------
I'm suggesting:

maxLOD = 32;
if (x == sculpt_width) // side stitching
{
// wrap?
if ((sculpt_type == LL_SCULPT_TYPE_SPHERE) ||
(sculpt_type == LL_SCULPT_TYPE_TORUS) ||
(sculpt_type == LL_SCULPT_TYPE_CYLINDER))
{ x = 0; } }

else
{
if ( sizeT > maxLOD )

else

}
}

Where sizeT is the sculptie image width set earlier.

x = (U32) ((F32)(t-1)/(sizeT-1) * (F32) sculpt_width)

is better than

x = sculpt_width - ( sizeT / maxLOD );

as it will recalculate the correct vert.

With the improved form it could just be switched out for the x - 1; and you have a routine that handles whatever you throw at it.

if (x == sculpt_width) // side stitching
{
// wrap?
if ((sculpt_type == LL_SCULPT_TYPE_SPHERE) ||
(sculpt_type == LL_SCULPT_TYPE_TORUS) ||
(sculpt_type == LL_SCULPT_TYPE_CYLINDER))
{
x = 0;
}

else
{
x = (U32) ((F32)(t-1)/(sizeT-1) * (F32) sculpt_width);
}
}

If my non- developer comments are not suited to this thread please tell me where i might engage on this subject and try to maintain the status quo in the next viewer.

1. Firstly i think we all agree that it is subjective..some need sculpties at high resolution others dont..but any one comment of not needing it is subjective. If for one need the highest quality sculpts available
2. I have been developing now with consultants since the inclusion of sculpts which amounts to 100's of hours of work, and our store is opening by this weekend, showcasing shoes in a way hardly seen in secondlife.
3. to suggest that a viewer might launch at the same time that would shatter our work and the resoluton of this effort is enough to discourage even the most motivated. It has cost time, money, energy, emotional output, and planning..all to make sl a progressive more interesting environment where clearly the future will be driven by visual, and sound as the two most important senses. Thus to suggest going backwards rather than forwards is just awful, as i believe everyone waits for better graphics and this is what will in-part drive the momentum of sl
4. So for me the only solution to be considered is education and better management. I have a savvy developer, but i dont have a best practices or a guideline as to what will ehnance performance, how many sculpts on one object? how many sculpts on a sim? what different meshes do to FPS? What is acceptable FPS?. Until those in the know compile nd make it available or a community thread creates a basic guideline it is hard for many ( as noted above) to know what to do.

for Linden to become a revisionist thinker would be awful in its implication for SL. Sculpts were the single most inspirational thing i have seen in the last 6 months, and i have built an entire showcase ( opens next week - but welcome to im me to look) around what is now an acceptable bridge between sl and rl, and has resulted in securing real world clients, and real world participants who not only want me to build and manage their SL prescence but only want to do it in light of the sculpted solutions i have shown them are possible. But importantly, loyalists keep standing by through preformance and bug problems. To have been given a tool, to use it and develop for it, and then to have it pulled back will not make many friends.

Can i confirm when this new viewer will be launched?
How can i lobby or try to keep sculpt changes from occuring, or confirming what will be launched?
this will effectively "break" all my products and have the same deleterious impact on others in my position. the challenges of sculpt products are difficult - you dont want to kill development or make the commercial development platform uncertain
Stiletto Moody

x = (U32) ((F32)(t-1)/(sizeT-1) * (F32) sculpt_width);

Recalculates the last point (which is fine if at max LOD). On lower LODS you don't want the last point but the last at max LOD. I think I've said enough to explain what I'm on about though. And as I've not signed a contribution agreement probably easier all round if someone other than me actually codes the fix

Funk: yes. i think this is the most interesting point of the entire discussion: there seems to be an issue with the LOD system not properly considering resolution. this could explain why everyone is seeing different results.

Michi: good to hear that the new code is helping with your framerate. i agree, we ought to have an option for low-res sculpties, and i suspect that'll happen when we get back to sculpties work.

DanielFox: the level at which the 32x32 meshes are visible has never changed - as i said before, the first and second LOD resolutions have remained at 32x32 and 16x16.

Chosen: yes, i agree. that's pretty close to exactly the same argument i made internally when first faced with this situation. but at the same time, the change we made was very minimal, and i feel reasonable. now that i'm seeing people complaining about something that didn't change - i'm beginning to suspect hysteria.

Lex: yes. like Chosen above, i agree with almost all of what you say. and i like your option 3 - but i think it largely amounts to the same thing we have currently implemented, because most users have below average video cards. the content creators will be unhappy that their creations now appear to have fewer vertices.

Omei: sorry - but i think you're confused. sculpt map resolution has no effect on mesh resolution. the two are decoupled by design. but your suggestion for lower-res sculpties (16x4, etc) is good, and will likely be implemented once sculptie development resumes.

Domino: as Seifert points out - the 63rd row is sampled for good reason - it's not an accident or a mistake. also - texture size isn't the problem here.

Hypatia: you have perhaps the sanest comments here - this is the usage pattern that sculpties were designed for. those of you who want exact positional control of every vertex: you want to wait for SL to implement progressive meshes - trying to shoehorn sculpties into this space is going to leave you unhappy.

Stiletto: i'm sorry this is causing you trouble, although i'd like to point out that we've made the RC client available for testing for over a month. can you please send me before and after images, showing how the new code effects your work?

"Omei: sorry - but i think you're confused. sculpt map resolution has no effect on mesh resolution. the two are decoupled by design. "

and

"... those of you who want exact positional control of every vertex: you want to wait for SL to implement progressive meshes - trying to shoehorn sculpties into this space is going to leave you unhappy."

I know quite a few builders who are currently very happy building sculpties thinking that they are controlling every vertex of the mesh. Are you saying that is just an illusion, and that if they really did control each mesh vertex (which is certainly the direction I was pulling), they wouldn't like the results? If I've got that right, can you distill out what the basic conflict is?

I realize that, in reality, they'll get mad at the viewer and LL, rather than realize that they're to blame, so my suggestion may not be workable in the real world. I just think the only way to get people to realize that they need to tone down their content is to provide meaningful repercussions.

"Domino: as Seifert points out - the 63rd row is sampled for good reason - it's not an accident or a mistake. also - texture size isn't the problem here."

Seifert says it's due to LOD issues. I disagree. While I may not have made it obvious what I was talking about, the suggested change does give very clean LOD levels.

I'm implemented the change to my Blender scripts to demonstrate, so maybe a picture will be clearer.

http://dominodesigns.info/images/FixedLODs.png

That shows the effect on a mathematically generated plane: http://dominodesigns.info/images/sculptie_plane.tga

If you scale the plane to 32 x 32 and run it through the unfixed formula, you'll get exactly the same as my fixed version does on the higher resolution ones. So the methods are identical up to the max LOD size. Mine maintains the max LOD from 32 x 32 with sculptie maps of higher resolutions, the current implementation allows an extra row to creep in.

If there is a good reason for this behaviour, could you share it please?

"Hypatia: you have perhaps the sanest comments here"

/me rushes off to add "Qarl Linden thinks I'm insane" to my sig file

You don't want to stretch it out across the whole thing, because then when you go to the nice 16 segment next LOD down, the texture would move near vertices that haven't, or if you force the texture to not move, then there would be some weird distortion at all LODs because of what happens at the top LOD.

If instead we have the texture map one pixel to one segment until the last one, which crams in two pixels, then you solve the above problem at the cost of varyingly stretching last segment of textures, as the LOD changes.

With the extra row of vertices, it's much more elegant, each pixel goes on one polygon.

You don't want to stretch it out across the whole thing, because then when you go to the nice 16 segment next LOD down, the texture would move near vertices that haven't, or if you force the texture to not move, then there would be some weird distortion at all LODs because of what happens at the top LOD."

Heh. If someone had mentioned texture mapping as the concern I'd have known what the problem was this approach of the extra row was trying to fix. Yes my way does introduce the complexity of having a different UV map for an unwrapped sculptie. Wrapped ones still get the 32nd face added so they work as before.

I've not looked at the way SL handles textures but I'd be very surprised if there isn't some degree of subpixel mapping available when using a 32 x 32 texture. So the talk of slots seems a little misguiding.

"If instead we have the texture map one pixel to one segment until the last one, which crams in two pixels, then you solve the above problem at the cost of varyingly stretching last segment of textures, as the LOD changes."

Lets look at the cost.

Sculpties get approx 5% more vertices at max LOD
Minimum sculptie map size is 64 x 64 when it could be a maximum of 32 x 32 resulting in 4 times the memory use on client while reading them.
Sculpties get texture movement across 1/8th of their size at lowest LOD, 1/16th at next.

"With the extra row of vertices, it's much more elegant, each pixel goes on one polygon."

Perhaps, but I think the costs are too much. Particularly as if people want per pixel mapping they could just change to a sphere or torus sculptie type and get the 32 faces in each direction. Just seems crazy to me to break all sculptie types to fix a corner case that could be handled with education.

The bonus is not 5% more vertices. The bonus is that the number of segments is always a power of two.

64x64 is really not very big. Particularly as the vast majority of sculpty textures will have associated with them a colours texture which is many times the size of the sculpty texture.

Changing to sphere or torus type isn't going to help you. Having to deal with the wrong topology is going to cause a great deal of grief in getting around yet another strange quirk of SL. Besides, you can do that right now with the current system, since a torus will work fine from a 32x32 texture. For that matter, a plane will also work fine from a 32x32 texture, it's just that something weird will happen at the 33rd vertex, rather like what you're proposing anyway.

This comes down to weighing hackiness on one side against inefficiency on the other. Computers are just going to keep getting better, so the inefficiency will become even less relevant as time goes on (not to mention that any small boost you get from using small textures gets wiped out anytime someone with a thousand twisted tori in their hair walks by). Ugly hacks stick around for a long time, because breaking backwards compatibility is something that LL can't really do.

Hmmm.. Using a 64 x 64 grid to get 33 x 33 points versus a 32 x 32 grid to get 32 x 32 points. hackiness and inefficiency appear to be on the same side.

Sadly I do agree that it's too late to fix, but there is hope. As the current implementation has that 64 x 64 minimum size, 32 x 32 and below could be fixed without breaking anything. Omei's suggestion about allowing pixel size to determine mesh size could be implemented there too.

The thing about the current implementation is that the mesh generation side does work correctly for 32 x 32 or smaller so that could be left alone. It's the texture mapping that has the wrong topology. A 32 vertice row naturally gives 31 faces, with wrapping an extra face is created from the last vertice to the first. The first is the seam on the wrapping, so in the UV map this 33rd point is put at the end of the texture map. Thus perfect mapping, 32 faces and the myth of the 33rd vertice is born

When there is no wrapping it's set to the last row. On a 32 x 32 this means it is a duplicate vert which gets removed, thus leaving the correct number of faces (31) for equal area texture mapping. Scale this to the full UV size and you get a correct map. As you say, the downside is that edges of sculpties don't line up with edges of pixels on the texture map, but this isn't normally a problem for 3D apps. The UV sculptie map being different than the texture UV map is a bigger issue, but the 33rd vert hack introduces the quirk of textures not staying put.

So perhaps the best option is something as simple as

if ( texture_width <= 32 )
{
do correct U mapping;
}
else
{
do hacky U mapping;
}

throw in a

if ( SizeT > texture_width )
{
SizeT = texture_width;
}

and similar for SizeS, texture_height and V.

This gives the ability to do sculpties of various sizes up to 32 x 32 with predictable LODs and equal area texture mapping across them all. Thus a lot of existing texture become more viable options for sculpties.

The sculptie creator could decide mesh size and whether to wrap or not and make an appropriate sized sculptie map. A 32 x 17 would make a good cylinder with power of two texturing for example.

And as it all happens on currently unsupported sizes, backward compatibility can be maintained.

31 faces is not the correct number of faces for equal area texture mapping, unless you are thinking that the pixels should be centered on vertices? But then if that were the case, if you scale a texture up by a factor of 2, what pixel center goes on the end vertex so that the applied texture looks the same as the original smaller one?

"the 33rd vert hack introduces the quirk of textures not staying put. " - I don't see what you mean here.

I don't think a 32 x 17 texture could be supported currently: everything is fixed to powers of 2, and I suspect there's quite a bit of hardcoded stuff in there. One of the big advantages of sculpties is that they required essentially no changes to most of the systems involved (no new data types, it all goes through the existing texture channels).

"31 faces is not the correct number of faces for equal area texture mapping, unless you are thinking that the pixels should be centered on vertices? But then if that were the case, if you scale a texture up by a factor of 2, what pixel center goes on the end vertex so that the applied texture looks the same as the original smaller one?"

Sigh.. Look at the picture I posted. The meshes shown there are actually how the UV map would look. UV texture map and sculptie UV map are two different things on a sculptie. Take a single face sculptie. That's a 2 x 2 map. The texture UV map is four points at the four corners. There is the exact number of vertices we need, there is an odd number of faces (1) and there is perfect texture mapping. Why should the layout change if I subdivide the face?

The only time it needs to change is if we add say horizontal wrapping. This adds an extra face from the last vertice to the first. so instead of one face on the texture UV map, we now have 2. So while we still only have those 4 vertices, and the sculptie UV map remains the same, the texture UV map does change to accomodate the extra face. A 3rd row gets added at the end of the texture, the points that were there move to the middle.

"the 33rd vert hack introduces the quirk of textures not staying put. " - I don't see what you mean here.

I mean the "varyingly stretching last segment of textures, as the LOD changes." As the final segment on the map at highest LOD is not equally sized with the rest, this means that section of the texture at lower LODS slides across a little.

"I don't think a 32 x 17 texture could be supported currently: everything is fixed to powers of 2"

Not everything. I've uploaded oddball sizes by using jpg instead of tga.

"One of the big advantages of sculpties is that they required essentially no changes to most of the systems involved (no new data types, it all goes through the existing texture channels)."

If LODs levels are being revisited with Omei's suggestion to get control over mesh size in mind then the current hack of the 33rd vertice becomes more of a hinderance than a help. Which is what prompted me to post.

Wish I had the time to do a full proof of concept implementation to clarify exactly what it needs.

I'm sorry if this is getting tedious, but you've got to explain what you mean if you're going to convince anyone.

" Look at the picture I posted. The meshes shown there are actually how the UV map would look. UV texture map and sculptie UV map are two different things on a sculptie. Take a single face sculptie. That's a 2 x 2 map. The texture UV map is four points at the four corners. There is the exact number of vertices we need, there is an odd number of faces (1) and there is perfect texture mapping. Why should the layout change if I subdivide the face? "

The single face sculpty is a degenerate case of this whole deal, but the same analysis applies. What would a single face sculpty with wrapping look like? By analogy with a 32 face sculpty with wrapping, which has 32 vertices, and a 16 face sculpty with wrapping that has 16 vertices, a 1 face sculpty with wrapping would have 1 vertex. Yes I know you couldn't actually make this with straight lines. It should look like a circle with one vertex on it, as opposed to a circle with 32 vertices on it. The reason you use a 2x2 texture for the plane version of this, is that you are going to the next highest power of 2 from 1 = 2^0, which is 2^1 = 2, and you use the last extra pixel to tell you where the extra last vertex goes.

So the 2x2 is really a size 1 sculpty map, but you have to use the mysterious "33rd row" to get it to work properly as a plane sculpty.

If you start with a size 2 wrapped sculpty, then it has 2 faces and 2 vertices. If you want to change it into a plane, you need to add an extra vertex to say where it goes. So we switch to a 4x4 sculpty texture, and pixels 0, 2 and 3 say where the vertices go.

There is no varying stretching of the last segment of the texture as the LOD changes with the current setup. Perhaps we should meet in world to hack this out, we seem to have some differences over the facts at hand.

"I've uploaded oddball sizes by using jpg instead of tga."

Internally everything is resized to powers of two. Check the properties of that uploaded texture and see what size SL thinks it is.

To clarify, the texture is never resized. What actually happens is that a separate array, the mesh, is built from the sculpt map when the sculpty is rezzed, and again each time its LOD changes. (This happens in LLVolume::sculpt(U16 sculpt_width, U16 sculpt_height, S8 sculpt_components, const U8* sculpt_data, S32 sculpt_level), in case you want to follow along in the code.) This is the point at which odd-sized, non-square, textures get converted to one of four square sized meshes.

I'm investigating what happens if "small" sculpt maps (what that actually means is TBD) create a mesh which matches the texture size. Kind of a feasibility study into whether low-resolution sculpt maps (which typically are used for "geometric" or "folded" models, as opposed to "organic" models) might benefit from a different implementation, one that is both more flexible and more efficient.

Why degenerate? A single face sculptie is an ideal form for shadows under furniture etc. Saves 4 verts, 5 faces and 1 texture used over the common way of doing this which is a box with 5 sides set to a totally clear texture.

"What would a single face sculpty with wrapping look like?"

Like a plane with texturing on both sides. This would be one way to do cut out figures, also currently done with a box. Saves 4 verts, 4 faces and no need for the totally clear texture on the edges.

"By analogy with a 32 face sculpty with wrapping, which has 32 vertices, and a 16 face sculpty with wrapping that has 16 vertices, a 1 face sculpty with wrapping would have 1 vertex."

No it doesn't. You took off the wrapping. 2 face sculptie with wrapping has 2 vertices in the U direction. a 1 face sculptie with no wrapping also has 2. Same as a 31 face with no wrapping has 32 vertices.

"If you start with a size 2 wrapped sculpty, then it has 2 faces and 2 vertices. If you want to change it into a plane, you need to add an extra vertex to say where it goes. So we switch to a 4x4 sculpty texture, and pixels 0, 2 and 3 say where the vertices go."

Ok so why do we need the extra vertice? why not just add an extra face from the last vertex to the first? After all that vertice on pixel 3 does need to be the same as the one on pixel 0 for it to work, right?

"There is no varying stretching of the last segment of the texture as the LOD changes with the current setup. Perhaps we should meet in world to hack this out, we seem to have some differences over the facts at hand."

You brought up the varying stretching (which I have witnessed in some versions of the sculptie implementation), I just assumed the problem wasn't sorted yet because you mentioned it. If it is fixed, that actually removes one advantage the current implementation has. Working with either format now means that the texturing UV map is different to the sculptie baking UV map on unwrapped sculpties. In both methods wrapped sculpties won't have sliding textures, it's unwrapped ones like plane and cylinder that would show any problems.

"Internally everything is resized to powers of two. Check the properties of that uploaded texture and see what size SL thinks it is."

It was a jpg (which is lossy so not suitable anyway) that worked for me, both tga and bmp have resized. I'll double check next time I'm in world but I clearly remember my surprise when it happened as I expected it to resize. This was quite a few versions ago though, I've not tried to repeat it as I don't normally use jpgs.

Only images being used as onscreen textures need resizing, due to OpenGL 2.0 and earlier only supporting power of two images I would assume.

I doubt anyone would complain if the sculpt map display was replaced with the upload preview display for sculpties. That would also fix the issue of screen grab stealing of modify enabled sculpties.

The lossless upload could mean just that and keep the size too. I can understand why for performance it makes sense to resize normal textures and do it once before storing, but for something that isn't intended for onscreen display it makes less sense, particularly if they are supposed to be lossless.

You can see the screenshots I posted up here when I filed this issue. It was never sorted out.

also, keep in mind - MOST residents are seeing your sculpties as in my screenshots above. as you rightly noted - our viewer doesn't correctly compute LODs for high resolution displays - the workaround is for residents in these situations to adjust their mesh detail slider so that they get the correct resolution. i know this is an inelegant solution, and causes you grief, and for that i apologize.

I have messed with the detail slider and need to push object detail to MAX to get something comparable to the old LOD (and I still get the mohawk effect on my hat at long distances, which never happened with the old LOD)

i wanted to float an idea past you - one that'll hopefully help solve/resolve the LOD issues we're seeing. (now, don't get too excited, i haven't run this past any other lindens yet - but it seems reasonable, so i'll fight for it if that time comes.)

the idea is to add another parameter to the sculptie - one for "mesh resolution". you can select "high", "medium", or "low". the default is "medium", it's the current 32,16,8,6 progression we now have. "high" returns us to a higher level of detail (perhaps higher than we had previously, possibly 64,32,16,8) and "low" is for frugal sculpties (possibly 16, 8, 6, 4.)

with this option - you could easily fix your hat/shoes by switching them to high resolution - and at the same time, naive builders will default to the reasonable levels.

I hope our old stuff gets set to HIGH though. I dont want to have to have to manually set all my current items to HIGH then have to repack them all into vendors, not to mention having to manually resend them to everyone who bought them earlier :/

I wont get excited yet, but this would be really great if you can twist some arms to get it implemented.

yeah, i'm afraid that's the way it would have to work. if we automatically changed all existing sculpties to "high", we'd end-up back where we started. the key idea here is that the content builder must intentionally (and manually) choose the high-res mesh (and its associated lag effect.)

I hope (if we get this) we can at least highlight multiple linked prims and change the setting in 1 go (unlike lights for example which require you to select each prim separately)

High 32, 32, 16, 8
Medium, 32, 16, 8, 6
Low, 16, 16, 8, 6

Though I'm not sure 6 is a good last value as it messes with having predictable LODs at the modelling stage, so I'd prefer to see something like:

High 32, 32, 16, 8
Medium, 32, 16, 8, 8
Low, 16, 16, 8, 8

» http://blog.secondlife.com/2007/11/07/new-viewer-second-life-1184-viewer-now-available/

For Release Notes, see:

» https://wiki.secondlife.com/wiki/Release_Notes