Narrow sculpty problem. Upload problem or client problem?

Ok - i've been noticing this happening a lot lately. For some reason, on sculpts where they are narrow compared to the length of the overall object, vertices are displaying as being either really crumpled or distorted in some way. Sometimes the bunching doesn't even have to be really small - it could just be a long, manipulated cylinder for railings, etc - they often show up jagged or in some pixelated approximation of circular.

Is this a known issue? or am I doing something wrong when I upload? I could have sworn they were not showing up like this some weeks ago.

For your reference, the first graphic attached shows an object that *should* look like a smooth, burnt candle wick. The second graphic shows part of a railing that *should* be round and not jaggy.




Addendum: and yes, i'm using lossless upload.

when you imported the image did you use
the option
lossless compression for .tga files

also

this looks like the sculpt isn't even fully loaded or you probably did not smooth the sculpt out very much.

use a simple program with graphics tool and use blue a couple times and try it again using lossless compression

These are lossless TGAs. They are loaded as far as they will go. image cache has been cleared multiple times. Sculpts are perfectly smooth in Blender. Export methods used (Domino's plugins) have been same as I've used for over a year. This occurs with both my own sculpts and some made by friends.

nice trees btw..

which client are you using? i have noticed some strange sculpty behavior in the latest main client.. I have been using the RC client as a rule.. but was forced to DL the regular client when some customer were complaining of random sculpty wierdness to verify the problems.

also.. do you have your object detail settings at maximum? This may cause stuff to not appear to load fully.


-why

Thanks

My primary client is the current RC, however this appears with Kirstin Cinquetti's Shadowdraft as well as the release. (EDIT: The release is running on my much older Mac, which has object quality settings set to medium)

I'm also noticing this *only* happens if the proportion heightwise is considerably longer than it is widthwise. A sculpt for a taller candle (let's say 1 wide:7 tall), for instance, does this near the wick, while a candle about a third the height(but still taller than wide) does not.

- Further experiments with and without alpha channels do not affect this issue.
- a deliberate upload that was *not* lossless was jaggy, but not in the same way and appeared in addition to the same odd sectioning seen in my attached photos.

That is strange.. what does the sculpt map itself look like? another thought with Domino's scripts, have you applied the scale and rotation previous to bake the sculpt map?

I presume you are using the multirez feature of the scripts to preview the LOD by checking in each mulitrez level.. does your problem sculptie look the same as a low multirez? I typically apply the mulitrez before baking.

You could also try reimporting the sculpt map back into blender to see how it looks in a round - trip test..


-why

Ah, ok, applying the multirez seemed to help.

I'll try to keep that in mind for all further sculpts - Thanks!!

That's odd. It shouldn't make any difference whether it's applied or not. Make sure the "Render Level" option is set to the right level for the sculpt map (3 normally).

Hrm. Yes, wierd, this is still happening with some other sculpts i've been working on more recently, whether multires is applied or not (whereas it did seem to help with the candle I was working on earlier, which was less severe).

Basically I'm seeing a lot of crumpling, vertices going where they're not supposed to - crumpled, etc., when they should be in a more round configuration.

Has this style of sculptie worked for you in the past? The reason I ask is that it looks like aliasing problems from trying to model details that are too small. There are only 256 steps in each direction on a sculpt map, so the finest step between two points is 1/255th of the size. So on something like a tree where the overall height is say 5 metres, the minimum detail step is around 2 cm. For the full 32 faces, that means a diameter of about 10cm is the smallest branch width you could model without using degenerate faces.

Anything smaller will show issues like this, both in SL and reimporting the sculptie into Blender.

It's because your vertices/edges snap together, or rather, they snap to the "grid" represented by the 32-bit color space.

Look at it like this: A sculpt map has 8 bits (corresponding to 256 values) per RGB channel. Each vertex in your model can only be at exact positions between 0 and 255 on each axis, i.e. it can be at [5, 134, 55], but not at [5.25, 133.73, 55.1]. If the position is a non-integer, it will be rounded to the next integer value.

Now, in structures that are thin compared to the overall dimensions that's naturally a problem because if you have a small cross section, there aren't enough possible positions on the grid to fit all of the vertices.

