new sculpty mesh sizes?

I do appreciate the fact that folks are digging in and exploring these new features, it just that the feedback so far seems a bit negative. I can only take so many negative forum posts in a row before I have to jump in and do a bit of cheerleading.

Qarl seems to be one of the more open and available Lindens, especially when it comes to ideas and feedback about the new features he is working on. Don't see any reason to attack him when he is doing his best to give us better tools.

Vlad, as to Qarl, I agree with you wholeheartedly. I find that professional software developers (a category that includes Domino and me, as well as Qarl) have a tendency to want perfection, at least perfection as we perceive it, and can get quite frustrated when others are too dense to see the light. So I passed over Domino's rant without giving it much thought. I suspect Qarl did the same. But you never know, so a gentle reminder now and then about being civil seems like a good thing.

Cheers

Lossy sculpties will always download and appear quicker because of JPEG compression. So if you're making something organic where precision isn't important then sculpties will be the wisest choice.

I'm not sure if this will apply to lossless sculptmaps though. Lossless sculptmaps require a considerable amount of storage space and so there might not be any advantage in using them when the screwdrivers arrive.

That's not what I said. Even if I had been at the relevant office hours, I suspect we would still be having this discussion as it's the first code drop related to this feature and thus the first chance to check out the implementation.

Even now when I'm directly asking for info, you just keep referring to your office hours when I've already stated I can't be there.

So for us who have real life commitments that conflict with your office hours, can you point us at a transcript of the relevant office hours or a summary of the plans?

I think it's a little naive to expect residents to only do what was intended with a feature rather than what is possible with it. Personally I think the ones that do multiple shapes from a single sculptie are a little crazy, but that doesn't stop me from helping them to do it with my scripts.

All I'm trying to do here is see if there is a better way to do the LOD calculation that fits with the direction sculpties are going (which would be easier if I knew what it was) and with what's already possible with them. Sure that means a negative post or two ( or three he he ) to point out the flaws, but the end result should be a consensus that the implementation that makes it to the release client is the best that could be done.

Blender and Wings are the two main ways residents create sculpties and both creators of the scripts they use want to see a better solution. That should at least cause pause for thought.

Could you elaborate a little more on this analogy ? For me it is more, that sculpties are intended to be the nails, which get hammered into the environment by the SL-viewer... So maybe the problem is, that we try to create screws with our tools? And maybe screws can't be hammered precisely into the plywood yet?
So, shouldn't we talk more about replacing the hammer by a screwdriver to make our life easier? in that sense, the screwdriver (an enhanced SL-viewer?) would deal better with sculties now AND eventually allow for meshes...

Anyways, as i understand the hammer/screwdriver analogy, the main point seams to be, that sculpties are limited in comparison to meshes ? But ... aren't we elaborating on the subtle effects of LOD? And wouldn't meshes suffer from the same problems as sculpties ?

But lets keep with sculpties: We all learned by now, that they in general get messy, when you don't take care of LOD. Domino brought us the tool we need to keep "the nails going straight into the panel", i.e. now we have some (full) control over LOD. Which turns out to be absolutely important for sculptie-work. So, if you don't take care of LOD, then almost ANY sculptie will suffer from the LOD effect, independent of its usage, less with organic shapes(nails) and more with architectural precise elements(screws).

So in other words: isn't it important for us to keep the possibility to control LOD and be sure, that the tools (the SL-viewer here...) handle our creations in a forseeable way ? ...
Well, reading that control over LOD gets less or more complex or even broken/unreliable scares me a lot!

But anyways, i am eager to see, what we really can do with the new sculptie-variants and i'm sure, i will take another look on precise sculpting (although i now understand, that i obviously create screws for my hammer tools here) but eventually i think, we will learn (again) how to create our anticipated results for the existing tools...

And one last word to meshes: ... If "sooner or later meshes will come to SL" implies "there will be an .obj importer into SL", then i am sure, the next generation of artwork has come to SL. PLEASE IMPLEMENT THIS !!! (where and how can we help making "sooner" a really short time ?) And many of us will jump straight into the air and then pull their millions of existing 3D-artworks into SL... well, me at least...

just my 2 cents here.

I have to agree regarding the Mesh implementation.
From the start sculpties have been a difficult learning curve for most of us and with the best will in the world some of us still struggle.

an .OBJ importer so models can be directly imported without all the messing about would seem the obvious solution.

Lets all get behind MESH and make it a reality

ok - if i'm understanding you - the problem you see with the latest implementation (with it's 22x45 meshes) is that it doesn't have the property that some verts remain present regardless of LOD. this is an effect of the sizes being powers of 2. and you're surprised by this change - and you feel like it's broken.

(and yes, all of this was discussed in my office hours.)

but. that behavior (although interesting) was never a requirement of the sculptie. sculpties are roughly based on the NURBS modeling primitive - and in the modeling packages which support NURBS - they provide a tessellation parameter which is not fixed to powers of 2. they work perfectly well with any numbers.

