new sculpty mesh sizes?

Woo hoo! I'm not the extremist for a change

I think any chance of improving it significantly went out the window with the choice of using 2n pixels to represent n vertices. What would have reduced to further along the same pixel, now ends up at the next one. Given the need to maintain compatibility and to allow for things like end cuts and profile cuts I think some non power of two levels are acceptable. LOD 0 isn't a subset of LOD 1 on the current sculpties, and I think trying to impose it now will cause more trouble than it's worth....

An historical note: There was a time in the development of sculpties where LOD0 for a 64x64 bitmap was 4x4. Qarl didn't like it because it turned "organic" shapes (which has always been his primary interest) into rectangular ones, whereas 6x6 at least let them have some semblance of being rounded. So Domino's point about compromise is a good one -- if having some sizes that goes through "odd" size sequence like 16x32, 11x22, 5x11, 4x8 is actually seen as a good thing for organic modelers, I wouldn't feel any need to try to argue them out of it.

Having said that, I wouldn't complain if 4 x 9 was special cased to make it 4 x 8.. That fixes quite a lot of them

Good point. And I am really quite happy to compromise. After all, there are plenty that conform to my preferences. Good point about the not breaking the 6x6s that exist too, Omei.

Qarl, it seems like we've got a pretty good consensus, among those most active in this discussion, about what is important and what isn't. And there have been almost 1900 builders who have read at least some of this thread, and I don't think any of them has expressed the opinion that what we're asking for is a step backward from the RC 1.21.0 implementation.

I'm going to be even more radical. I made an algorithm for my scheme, but realised it was much faster to use a lookup table. This needs only 128 integers, so it doesn't use too much memory. The big advantages are (a) that you can then use whatever numbers you like with equal ease, and (b) you can even have alternative tables, selected with a flag. This would allow one table optimised for "organic" shapes, and another optimised (like mine) for "sharp" ones, with virtually no extra overhead.

I have ... NOT ... attached a simple version of possible C++ code for this, and a table that compares Domino's and my own suggested numbers ... because the forum attachment system refuses to work for two whole days. If anyone can tell me a simple way to make them available, I will do so.

Hoorah! 1.21 RC 2. Qarl fixed the lossless oblong bug. So I uploaded my 128-separate-solid-piece sculpty and it worked.

Qarl, where do we stand on this? Have you accepted our request in principle? If so, should we settle on a specific patch and submit it to the Jira? Or would you want to write you own version anyway?

I ask because there is no sense in submitting a Jira patch if you don't support it. I realize that your support may not be sufficient to get it incorporated into the viewer, but it is certainly a necessary condition.

If we do and the patch is based off my python code, it'll (probably) need a check on minimum sculpt map size of 8 pixels in either direction. I've signed a contribution agreement so using my code or persuading me to write a patch are both valid options

One thing this has brought back to mind is the minimum sculptie size of 6 x 6. With a minimum size of 8 x 8, the formula gives better results (same as LOD 1). It would be nice to see the sculptie LODs (or at least LOD 0 ones) moved to an editable config option rather than hard coded in the viewer. That way people could opt in to a 8 x 8 minimum if their machine is up to it and get clean subdivisions on most of the sculptie ratios.

Ah. Found out why I couldn't add attachments. So here are my preferred dimensions for oblongs, and the code that makes them (table lookup version only). See post 09-0802008 in this thread for explanations.

{note - for speed, the map sampling index function should be called only once for each index, to build vectors of the appropriate length which then supply the numbers as they are used repeatedly}

hey Omei - sorry to be slow getting back to you - i was on vacation for a bit - and now i'm swamped trying to catch back up.

i think the next step here is to file a jira for each separable idea. no need for patches yet, unless you feel so inclined. once filed, i can begin directing other people to it for comment. (LL and residents alike.)

sound good?

Qarl,

Hm. Separable issues. There are different ways to try to separate them. What I see as the most important change could be broken down into three independent pieces:

1) When creating the mesh from the sculpty bitmap, never double-sample points. Double sampling creates bad texture mapping.

2) Uniformly treat a 2^n x 2^m sculpty bitmap as specifying only 2^(n-1) x 2^(m-1) quad faces, consistent with the traditional 64x64 and 128x128 sculpty bitmaps. This preserves good texture mapping as LOD changes.

3) Modify the LOD reduction algorithm to strongly favor factor-of-two reductions in each dimension. Failing to do this makes it very difficult to manage the degradation of geometric features over multiple LODs.

But do you really want three separate Jira items for these?

Domino, Drongle, ..., do you agree that these three together cover our main concerns?

Exactly. I believe my scheme adheres to all these perfectly (except for the 6x6 at lod0 for square maps, a concession to backward compatability). Domino makes a few more concessions to the rounded sculpty, keeping some non-power-of-two dimensions.

You could add that the dimensions at each LOD step should be determined by the maximum that satisfy the requirement for a number of quads (1024, 256, 64, 36 at present, I think).

