new sculpty mesh sizes?

I have created a long thin object in my "the arch example" video tutorial, that definitely is LOD invariant, and not at all looks crap. It is not only a sculpty, it also is a precise sculpty and it was made with a 32*32 faces mesh. I will have to check, what happens with an extreme mesh, which allows me more vertices along the bow. My "first naive expectations" would be, that i get an even smoother curvature along the bending line. And i would expect to see even more LOD invariance...

This brings up an idea. Apologize, if i am shooting into the very wrong direction. I just try to keep simple minded (that sometimes helps me understanding):

The following snippet is a hypothetical documentation snippet for the new sculpted prims behaviour:

<snip>
If your grid dimensions (edges per dimension) are divisible by 8, then the sculpted prim LOD levels will show the following number of faces:

LOD0 = (n/ x (m/ faces (* see note below)
LOD1 = (n/4) x (m/4) faces
LOD2 = (n/2) x (m/2) faces
LOD3 = (n/1) x (m/1) faces

While ensuring, that all vertices used in lower LOD levels are guaranteed to be shown also in higher LOD levels.

In all other combinations of (n,m) the LOD levels might possibly show different vertex combinations. In this sense, building LOD invariant sculpties is limited to the grid dimensions as noted above...

Example: a 32*32 faces mesh will results in following LOD values:

LOD0 = 32/8 x 32/8 = 16 faces (* see note below)
LOD1 = 32/4 x 32/4 = 64 faces
LOD2 = 32/2 x 32/2 = 256 faces
LOD3 = 32/1 x 32/1 = 1024 faces

</snip>

If LOD0 shows 36 faces, instead of 16 i would not complain, i just want to understand, is this choosen due to enhanced quality of the LOD0 display, or due to some invisible(unknown to me) rules ?

If a behaviour as described above could be implemented, wouldn't then everyone be satisfied ? A handy rule exists which can be simply explained... And Domino's scripts could still show LOD for the LOD-safe dimensions, while simply discard LOD for all others ? BTW: Why does blender only support LOD displays of power of 2 ? Is that sort of standard behaviour in 3D modelling?

again apologize, if i am completely wrong here. But explaining, why such an approach would be bad, might help to understand, how it can be done better...

Well I take back what I said earlier about the extreme dimensions (512x being crap. I've just tested a 512x8 sculptmap and the LODs were great!.

I will. I want to do some more tests to fully explore all the implications first.

Qarl, In two weeks my schedule opens up and I will be free for your office hours. Do you post the topics for each meeting anywhere so I'll know which to attend?

Also, I'd love to hear your reason for the extra row and column, The only reason that anyone gave that made sense at the time was the LOD issue. Now this discussion suggests it wasn't the LOD issue at all.

I've vague recollections of texturing being another major point, in which case was adding the end caps as separate primitive faces considered? So a sphere type sculptie would have 3 texture faces, the other types just 1 (well until cuts, hollows etc are introduced) .

This isn't true with the current RC implementation. However, it is true for a few special cases. So the resolution to this discussion may be something along the lines of "If you want that kind of transparency, limit yourself to those special cases."
Historically, it has been cheaper to build graphics hardware that only deals with powers-of-two bitmaps. (The software is also simpler, but that is less of a factor since there is essentially zero manufacturing cost for software.) So those dimensions have always received the most attention. In the specific case of textures in SL, the upload process will always resize them to powers-of-two dimensions. So unless/until that changes, there is no way to get non-power-of-two bitmaps into SL.

The former.

My guess.... For the completely stiched topologies, original sphere and torus, there was never an extra row in the map, it was generated implicitly to acheive the stitching, giving 33x33 vertices (32x32 quads) to the rendering code. When the unstitched topologies came along, the sensible thing was to use the same rendering code. So they had to be explicitly 33x33 (for plane and 32x33 for cylinder).

At that time, with no lossless upload, since larger bitmaps were routine, the simple solution was the use of the "extra" pixel in the subsampled 64x64. Now we have lossless upload, it could be 33x33, but the texture code, also being used, is restricted to powers of 2 (or at least works more efficientky with them). So it stayed at 64x64.

This has the added advantage of powers of 2 for the quad dimensions, again simplifying the (simpler) LOD switches. It also gives good numbers for designing to account for LOD and for texture stretching. Lastly, multiplication and division by powers of 2 are simple bitwise shifts, much faster than multiplying/dividing by anything else. (May be showing my vintage there ... the differences are less important with fpu pipelines etc. I used to code shift-based multiplications in assembly language!).

Any abandoning of these rules would break a huge amount of existing content. So any changes would have to preserve the legacy maps anyway.

Just for the historical record, the 64x64 bitmap was there from the start. Qarl never sanctioned the use of a 32x32 or lower bitmap. It was only those darn push-the-boundaries-and-see-what-happens people that used those.

I keep mentioning end and profile cuts as they are a way around this limit. Say on a 64 x 64 sculptie, end cut at 0.85 and end profile cut at 0.45 gives a 54 x 28 image to use as the sculpt map.. It's another reason in my opinion why clamping the max returned sizes is needed and why end capping that works on a real vertice row is preferrable.

After much staring at numbers I like the ones this function produces the best:

 # Quote this post to see indentation on code
def sculptie_size( width, height, detail ):
	v = [ 6.0, 8.0, 16.0, 32.0 ][detail]
	ratio = float(width) / float(height)
	verts = min( width * height, v * v)
	s = sqrt(verts) / sqrt(ratio)
	s = max( s, 4.0 )
	t = verts / s
	if t > width / 2 :
		t = width / 2 
	t = max( t, 4.0 )
	s = verts / t
	if s > height / 2:
		s = height / 2
	return int(t),int(s)

It gives a wide range of usable sculpt map sizes with pretty good LODs and a variety of strengths each size has. Some are better for LOD resistance (8 x 8, 8 x 16, 8 x 32), some are better for organics ( 32 x 64, 16 x 128 ) and some are better for LOD management ( 32 x 128, 64 x 64 ).

Just for fun, here's what it reckons we should use for the 54 x 28 cut option

Width x Height x LOD: Faces X, Faces Y, [ X pixels ], [ Y pixels ]
54 x 28 x 3: 27,14 [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 53] [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 27]
54 x 28 x 2: 22,11 [0, 2, 4, 7, 9, 12, 14, 17, 19, 22, 24, 27, 29, 31, 34, 36, 39, 41, 44, 46, 49, 51, 53] [0, 2, 5, 7, 10, 12, 15, 17, 20, 22, 25, 27]
54 x 28 x 1: 11,5 [0, 4, 9, 14, 19, 24, 29, 34, 39, 44, 49, 53] [0, 5, 11, 16, 22, 27]
54 x 28 x 0: 8,4 [0, 6, 13, 20, 27, 33, 40, 47, 53] [0, 7, 14, 21, 27]

And a more optimised version:

def sculptie_size( width, height, detail ):
	v = [ 6.0, 8.0, 16.0, 32.0 ][detail]
	ratio = float(width) / float(height)
	verts = min( 0.25 * width * height, v * v)
	s = sqrt(verts) / sqrt(ratio)
	s = max( s, 4.0 )
	t = verts / s
	t = max( t, 4.0 )
	s = verts / t
	return int(t),int(s)

128? The new sculpty sizes should open up some new possibilities. But didn't we more or less determine that in the optimal tiling of the infinite plane, each tile would require 19 triangles? Assuming the new sculpties will still be limited to 2048 triangles, that would set an upper limit of 107.

Have you come up with a breakthrough idea?

Not really a breakthrough, and I can't test it until we can upload the 8x512 bitmap losslessly. It's all because of the greater edge/area ratio.

You remember our 10-pixel units, and that you could save pixels at the edges because you could leave two out? Then we could get more in with the extra row in the unstitched topology? Well, a 8x512 bitmap should allow a 4x256 plus the extra row/col = 5x257 = 1285 vertices = 128 10-pixel cells.

Now You can't pack the 10-pixel cells in perfectly, but you can get two across in a 4x5 pixel space, leaving four pixels blank and four that are allowed hanging over the sides. So that allows 2*257/4 = 128 tetrahedra. In fact, the overhangs and spaces cancel out so that it does use 10 pixels per tetrahedron.

Caveat: I am making a big assumption that I am still not sure about ... that the extra pixel will still be there. The message I got from Qarl and Aminom seemed to nbe that the numbers they are talking about are faces, and for n faces you need n+1 vertices. I could still be wrong there. Seemed alright for a 32x128 map I used for stairs, using 17x65 vertices. Note that 5x257 vertices = 4x256 quads = 2048 triangles. So that limit is not violated.

_AA___
AAA0
AAA0
AAXX
0XXX
0XXX__
..XX

Interesting to note that we also hit another hard limit here. Each thingy has to use one length unit for the thingy and one unit to separate from the next, all on the straight line they share. That's 2 units each, and there are only 256 units there. So more than 128 is impossible using this technique. It is amusing that both limits may be acheived at the same time.

I tested this and, albeit with distortion from the lossy upload, the extra row and column are indeed there for both 256x4 (257x5 in 512x8 bitmap) and 128x8 (129x9 in 256x16 bitmap). So the 128 thingies should indeed be possible.

Ah. I had forgotten how you figured out how to make the edge an asset rather than a liability.

Very nice result!

OK - it's very hard for me to follow all the various threads in this discussion - but as near as i can tell - all issues directly related to the aspect ratio feature have been addressed - and what remains is Omei/Domino's request about what we do when a map is too small to provide data for all the vertices.

(if you feel i'm ignoring your issue, please feel free to stop by my office hours and harass me in person.)

so if i understand you guys, what you're saying is that the number of vertices (in a given direction) should be clamped to n/2, where n is the resolution of the map (in that direction.)

a competing idea might be to clamp the vertices to n (not n/2.) but i see problems here with texture coordinates. but i don't think anyone is asking for this, so i'll skip it.

it's an interesting idea. very clean and doesn't have any design issues (IMHO). but implementation - there are a lot of sculpties out there that would change as a result of this. some people (despite all warnings) create 32x32 maps - and probably don't want their prims to change out from under them. so we'd need to advertise this widely and gather feedback.

i'll bring it up at my next office hours to gauge the reaction.

i feel i'm forgetting something. but i suspect someone will remind me.



K.

OH NO! Please tell me you don't mean that! Please tell me you mean n/2 quads (n/2+1 vertices), retaining the extra row and column in the unstitched topologies. Otherwise you will break every sculpty I ever made and make reasonable LOD-proof texturing impossible. I just spent many hours making a whole carpentry system using 9/5 vertices at top two LOD levels on the 16x256 map. This is very efficient for making cuboids, which need 5 vertices in one direction for stitching their sides in one dimension. Nobody is forced to use the extra rows, and everyone can still use the smaller bitmaps if they don't need them. Furthermore, as that's how they work now, it would reduce the changes.

I've done a bit of sculpting with the new sculpts- 8x128 in particular. I was able to make a chain that has 8 8x12 links that textures well with repeats, and retains a decent shape under LOD. In the process of making a hand that needs some work, but these sculpts look promising for organic uses as well, when chopped up.

sorry sorry - i tend to get sloppy when referring to verts in sculpties.

i DO mean n/2 quads (n/2+1 verts.)


K.

Ahhh...I can breathe again

Aminom ... do these work even without the lossless upload (your jira VWR-8725)? I voted for that, but only one other person has. It's crucial for me.

Limiting to n results in a row of degenerate faces for the smaller sizes which gives texture jumps on LOD changes.

I also did tests on limiting to n-1 faces (n vertices) but the LODs weren't as clean as n / 2 on the larger sizes. If my end cut / profile cut stuff seems a sensible addition, then I could live with n-1 as a limit too. It would just mean using cuts to get cleaner LODs for some sizes.



The only other change I made was to increase the minimum faces to 4 from 3. I agree that 2 is too low, and 4 seems a good value as it's below the minimum sculptie LOD ( 6 x 6 ) and still allows box shapes to appear at the lowest LOD. Having it as a power of two number also helps the LODs.

Yes, that summarizes the two issues I focused on earlier in the thread. But by itself, it doesn't fully specify the LOD details, which is what Domino has been giving special attention to. I'll presume that we will agree that the main LOD constraint is that the number of faces at each LOD is limited to approximately the same number as for a legacy sculpty, i.e. 1025, 256, 64 and 36. To me, that implies that, for example, a 16x16 bitmap would result in 8x8 = 64 quads, so it would be rendered the same at the top three LODs and then rendered as 4x4 for the lowest. Do you concur?

Some of the other bitmap sizes don't have quite such obviously unique treatments, though. Suppose you have a 256x16 bitmap, giving 128x8 = 1024 quads. At the first LOD cut, it makes sense to go to 64x4. But what about the next level? Various possibilities come to mind.

Then finally, there is Domino's desire to be able to use only a portion of the bitmap. It's a nice idea. Would be very useful for sculpty animation, for example. Personally, though, I would be willing to settle for no more new features for now, especially if it means we can get our other wishes before RC 1.21 gets promoted to an official release and it becomes even harder to make changes.
I'm sure there will be at least some who argue for strict backwards compatibility. But I hope that when you present it, you'll point out that it is a big win for builders who want to make use of small sculpt map dimensions. We'd be trading a situation in which the treatment of small maps was undefined, unsupported, inefficient (because it injected tons of degenerate faces into the rendering pipeline) and broken (wrt texturing) for one which addresses all these issues. You can also point out that it is easy to fix up any existing small bitmaps to conform with the new implementation simply by rescaling them by a factor of 2, with no interpolation).

Once again, I will try to make your office hours this week, but I'm not terribly optimistic that I'll be able to break away at the designated time.

I've generated the full range of supported sculptie sizes and LODs that n / 2 and minimum faces = 4 creates. http://dominodesigns.info/downloads/second_life/lods.txt

The Python script to generate these is at http://dominodesigns.info/downloads/second_life/size_test_new.py

For comparison I've also done n /2 and min faces = 3 at http://dominodesigns.info/downloads/second_life/lods3.txt

And n - 1 with min faces = 4 is at http://dominodesigns.info/downloads/second_life/lods1.txt Note: n - 1 should really have extra texturing faces added depending on wrap and end capping, so the face counts are only correct for the plane type sculptie.



Yeah, it would be very nice to have, but really I only brought it up now so that it's considered in the context of the vertice counts. If at some point it will be done, then the final maximum vertice count is far less of an issue - greater control over it (and thus LODs) would be in the pipeline anyway.

Thanks, Domino.

Although a lot of these make sense, some seem odd. I'm wondering whether the cases I consider odd are ones that you would argue for, or whether they just fall out of your general algorithm.

Some examples of specific cases that seem odd are:

8 x 64 x 0: 4,9 (as opposed to 4,
16 x 32 x 1: 5,11 (as opposed to 4,

(I guess it's mostly, if not entirely, those cases where the number of quads is something other than a power of 2.)

It is the way the algorithm works, but it's not something I'd push to fix. One of the nice things about this solution is that there is a little something for everyone. The odd ones are more suited to organic sculpties than the ones with clear LODs.

I realised having different sculptie sizes behave differently isn't too bad as long as there are clearly defined limits and the behaviour is predictable and useful. The lowest LOD attempts to fit 36 vertices into the image ratio, so 4 x 9 is actually perfect. 5 x 11 is the nearest to the 64 vertices for LOD 1 it can manage for that ratio.

Any other solution would likely end up as another discussion on whether 8 x 8 should be the lowest LOD level

Generally I like these, but to maintain sharp corners at different LODs without the texture artefacts that result from degenerate vertices, I think it is necessary that the sampled vertices at a lower LOD are always an exact subset of those sampled at the higher LOD. This condition is not met by all of these.

Of course it would be possible to work around this by using only those dimensions that didn't have the problem (except at LOD 0 where almost all do). And I could accept that these might be better for "organic" sculpties. But there is a trick that could be used for the non-square ones that would allow alternative algorithms ... use one when the fisrt dimension is smaller and the other when it is larger.

I have to admit that my view is also conditioned by an irrationally uncomfortable feeling about sampling the vertices at non-constant spacings which happen with some of these.

Here are the alterations that would fit with my strange preferences. (I will make a C algorithm if I can).....

--------------
unsquare
--------------
8 x 32 x 0: ....4,8 [0, 2, 4, 6, 7] [0, 4, 8, 12, 16, 20, 24, 28, 31]
8 x 64 x 0: ....4,8 [0, 2, 4, 6, 7] ] [0, 8, 16, 24, 32, 40, 48, 56, 63]
8 x 128 x 0: ..4,8 [0, 2, 4, 6, 7] [0, 16, 32, 48, 64, 80, 96, 112, 127]
8 x 256 x 0: ..4,8 [0, 2, 4, 6, 7] [0, 32, 64, 96, 128, 160, 192, 224, 255]
8 x 512 x 0: ..4,8 [0, 2, 4, 6, 7] [0, 64, 128, 192, 256, 320, 384, 448, 511]
16 x 32 x 1: ..4,8 [0, 4, 8, 12, 15] [0, 4, 8, 12, 16, 20, 24, 28, 31]
16 x 64 x 0: ..4,8 [0, 4, 8, 12, 15] [0, 8, 16, 24, 32, 40, 48, 56, 63]
16 x 128 x 2: 8,32 [0, 2, 4, 6, 8, 10, 12, 14, 15] [0, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 63]
16 x 128 x 0: 4,8 [0,4, 8, 12, 15] [0, 16, 32, 48, 64, 80, 96, 112, 127]
16 x 256 x 0: 4,8 [0,4, 8, 12, 15] [0, 32, 64, 96, 128, 160, 192, 224, 255]
32 x 64 x 2: ..8,16 [0, 4, 8, 12, 16, 20, 24, 28, 31] [0, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 63]
32 x 64 x 1: ..4,8, [0, 8, 16, 24, 31] [0, 8, 16, 24, 32, 40, 48, 56, 63]
32 x 64 x 0: ..4,8 [0, 8, 16, 24, 31] [0, 8, 16, 24, 32, 40, 48, 56, 63]
32 x 128 x 0: 4,8 [0, 8, 16, 24, 31] [0, 16, 32, 48, 64, 80, 96, 112, 127]
---------------
square
---------------
16 x 16 x 0: 4,4[0, 4, 8, 12, 15] [0, 4, 8, 12, 15]
32 x 32 x 0: 4,4 [0, 8, 16, 24, 31] [0, 8, 16, 24, 31]
64 x 64 x 0: 4,4 [0, 16, 32, 48, 63] [0, 16, 32, 48, 63]