also - the lowest LOD, having a 6x6 mesh, also works perfectly well. and for those who remember, when the sculptie was first being tested, its highest LOD was 24x24. indeed, the sphere prims in SL right now have mesh details of 24, 16, 8, 6.

so yes, powers of two are nice - but are by no means required.

that said - i'm very happy to discuss options which will improve the situation - although i'm having difficulty following all the different ideas voiced in this thread.

one seems to be the idea of reducing overall vertex count to maintain powers of 2. the problem here is that i expect many builders will object to getting fewer verts. but it should discussed.

there are other proposals that seem to wildly vary the aspect ratio to maintain the powers of 2 - that sounds much less desirable to me.

i don't mind dropping the min 3 requirement to 2 - but again we should look closely at it. when i tried 2, the lowest LOD for closed surfaces tended to "pop" terribly (the normals being interpolated across a flat surface are very different from a surface with just a little depth.)

Domino - if we scheduled an after-work session to discuss this stuff, would you be able to attend?


best,


K.

Nothing to add but sincere thanks for engaging the community on this very important matter and being willing to discuss it after hours. kudos, kudos Qarl!

OK, Qarl. You've opened the flood gates. I hope you don't drown.

I'l let Domino speak for himself, but I think there are at least 4 issues that can be separated out. I'll start with one where the issue seems very clear. I'll label it the

Doubling Vertices in Response to Small Dimensions Issue

If a scuplty bitmap has fewer vertices than are allowed at a given LOD, the mesh building doubles up vertices in order to make the "quota". This results in a discontinuous texture mapping at maximal LOD (and perhaps other LODs as well). Now this is not a newly introduced issue. Previously, the Linden position was that bitmap dimensions less than 32 were simply not supported. But it seemed like the new flexibility signalled acceptance of smaller dimensions. And if 128x8 is a supported bitmap size, why wouldn't 64x8 be as well? See http://www.flickr.com/photos/21635604@N05/2806885944/ for an example.

I think all it takes to fix this is to use the number of vertices extracted from the bitmap (in either direction) as an upper bound for the mesh dimensions.

right - but as you say - this has always been around - it really has nothing to do with the aspect stuff - it's just a matter of providing a larger sculpt map.

