Jira issue for new scupty sizes

After much technical discussion (see /8/9a/278017/1.html), we (primarily Domino Marama, Drongle McMahon and I) reached a consensus and have submitted a Jira issue (see https://jira.secondlife.com/browse/VWR-9384) asking for a change in the way RC 21 handles the new flexibility to use non-square bitmaps for sculpties. But despite the fact that a lot of people have followed (at least part of) that discussion, the Jira itself has only two votes so far. I'm hoping that is because most people got tired of reading about just how many angles will fit on a bitmap, and haven't realized there is an issue to vote for.

If you haven't followed the issue until now, the short summary is that the implementation in the RC adds three new "supported" sculpty mesh sizes to the current 32x32 quads -- 64x16, 128x8 and 256x4. The requested change, which is really quite minor from a coding point of view, makes any rectangle with power-of-two dimensions supported.

Even if you have followed some of the discussion, it may not have been obvious that this change will allow sculpties to be rendered much more efficiently whenever you don't really need 2048 triangles. If you have a geometric shape that only needs 4x8 quads, for example, only 4x8x2, or 64 triangles will be created, instead of 2048. No more will a sculpty necessarily cause more rendering lag than a traditional prim.

Qarl seems to be receptive to the idea. I originally submitted the Jira as a new feature request, because without a specification, there's no clear dividing line between a bug and a feature. But it is marked as a bug now, so I presume Qarl changed it when he assigned it to himself.

Nevertheless, Qarl doesn't get to decide on his own what does or doesn't get into a release. It pretty important that this change get in before the non-square sculpties hit the main grid. Otherwise, people may start using the "non-supported" sizes anyway, which makes changing the implementation even harder because of backward compatibility issues. So if you care about the future development of sculpties, please add your vote for the issue.

Voted. Thanks for the heads up, Omei.

I voted as well. It is hard enough to get a decent complex texture on a sculptie and this will only increase the difficulty if it isnt fixed.

Voted.

/me does a shameless thread bump and just says...

Voted.

Thanks Omei, Domino, and Drongle! I *really* appreciate the thought and skill that has gone into this.

Voted!

Voted... Thx again for the heads up. I'll see if I can get some friends to vote...

For those of you who are not in the Sculpty Dev group, Qarl just sent out the following:


(I think Qarl feels those builders who think of Sculpties as NURBS haven't been represented well in our discussions so far. But Chosen, you would consider yourself to be a NURBS user, wouldn't you?)

I would consider myself a NURBS user, as far as sculpties go, yes. But that doesn't mean I don't want as much predictability as possible with LOD culling. I can't see any way in which making oblong sculpts behave themselves better in this regard could hurt NURBS-based sculpties, and it would certainly help the poly-based ones. So it's at the very least a not-lose/win, if not a total win/win.

I do get Qarl's point that in a true NURBS-based modeling system, you can tesselate to any resolution you want, but no system like that would ever have to deal with the overly aggressive LOD culling that SL forces. Because we can't control the culling ourselves, we do need at the very least to be able to predict it reliably.

In any case, the main reason I'm a NURBS sculptor is not that I have any particular love for NURBS over polys for this kind of work. It's just that I'm a Maya user, and the Maya sculpty exporter happens to be optimized for NURBS. If somebody good with MEL could add to it so that it would handly poly-based sculpties as well as the Blender and Wings exporters do, I'd be creating polygonal sculpties just like you guys do. But since I love using Maya more than I miss using polygons, I do NURBS.

While I do think having NURBS-like objects in SL is fantastic, and I certainly wouldn't want to lose them, the whole truth is I'm eagerly awaiting meshes in SL as much as anyone else, if not more so. When the day comes that we can import meshes directly, instead of having to use sculpties as a go-between, I'll rejoice.

As I see it, sculpties and meshes should co-exist. We shouldn't have to bend over backwards to force one to exhibit the behavior of the other, as we do now. But even if we had meshes today, I'd still be all for putting as much precision as is practical into sculpties. As long as SL's LOD culling remains as aggressive as it is, I can't see any better way to go than to stick with powers of two.

Chosen, could you express this to Qarl in some way? Maybe copy it to the Jira, or go to his office hours tomorrow? I'm afraid that Qarl may think of Domino and me as the fanatical fringe when it comes to sculpties.

He he.. I'm sure most people think I'm on the fanatical fringe. Hopefully some realize there's method in my madness and get voting

I'm planning on being at the office hour tomorrow. Looking forward to it.

Voted

I have added some improved tables and the source used to make them to the jira. These take account of Qarl's comments at the OH.

It's an idea.

But I feel, if we're going to be pushing this far into arbitrary geometry, we should quit beating around the bush and implement meshes or "true" NURBs support already.


Just saying.

I don't think anyone would disagree, but the question is when? (Qarls OH, somebody suggested 2027 ) While the oblong sculpties are there already. We just want to optimise the numbers they use for sampling the sculptmap. No new work vs. huge amounts.

Jeffry, you're not alone; I think this basically reflects Qarl's view. I also think everyone here has great respect for both you and Qarl, so the viewpoint deserves serious consideration.

Sculpties have been part of SL for a year and a half now. Regardless of how near or far away general meshes are, sculpties will continue to be part of the SL builder's vocabulary for a long time.

In the beginning, there was really only one supported sculpty mesh size -- 64x64. (Trying to work around various early problems. people would use sizes of 128x128 or 256x256, but those are now unnecessary and deprecated.) Its always been the case that you _could_ use different sized bitmaps (including non-square ones), but the implementation wouldn't give you good results.

Over time, and particularly in RC 21, Qarl has considerably refined the implementation, to the point where it _almost_ supports any rectangular bitmap 2048 of bits or smaller. But Qarl's personal interests are in "organic shapes" generated from NURBS models, and only a few of the possible bitmap sizes are useful for those. The current RC 21 code is targeted at those few cases. All the other cases are handled, but in a way that probably isn't useful for anything.

All those other cases _are_ (or could be) useful, however, for a number of reasons. One is ease of modeling, for people who don't gave access to a NURBs modeler (or simply prefer some other method). I'm thinking mostly now of the Wings 3D user, although it is obviously not limited to them, since there are Blender and at least one Maya user among the proponents of this Jira item. With the requested change, if a Wings builder is creating a shape that only needs 32x8 quads, they can model it that way. Without the change, they would need to model it at 128x32 to get the same quality of result. In Wings, this takes significantly more sophistication.

A second, closely related, reason is rendering efficiency. As it stands right now, that model that can be perfactly expressed as a 32x8 quad model gets expanded into 2048 triangles instead of 512.

The third reason is LOD handling. SL's aggressive LOD reduction makes LOD management one of the builder's biggest challenges. The current RC 21 implementation makes LOD management nearly impossible for most of the bitmap sizes.

So now the bottom line -- do these advantages really justify distracting Qarl from bigger issues? And here, I think the answer is Yes because the user community is doing virtually all the work. The only change requested in this Jira item is to one short function that calculates how many pixels are going to be sampled from a bitmap of a given size. (Some other issues, like animated sculpties, do crop up in the discussion of what the numbers should be, but they are not part of this Jira request.) No one is asking Qarl to take an active role in the details of the discussion, since these are all bitmap sizes that he doesn't have an interest in. The only thing we're asking him for is an occasional review so we can address any concerns he has before submitting a final patch. It is a given that we at least need his approval, if not his enthusiastic endorsement, for any sculpty patch to be accepted.

Respectfully,
Omei

Chosen, I read the transcript for the second half on the Jira. Do you have any general impressions? Any salient specifics from the first half? Do you think Qarl is receptive, assuming we address his specific concerns?

Overall, I thought the meeting went quite well. It wasn't as singly focused on oblong sculpts as I'd thought it would be, which was a little disappointing, but some good did come of the larger discussion, which was definitely worthwhile.


The only important specific point I remember that wasn't included in the transcript was the explanation for why we've got 6x6 instead of the more logical 8x8 for low LOD on sculpts. Apparently, the original scheme was for 8x8, but since that yields nearly twice as many polys as 6x6 (64 instead of 36), the powers that be at LL decided that 6x6 would make for better performance. Qarl went on to explain that when a scene with nearly a million polys with 8x8's was culled to around 300,000 with 6x6's, the word was given from on high that 6x6 was the way, and that was that.

I don't think LL will budge on this issue. There are just too many users with under-powered graphics cards. So low LOD will likely always be problematic, which is unfortunate.

But as for sticking with powers of two for everything else, I think Qarl's on-board with the idea. But again, the discussion didn't center on that nearly as much as I had expected it would, so it's hard to say.

On a side note, it's getting pretty hard to follow the discussion, between the Jira, this thread, and in-world conversations. It's all pretty fragmented, and depending on in what order you read, the picture could look very different. I'm not sure I've got it all straight at this point.


My impression of Qarl has always been that he's extremely receptive, and this case is certainly no exception. He seems to have a very genuine desire to make sure all points of view and all concerns are well considered before final action is taken.

Unfortunately, though, Qarl doesn't necessarily get the final say on what he is and isn't allowed to do. Selling him on any given idea is the just step one, the easy part. He then in turn needs to sell his boss(es), which is considerably harder. It's not always possible.

I've just posted a patch which implements the figures shown in https://jira.secondlife.com/secure/thumbnail/19302/19302_sculpt_calc_mesh_res_dom.png

https://jira.secondlife.com/secure/attachment/19436/VWR-9384.patch.txt

Vote for better sculpties at: https://jira.secondlife.com/browse/VWR-9384

http://dominodesigns.info/second_life/blender_scripts_git.html

I've updated the Blender scripts with a new base sculptie generator that applies the rules for sculptie that this jira recommends. This will give you a quick way to explore the possibilities that the new ratios give. The script takes X Faces, Y Faces and a Multires/Subsurf setting to represent the LOD as inputs and gives you the correct sculptie map and faces to model with those settings. If the size is too large it returns the maximum faces that will fit on the map. It will also optimise the UV layout for smaller sizes, so you can request things like 5 x 11 with 2 LODs and get a modeling mesh that will give good LOD results when baked to a sculptie.

Sadly, Qarl said at his office hours that VWR-9384 won't make it into the next release. This could mean that people will start creating sculpties that are not compatible with VWR-9384 and it may end up NEVER being implemented as there would be incompatible "legacy" content.

The reason given was that this was a low priority change. Apart from the combination issue that has most sculptie JIRA entries in it, it's Qarl's assigned task with the most votes. It's a method that everyone interested enough to join in the discussion agrees is the best solution (including most sculptie tool makers). And it's a method that really does need to be implemented before oblong sculpties go live to prevent incompatible content being created. I really struggle to see how it can be considered low enough priority to not include.