new sculpty mesh sizes?

This sounds dire. I'm presuming you're saying this from the perspective of making sculpties in Blender, though. In Wings, since it doesn't have nurbs in the first place, and the mapping from modeling vertices to bitmap pixels is direct, I don't see the user's workflow being affected much.

My overall take on Qarl's current implementation is that it is a great feature, but the specific details of LOD handling severely limit the use for any model that isn't pretty smooth all over. But even for the "organic" shapes that Qarl favors, some of the LOD details are bad. I don't think Qarl will resist changes that would benefit even organic shapes just because they are even more beneficial for shapes with sharp features. I'll drop him an email and see if he cares to comment here.

hey all - wanted to give a quick answer to the concerns voiced here. for more detail - please stop-by my offices hours friday.

i think the problem we're seeing is that you really want pixel-perfect control of your vertices. and i don't blame you in the slightest. but that's not what the sculpties are designed for - and it's not where we eventually want to take them.

what you want are meshes. and you shall get them sooner or later. and if you feel strongly - you can influence "sooner" :

http://jira.secondlife.com/browse/MISC-1494

http://jira.secondlife.com/browse/MISC-1495



K.

Qarl, I'll certainly try to make your office hours to hear more. And you're absolutely right that this discussion is about making the most of sculpties by controlling individual vertices. If and when we get more general meshes, they'll undoubtedly be even better than sculpties.

But do you really think that you are going to be able to evolve sculpties into something more NURB-like while maintaining complete backward compatibility with all the existing content? It seems much more likely that there will be a legacy sculpty implementation for existing content and a new implementation for nurbies that isn't encumbered by legacy concerns. If that's really what's going to happen, then it still makes sense to tweak the current non-square sculptie implementation to be more useful in the meantime. I'm assuming that we, in the role of open source developers, can write and test the patch. The only thing we would need from you is to tell us if we are proposing something that is unacceptable.

Option 2 in other words.. The Blender scripts do that too, it's the loss of multires previews and subsurf modeling I'm concerned about.



Linden Lab is right, residents are wrong. Same old story. I have real life commitments that conflict with your office hours and I can't find the transcripts, so I guess I'll never know what sculpties are designed for and where they are headed.

To all,

I would like to explain in less technical terms the implications of this discussion among Domino, Qarl and me.

What Qarl has done for RC 1.21.0 (kind of slipped in along with a cool scripting feature that I won't go into here) is to generalize sculpties to non-square bitmaps. As an extreme case, suppose you wanted to model a twisting pipe, say the condensor for a still. With the current sculpties, you would be limited to 32 straight sections of pipe per sculpty. But you would also be required to use 64 triangles for each cross section. This is a huge waste of rendering resources (i.e. it adversely affects the user's frame rate).

With Qarls changes, you can instead choose to use, say, only 16 triangles for each cross section, and in return get 128 straight sections of pipe per sculpty.

The klinker is that the LOD degradation in the current implementation has some serious issues. If you try to push the boundaries, such as using a bitmap size that is no bigger than you actually need, you can end up with broken texturing at low LOD. But that problem is minor and easily fixed. More significant is that unless you stick to a few standard bitmap sizes, the LOD handling gets really weird. Instead of systematically dropping alternate vertices as LOD drops, the algorithm can pick an entirely different set of vertices each time the LOD changes. How to improve this situation was the main topic Domino and I have been discussing.

My view of the impact if LL doesn't want to make any changes is less pessimistic than Domino's, though. For a small selected set of bitmaps sizes, LOD handling will still be as good as it is for "legacy" 64x64 and 128x128 sculpties, and I think Domino's scripts for Blender can be adapted without a big problem. (Is that true, Domino?) It's more a matter that only a few new sculpty sizes will be very useful, even though the code could support many more.

The square sculpt maps still resolve to the same face counts at the different LODs, so yes they are backward compatible.

I've already updated the scripts to give fairly complete support for oblong sculpties. Though in doing so I had to break support for doing things like using a 3 x 5 face mesh as the starting point.

It's the user support issues as much as anything that bother me. When I have to start explaining that certain techniques (which people are already using) will only work with some sculptie sizes it becomes more trouble than it's worth. It's not like I get paid to do it or anything

If Qarl had to support people creating sculpties rather than just doing the code and moving on, I think he'd know why I'm shouting about it.

So I either reduce the scripts to the lowest common denominator or just keep them for my private use to avoid the support headache.

I was actually thinking of ones like 256x64 and 128x32. Those would still be compatible with your multi-resolution structure, wouldn't they? Sorry if its a dumb question, since I'm only guessing how your Blender scripts work.

If that's truly a choice, and my only choice, I vote for "least common denominator".

I'm not going to try oblong sculpties soon, anyway, because of what I've read here about LOD problems. I like how you've shown us a way to preview LODs, and control them. I'll stick with that -- gratefully! I'll pretend I never heard of these oblong sculpties, even.

Ah, that I understand very well. I've tried out various ideas for Wings, but only release those that I think will require essentially zero support. And the Wings user base is presumably, on average, a lot less technically proficient than that for Blender. On the other hand, you probably have more trouble with people getting in over their head and hoping you can clear it all up with a twenty second email.

Not entirely true, as you can make, say, four sections in strips of the sculptmap, with 16 triangles per cross section, using the zero-thickness connector approach to sticking them together. However, this does leave you with shading artefacts due to the strange normals at the joints. These go away with the oblong maps.