I think that then the only ambiguity left is the decision about which dimension to divide by two when a lod step is satisfied by reducing only one or the other.

I think the three points are not really separable as they collectively form a specification for a single sculpt map sampling scheme. Separation might lead to implementations where they don't work together.

I also proposed two (or more) mappings, selectable by a flag, optimised for sharp and rounded sculpts. This depends on adopting the look-up-table implementation (which also has the advantage of speed*). This is clearly a separate issue and I can do a separate jira for that.

*At least it would have in the old days. In the age of pipelines and predictive memory access.... who knows?

Actually my concessions are more to do with thinking of implementing profile cuts and end cuts and allowing for other LOD setups. In my opinion these cuts should reduce the used area of the sculptie map, so requests for sizes like 19 x 23 should be supported.

I'm wondering if Qarl means adding Jira's for potentially conflicting ideas so the votes can decide. So for no doubling it could be three separate issues / possible solutions:

1) Never double sample points
1a) Limit sculptie size to n - 1. This needs a lot of other changes to sculptie generation, but could give improved results on 32 x 32 and smaller sizes - it's allowing n map pixels to represent n vertices as with n - 1 you always need to add the last row to give the full sculptie. This is the most complex to implement as the generation of the sculptie UV and texture UV would be different for different types of sculptie.
1b) Limit sculptie size to n / 2 (previously option 2)
1c) Change sculpties to use a lookup table

2) now 1b)

3) Favor power of two reductions
3a) Increase minimum generated sculptie size to 4 x 4 from 3 x 3
3b) Change sculpties to use a lookup table (linked to 1c)

4) Improve favoring of power of two reductions (not needed with 3b)
4a) Add option to increase LOD0 from 6 x 6 to 8 x 8
4b) Special case 4 x 9 and 9 x 4 to generate 4 x 8 and 8 x 4.

My example code does 1b) and 3a).

My real preference is for 1a) but I don't hold much hope for it as it breaks the 2 pixels per vertex expectation. It would also break existing content to some degree as the number of faces would no longer be consistent over the different sculptie types. The main benefit is in better end cap handling (eg a capped cylinder would keep the barrel shape at all LODs).

1b) 3a) and 4a) is the package I think most likely to cover most peoples needs. It gives comparable results to a lookup table for the majority of map ratios with very little coding.

I think I agree with 1b+3a+4a, if I understand them correctly.

However, you seem to be implying that the lookup table is exclusive of other choices. In fact it is compatible with any of them (The table can be filled in with the algorithm if you want!). It is simply a means of implementation that avoids repetitive calculation. It should have substantial performance benefit.

As side effects it also removes all constraints possibly arising from algorithmic approaches and allows the use of alternate tables.

Sorry if that caused any confusion, I was using "lookup table" for the "hand pick values for each LOD & ratio" option.

It's tricky trying to split the options this way. 4a & 4b aren't mutually exclusive either. 4a offers higher end PC users a way to drop LOD0 for sculpties (by making it the same as LOD1), whereas 4b improves the reduction from LOD1 to LOD0 for anyone with 4a off..



I'm not sure whether the calculation is so complicated that switching would give better performance. If it's not about allowing more complex formulas to "hand pick" values, then I'd wait until the code is stable for this. It'd be easier to test any performance difference and raise another Jira then if appropriate.

Not sure I follow your 4a/b options completely, but I do have to disagree about the lookup. True, these calculations may be too small a part of overall rendering cost to make a significant difference*, but you are proposing a whole new piece of code anyway. In that case why not use the lookup code instead. Then you never have to risk changing the code again - just change numbers in the tables. I would always choose the more flexible option during development, even if there was a performance hit.

I do have an instinctive prefrence for algorithmic calculation. It is more intellectually satisfying. The numbers in my table are generated that way.

Well, never mind. That's all philosophy. What matters is the numbers we end up with. I think we should try to define the alternatives for those, offering the algorithms where they are available, and let Qarl and his friends choose how best to implement them.

I will wait for one of you guys to start the jiras and add my options if it seems needed. I think it's best to put the lookup idea in a separate jira, as it can be used whatever is chosen from the more important one(s).

*I'd have to look at the source code, but I hope the whole map->vertices transform is only done once whenever the map or prim dimensions change. In that case it would certainly be too insignificant a difference to bother with.

Not really. I'm just looking at tweaking sculpt_calc_mesh_resolution which is currently on lines 2096-2145 of http://svn.secondlife.com/trac/linden/browser/trunk/indra/llmath/llvolume.cpp

4a) would just be a setting to switch the constant SCULPT_REZ_1 from 6 to 8.
4b) would be ugly checks for 4 x 9 and 9 x 4 and changing them to 4 x 8 and 8 x 4 (hence why I came up with 4a as a cleaner solution )

3a) is just changing the 3s in the llmax statements to 4s.

1b) is changing "S32 vertices = sculpt_sides(detail);" to
S32 sides = sculpt_sides(detail);
S32 vertices = llmin( (width * height) >> 2, sides * sides );
and adjusting the later code as vertices no longer needs multiplying by itself there.