There are ways around it, though. I did a tube frame chassis for a buggy using an octagonal cross section, resulting in a 16x64 sculpt map. Then I manually stretched it to 32x64, effectively doubling the vertex count by having two vertex columns collapsed into one edge. You can get away with it still looking smooth because 3 columns are necessary to make a sharp edge. Then I stretched the last vertical column of pixels to get a 64x64 sculpt map, which effectively collapses all the vertices there into a single edge.
What you end up with is a sculpty with half the horizontal resolution, i.e. 16x32 instead of 32x32 (effectively it's 8x32 because two columns make one edge). Downside is that LOD can behave strange.

Of course, since I made that (haven't been able to go in-world for months because of RL problems), we've gotten oblong sculpt maps, so this technique is pretty much obsolete.

What you can still do though, even with oblong sculpt maps, is check vertex positions before baking. I do it in blender by cloning the mesh, scaling it to 2.56 in every dimension and then doing a snap to grid, with the grid set to 0.01. You can then drag the vertices around with snap to grid enabled to make sure none are overlapping.

To a certain extent, yes. However I hadn't begun to do this much stretching until recently, as I started encorporating various branch structures along with tree trunks. I haven't had as much of a problem with individual branches that are constructed this way, though as you mention the overall area covered must also have a huge factor in it.

I'll try to keep this scale issue in mind with further work.

Thanks!

Interesting... i'll have to give this a try. Thanks!

https://jira.secondlife.com/browse/VWR-9384 will make oblongs much more useful in replacing this technique.

No doubt about it. I've noticed that lossless uploading is already a non-issue, so going ahead and using oblongs should be safe, right?.
Amazing how fast things seem to change when you're gone for a few weeks, can't wait to get some free time on my hands to try it out

Not really.. As Omei mentioned in the bug report, the patch makes oblongs behave differently, that's why he marked it as major priority and why we pushed hard to get it in before the 1.21RC became the live viewer.. So instead of teaching people to use them, I'm still asking people to vote for the jira and recommending they boycott the current implementation

To help fix long crinkled sculptmaps you should use the new oblong sculpties.

So if you wish to make a long tube you would export it as a 16x64 sculpty. Or even 8x128.


The crinkles are caused by not enough positions available because of the 8 bit precision (0-255) of sculptmaps.

You can sometimes overcome this depending on the shape of your object and depending on whether your sculpty convertor maximizes the scale of your object before exporting.

In your case you've got it bad because your object is a very awkward shape and so the maximizing of its scale isn't goiing to help at all. When it comes to scale maximizing - an ideal shape would be something long and straight, like a sword.. or a willy when it's happy.

After the vwr-9384 changes of course... Until then it's best to avoid oblongs as using them risks losing a lot of functionality in LOD management for ever. Last thing we need is "existing content" that isn't compatible with the update.

I've been using them in a major multi-million dollar project. It's too late now!.

Be interesting to see if the patch gets applied or the report closed with a "Won't fix" then

Here's sample of the effect of the patch:

8 x 8 LOD3: 4,4 not 32, 32
8 x 8 LOD2: 4,4 not 16, 16
8 x 8 LOD1: 4,4 not 8, 8
8 x 8 LOD0: 4,4 not 6, 6
8 x 16 LOD3: 4,8 not 22, 46
8 x 16 LOD2: 4,8 not 11, 23
8 x 16 LOD1: 4,8 not 5, 12
8 x 16 LOD0: 4,8 not 4, 9
8 x 32 LOD3: 4,16 not 16, 64
8 x 32 LOD2: 4,16 not 8, 32
8 x 32 LOD1: 4,16 not 4, 16
8 x 32 LOD0: 4,8 not 3, 12
8 x 64 LOD3: 4,32 not 11, 93
8 x 64 LOD2: 4,32 not 5, 51
8 x 64 LOD1: 4,16 not 3, 21
8 x 64 LOD0: 4,8 not 3, 12
8 x 128 LOD3: 4,64 not 8, 128
8 x 128 LOD2: 4,64 not 4, 64
8 x 128 LOD1: 4,16 not 3, 21
8 x 128 LOD0: 4,8 not 3, 12
8 x 256 LOD3: 4,128 not 5, 204
8 x 256 LOD2: 4,64 not 3, 85
8 x 256 LOD1: 4,16 not 3, 21
8 x 256 LOD0: 4,8 not 3, 12
8 x 512 LOD3: 4,256 not 4, 256
8 x 512 LOD2: 4,64 not 3, 85
8 x 512 LOD1: 4,16 not 3, 21
8 x 512 LOD0: 4,8 not 3, 12
16 x 16 LOD3: 8,8 not 32, 32
16 x 16 LOD2: 8,8 not 16, 16
16 x 16 LOD1: 8,8 not 8, 8
16 x 16 LOD0: 6,6 not 6, 6
16 x 32 LOD3: 8,16 not 22, 46
16 x 32 LOD2: 8,16 not 11, 23
16 x 32 LOD1: 5,12 not 5, 12
16 x 32 LOD0: 4,8 not 4, 9
16 x 64 LOD3: 8,32 not 16, 64
16 x 64 LOD2: 8,32 not 8, 32
16 x 64 LOD1: 4,16 not 4, 16
16 x 64 LOD0: 4,8 not 3, 12

16 x 64 and 8 x 128 both appear to be requesting more faces than are available, this means a degenerate face on the wrap and texture jumps on LOD changes. So they can't even be considered supported sizes under the current implementation.

The "not" is just a seperator, some combinations give the same results.

Is this the case even on lossy sculpties with an extra large sculptmap?.

Why hasn't LL made it so that the oblong sculpties take the final column of vertices from the edge of the sculptmap. Ya know - like they've done with the 64x64 sculptmaps?

If you are using oversized maps, the highest LOD level should be the same. I've attached a list of the full range of ratios and the changes the patch makes to the jira.

https://jira.secondlife.com/secure/attachment/19893/vwr-9384-ratios.txt

Once you hit the maximum face count for a given ratio, larger versions give the same results. The patch moves that maximum up a size to match the 2 pixels per vertex of the 64 x 64 map for a 32 x 32 face sculptie.



They have. That's the problem with 8 x 128 as you need 9 x 129 to represent that number of faces. The last column comes from width -1 so ends up as a zero width face. When the LOD changes and the zero width face is removed, you get a texture jump.

Ah that's great. I always use oversized sculptmaps (128x12. I never use lossless sculptmaps because they take too long to appear.

Speaking of which - I was just reading the Jira and Qarl mentions only supporting 64x64 (or less) sculptmaps in future!

I've tested and it clearly takes longer for a 64x64 lossless sculptmap to rez when compared to a 128x128 lossy sculptmap. And using 64x64 lossy sculptmaps results in a significant drop in quality when compared to 128x128.

For me 128x128 is by far the best when taking rez times AND quality into account.

Yeah.. have to be at least 64 x 128 with the oblong patch and I'd prefer at least 128 x 128 so that there's room for animations via profile and path cuts.. I'd really prefer 256 x 256 for animations but I'd settle for 128 x 128 as it's the historical lossless size.