In a bent tube, the greater problem is the outside collision box, which more or less forces you to make it phantom and use more prims to fake suitable collision characteristics. My guess is that the collison problems would be the really hard thing to deal with for arbitrary meshes too.

Well to be specific, I've limited this to sculptie maps that give a mesh between 64 and 1024 faces and assumed the number of faces will be clamped to half the map size. I've always considered LOD 0 to be a lost cause, so "OK with 1 level" means 1 & 2 work and 3 is the same as 2. "OK with 2 levels" means 1, 2 and 3 work.

LOD 0 = 36 faces
LOD 1 = 64 faces
LOD 2 = 256 faces
LOD 3 = 1024 faces

8 x 32: No Lod needed
8 x 64: Broken
8 x 128: Broken
8 x 256: Broken
8 x 512: Broken
16 x 16: No Lod needed
16 x 32: Broken
16 x 64: OK with 1 level
16 x 128: Broken
16 x 256: Broken
32 x 32: OK with 1 level
32 x 64: Broken
32 x 128: OK with 2 levels
64 x 64: OK with 2 levels

256 x 64 is another that works, but we are now just repeating other ratios on a higher resolution sculpt map. Even with the full range of sizes that produces up to 1024 faces there are only 11 distinct ratios ( 1:1 and 1: powers of 2 from 2 to 1024 ). The rest are repeats or rotated versions.

The third choice is lots of donations so I do get paid

The lowest common denominator is no more LOD previews as they won't work on all sizes.

my office hours are at 11am SLT each friday. you can find the location by googling for "qarl linden office hours".

despite Domino's insistence that residents were not consulted on this issue - all i can say is that i've been discussing it with residents publicly and frequently for at least six months.

again - i'd like to state that you ought not try to do mesh-like constructions with sculpties - it's like using a hammer when you need a screwdriver. it works sometimes, and other times, not so much. the solution is not to make the hammer more like a screwdriver - the answer is to get a screwdriver.


best,


K.

But it's so much fun! A delightful intellectual challenge. I will be sad when meshes arrive because all that effort will be devalued and we will be stuck with boring same-old 3D programs, where everything is already worked out and only experts will prevail.

Realistically, since there apparently will be both a hammer and a screwdriver in our toolbox, under what circumstances would it be better to use the sculpty hammer versus the mesh import screwdriver?

... and you'd better tp straight into the office 'cos it's VERY hard to find it going in from the outside! (unless you know the secret way in

Really? I wouldn't know how to do that. How would you keep the connector one dimensional when the sections aren't straight?

Where you say "No Lod needed", I agree in principle. But the 1.21.0 code duplicates vertices for bitmap dimensions less than 64 (or 32, depending on sculpt type), resulting in bad texture mapping at the highest LOD. I consider that broken even worse than doing funky things at lower LOD. No?

I would think "real" meshes would imply real physics, as well. Or at least more real than sculpties. Physics might be computed with a lower resolution mesh than rendering, for example. I don't think Qarl would be holding us off on sculpties if he thought meshes were going to be half-baked.

So somehow these new features for making sculpties are 'broken' and useless before they even hit the RC viewer? Gimme a break.

Slice and dice the algorithms any way you like, it wont change the fact that sculpties were never meant to be a precise mesh. The fact that we've figured out how to bend them to our will is really just a bonus.

The content and tools that we already have are unaffected and we get more creative options. How is that a bad thing?

I guess it depends....I was assuming you weren't going to see inside the pipe. In that case, you have the vertices that stitch along th length of the pipe, at its top& bottom edge in the bitmap, all linked to a row of pixels that are a single vertex inside the pipe. The next row is the single point inside the next section. This does assume the pipe isn't too convoluted, in which case you would need more rows. It's not as efficient as the oblong, of course, because you waste the extra rows of pixels. I'll have a go at making one so you can see. The only ones I have already are five separated straight cylinders with closed conical ends. Not the same thing, so it will take a day or two*!

If you don't allow me to have nasty stuff inside the pipe, then you are right (unless it can be straight sections welded at angles, in which case you can make the extra pixel row a vertex on the rim with the joint, so there is nothing inside).

*also the calculations are quite hard and my vector arithmetic for bending the tubes is poor, although that would be the same for an oblong.

Vlad, what we're discussing is what is in the current Release Candidate viewer, which means what it says. So if anything is going to be changed before it become part of the official viewer, now is the time to do it.

I joined in this discussion because there seemed to be significant enthusiasm for the new flexibility, and yet there were what I considered to be fairly minor implementation flaws that would keep them from being more generally useful. Qarl's take on it seems to be that if only a few special cases work well, so be it, because he wants to devote his energy to full blown meshes. I can live with that. But it still seems useful to sort out what the existing implementation does and doesn't do, if for no reason other than to set expectations. And one really small change in the code (i.e. not artificially creating doubled vertices) would fix a problem that will affect organic sculpties just as much as any other. (Or alternatively, you could say it would greatly expand the range of sizes that the new code actually works well for.)

Agreed, "broken" is a subjective, binary, shorthand for a more nuanced issue. But I think Domino is perfectly justified in using the term as a shorthand, given that he has gone to a lot of effort to provide the details behind that judgement.

Drongle,

I don't mind nasty stuff inside the pipe. After all, I'm not going to drink the end result. Still , I can only visualize how it would work if a straight line between the ends of each section lay entirely inside the pipe. If you can do better than that, it would be instructive to see how.