OK. I have looked again with those modifications to the function*, and I do like this combination. (Especially losing lowest LOD level; effect of 4a; will Qarl let us do that?) As in my earlier table, there are only three possible map dimensions that disagree with mine at the lower LODs. These preserve the w/h ratio better than mine at the cost of sacrificing the rule that successive sampling subsets are contained in their predecessors. It is easy enough just to avoid those particular dimensions if I want to stick to my rules (16x654, 16x128, 32x64). So I am perfectly happy with this proposal.

You are right that the code changes are small enough that Qarl will probably prefer that approach (although of course the lookup would let you have 4b with no ugliness at all !).

I did find slight differences between some of your python numbers and those from C in the original verison of the function, I think due to implicit casts in C in the middle of the calculations instead of the explicit cast at the end. Doesn't make any real difference though.

*for completeness ... "s = (S32)(vertices / fsqrtf(ratio));"
.has to become ........"s = (S32)fsqrt(vertices / ratio);" too.

OK. Here's my suggestion for organizing the Jira issues.

Jira 1: Request the implementation of the three principles laid out in post #112. I agree with Drongle that it doesn't make much sense to separate these out as Jira issues, even if they are logically independent. I also acknowledge that these principles don't completely specify all the choices, i.e. Domino's sub-categories. and the implementation issue of algorithm vs. table look-up . But I don't see Qarl's acceptance or rejection of the overall request depending on these. We can continue to discuss the details on the Jira, and there may be other commentators once we change venues.

Jira 2: Request the option for content makers to be able to specify a choice of LOD strategies.

Jira 3: Request the option for users to control sculpty LOD change aggressiveness independently from traditional prims.

Jira 4: Request the ability for a builder to specify the partial use of a bitmap matrix.

If you guys concur that this makes sense, I'll write # 1. Presumably, Dongle would write #2 and Domino would write #3 and 4. (I think that's who suggested them in this thread.)

Sounds good Omei. For jira 1., I think we should include the list(s) of expected results (however implemented), to make sure it's unambiguous. If you don't want to put exact numbers, Domino or I can add them in a comment.

I think the cases of non-factor-of-two sampling in Domino's function, which I agreed to accept, are at odds with your rule 3, although that was phrased to allow exceptions. Am I right there? Are we all agreed on accepting these (unless/untill alternate tables appear)? I suspect Qarl will agree with Domino, as these will work better for "organic" sculpties.

What about a fifth jira ... request that sculpties are not rendered until the uncompressed map is in plce ... to avoid the nasty half-loaded ones and the silly spherical blobs? Or is there one already for that?

I seriously wonder whether just doing the patch and submitting that as the jira might be better.



I won't be voting for that one.. I read it as "lets make the life of 3rd party sculptie tool developers even harder"



Do you mean the option to disable LOD0 on sculpties? I don't see this as altering change aggressiveness.



Well, that's only part of it. Enabling normal prim editing options on sculpties is more what I had in mind. I think that's best done as one big job rather than a bit at a time.

I certainly don't object to adding a patch, especially since you and Drongle seem to have reached a consensus. I haven't actively participated in that discussion because I don't have any strong feelings about it. I'm not currently set up to build the client, but if you are, go for it.

I didn't mean to imply that there was any consensus about which Jira items were good or bad, or to commit you and Drongle to submitting the suggested Jiras. My main purpose in listing 2-4 was to clarify what isn't part of #1. I'm not sure I would vote for this, either. Seems like it might be better not to distract Qarl from making progress on general meshes.

I guess I had generalized it in my own mind. Since LOD is a only client side optimization, I can see a reasonable argument for a slider that allows more control than just disabling LOD0. But I'll leave it to you to write the Jira however you see fit.

Whatever you want. I thought my wording captured the essence; I apologize if it didn't. Again, I mostly wanted to make sure that we agreed this was distinct from #1. (I think the more narrowly defined the Jira issue, the easier it is to get Qarl's attention.)

OK, please go ahead and do that. I want to vote for it yesterday. That really deals with the most important aspects. We can add explanatory comments of we want to. The lowest LOD thing is just one number - easy to revert if Qarl wants to.
I'm sorry you see it that way. You wouldn't have to use anything you didn't find useful, and it would be completely transparent.
Never mind. That bit is in your patch anyway.
I haven't ever thought about this, so I can only agree that it's a separate issue. (Does this make the 3rd party sculptie too designer's life easier?)

Anyway, I am going to wait for you guys to sort out the dimension/LOD jira so that I can vote for it.

Ok, I've created a Jira issue for the main item. It's https://jira.secondlife.com/browse/VWR-9384

I hope all those who have been following this thread without raising objections will vote for it now. If we don't get Qarl's attention before the oblong sculpty code reaches the main grid, we might have to live with the current implementation just because of the backward compatibility uproar that would come with a later change.