and all of this is tied into the issue of that 63rd row - which has always troubled the community and probably deserves its own discussion (again.

so i'd say we tackle the issues specifically tied to the new feature first.


K.

Doesn't trouble me. It makes perfect sense and I love it.

OK. That was going to be my second issue. I'll call it the Fencepost Issue.

Again, I can't speak for Domino. But I was one of those people who originally viewed using a 64x64 matrix to represent a 32(or 33)x32(or 33) array of points as an ugly, inefficient kludge. But as time passed, I couldn't come up with a solution that was better. And so I believe I have seen the light on that issue. I now view it as a good decision on your part. But in any case, like it or not, that's the way "traditional" sculpties are -- one uses a 64x64 matrix to represent a mesh with 32x32 (quad) faces. So the next issue is whether that pattern is going to be applied consistently, i.e. a 32x32 matrix represents 16x16 quad faces, or in general a dimension of 2n represents a row or column of n quads. Domino and I are arguing in favor of that consistency.

I understand that I am framing the issues in terms of a mesh, when you would rather think of sculpties as being more like nurbs. But since many (most?) SL builders probably don't really know what a nurb is, I think it's inevitable that we're going to use the mesh description as a common language.

heh.

but see, i think you're wrong there. i think there's a perfectly good (and clean) reason for it. and i've had that discussion with people at least a half-dozen times now.

so can we defer this for later, and focus on the issues with the new aspect-ratio functionality?


K.

I'm puzzled. The text you quoted was just my introductory confession. I'm saying I was wrong and you were right. You haven't
changed your position, too, have you?

ahhh - sorry Omei - i had completely missed your point. (shouldn't try to correspond while doing two other things at the same time.)

so yes, if the mesh is to have n vertices, you'll want at least 2n pixels to describe it. and it sounds like you see some inconsistency? i'm afraid you'll have to spell it out for me.


K.

Hi;

By now i have read quite a few very interesting information snippets about sculpties within this thread . And i realize, that my knowledge about this topic definitely needs some improvement. So i kindly ask for pointers to in depth information sources beyond what can be found in the wiki:

- the original (technical) requirements for sculpties
- the intended usage scenario for sculpties (Linden Labs opinion about where do they work, where not, what has to be taken into account during creation)
- in depth technical informations about sculpted prims implementation, especially regarding how LOD is handled (and why it is done so).
- informations about the discussions, which Qarl refers to in post #40 and #63 of this thread.

i also would like to understand in depth, how sculpties are different from meshes. I read they are more NURBS like... How NURBS like are they then ? there must be some principles going along with the sculptie implementation, which i am not aware off. Where can i get more details about this ?

In particular i also would like to understand:

- why the lowest LOD level uses 36 faces instead of 16 as expected from the series 1024 - 256 - 64 - 16 ...
- what is the "63rd row - which has always troubled the community" ?
- why we don't use 33*33 images for sculptie plane, 32*33 images for cylinder/sphere, and 32*32 images for torus. What exactly makes 64*64 pixel maps get "better results" ?
- related: why is that so: "if the mesh is to have n vertices, you'll want at least 2n pixels to describe it." ?
- what does this mean: "the sphere prims in SL right now have mesh details of 24, 16, 8, 6."

Damn i again feel like a newbie by now

I know, this list of questions should better go to a separate thread, OTOH since all i ask for, has been mentioned in this thread, maybe some answers can help some of us "typical users" to better follow the discussion here

Correct. At least it amounts to the requirement that a straight line touching at least one point in the rim at each end must pass wholly within the pipe. With that restriction alone (ie completely free rotation at the joints) I believe I can make 8 such sections (5 x 9 vertices) that would survive at second LOD step. How convoluted that could be depends on the ratio of pipe diameter to bend radius. If this is 1, each section can bend through 240 degrees. That could make a 5-turn helix, for instance. However, there is so much wasting of pixels to make the connecting lines that it is not worth making this. The oblong alternative is unrestricted, vastly superior, and much easier to make. I should keep quiet in future!

OK, so If I make an 8x128 bitmap, for example, I expect to see 4 quads in the short dimension at maximal LOD. But that's not what the current implementation does. It gives me 8 quads if stitched or 7 quads if not.

Gaia, I certainly sympathize with you. This discussion is way more technical than usual for this forum. On the other hand, I think there is a (perhaps small) subset of sculpty builders who are following the discussion, and I think it is important that they have a voice when the rubber meets the road. If we moved this to someplace like the SLDev mailing list, I suspect we would lose the builders who aren't also developers.

As for your questions, they are all quite reasonable. But most of the answers have never been written down in an organized manner. The SL Wiki does have some of this, but it doesn't get as much loving attention as it deserves. If you do get helpful anwers, I hope you'll get them into the Wiki.

Sorry, please don't missunderstand me. I am not argueing against this thread, i just want to keep understanding its content

Since documenting complex issues seems to be my destination, certainly i will end up with writing a compendium about "the hidden secrets of sculpted prims" or something alike, or maybe even make just another video tutorial about this topic But, beforehand i need exact information. So i will scan the wiki again in order to find more hidden infos... and hopefully get some more detailed answers from the experts here

And I understand your point now. I've never actually built a still, but my mental picture of the condensor coil has something more like a 10/1 ratio between bend radius and pipe diameter.

but! this is exactly the same problem as providing only a 32x32 map - you're going to see overlapping verts.

ok - similar to needing to specify a 64x64 map - you need to specify a map which has enough detail for the ratio you've chosen.

64x64 = 4096 pixels, but the map you cite above has 8x128 = 1024 pixels.

if you want only 4 verts in the short dimension, you need to use-up 256 verts in the long dimension, which corresponds to an 8x512 map. (which has exactly the 4096 required pixels.)

so what i'm hearing here is that you want to clamp the max number of verts based on the max number of pixels. but that's the same as your "Doubling Vertices in Response to Small Dimensions Issue", which we decided to talk about later... right?


K.

I revisited the question of how many disconnected solid objects could be made with a single sculpty. Previous record was 102 with the 33x33 plane topolgy. I made a map at 8x512 pixels (5x256 vertices) that should have made 128 separated tetrahedra, but alas, I can't upload it losslessly, so it makes a complete mess. (at least I think that's why?) This will also affect other more practical uses of the new maps. Since the data size is the same, can we get the lossless upload limits changed to operate on whole number of pixels instead of largest dimension? Should I make a jira for this?

OK, Aminom already did : http://jira.secondlife.com/browse/VWR-8725

Yes, but later has to arrive sometime. I think we've come to the crux of the matter. What Domino and I are asking for is a relatively simple, easily understandable, rule for what elements in the bitmap are going to get selected for rendering. A rule that says "If your bitmap has eight rows, at maximal LOD it is going to be rendered as four quads in the vertical direction" is transparent. A rule that says "If your bitmap has eight rows, at maximal LOD it is going to be rendered as 8, 7, 6, 5, 4 or 3 quads, depending on how many columns there are" is not.

The problem just gets compounded when a builder is also trying to take into account what their creation is going to look like at lower LODs, say when 11 quads at one level get reduced to 5 at the next level, and the 5 aren't even a subset of the 11. If you don't feel that the transparency we're asking for in the maximal LOD case is consistent with your future plans for sculpties, I don't think there is much point in slogging through lower LOD details.

Well, so far I have done most of the talking. I think it's appropriate to see if anybody else wants to throw in their two cents worth at this point. I'm sure Domino, at least, will have something to say when he discovers this discussion.

Well I'm happy..

I suppose it comes down to what type of builder you are. Organic modelers will prefer a smoother transition between LODs while the picket fence and staircase makers will prefer a powers of 2 LOD because it matches their subdivision (multires) based modeling techniques.