|
|
|
Qarl, you understand the implications correctly. It is our belief that for a builder trying to manage LOD degradation, having the number of faces drop by factors of 2 (so that there is a subset of vertices that stay fixed across LOD changes) is more important than either maintaining the ratio of the sampling in the two dimensions or maximizing the total number of vertices sampled. But exactly how best to trade off these three considerations occupied much of the discussion on the forum.
I have made tables of the s and t from three versions of sculpt_calc_mesh_resolution in the file oblong dims.png
These are supposed to be for Domino's version described in the forum (apologies for any errors), for my own version (Drongle) and for the existing version (Qarl, again, apologies for any errors). There is a key below indicating which parameters fail to preserve aspect ratio, which are(not) powers of two, and which are different in Domino and Drongle. I think we more or less agreed in the forum, to Domino's version, which does a better job with the aspect ratio than Drongle's. (The latter is more strict about the powers of two and sacrifices aspect ratio in some more cases. It might be useful if lookup tables are used instead of a function, but that's for a later jira). As can be seen, there are only two more cases (14) where the aspect ratio is wrong with Domino's than with the existing function (12). Domino's function also produces few cases which are not powers of two, so that these can be avoided by the geometrophiles without much loss of functionality. Note also that the existing function is fairly approximate in preserving the aspect ratio (orange cells) while Domino's function is exact in many of the same cases. The cases where Domino's numbers have the wrong aspect ratio are forced by the minimum dimension of 4. I may have made some mistakes here, as the shading was by hand. Please donlt hesitate to correct me. That's a great set of comparison tables, Drongle!
I'm not sure whether it was on purpose, but I want to note that your shading only reflects principle 3. Many of the boxes left white in Qarl's table violate principles 1 and 2. It was on purpose - because that's what Qarl asked about
 Yeah using 1 face as the minimum actually corrects all the ratios where the 4 face minimum causes a problem. But I don't think it will leave as many useful ratios and it allows more non-power of two sizes to creep in. For me there are two main issues:
A) The oblong sculpties as implemented break with the 2 pixels square per vertex that was established with the 64 x 64 sculptie maps. B) The minimum of 3 faces is not artistically useful in the majority of use cases. Sculptie hedges and things like http://forums.secondlife.com/showpost.php?p=2022772&postcount=516 A) is principle 2. Fixing this automatically covers principle 1) as well. Fixing B) by increasing the minimum to 4 faces means that principle 3) is mostly done. The majority of the cases where 3) is broken happen on LOD0, and this is to be expected as 6 x 6 is not a power of two size. The obvious fix for this is to increase LOD0 to 8 x 8. As this could have adverse performance effects, I suggested that there should be a user option to set LOD0 to 6 x 6 or 8 x 8. The cases where principle 3) isn't followed all have an alternative ratio that provides a good solution: 32 x 32 instead of 32 x 16, 32 x 128 instead of 16 x 128 and 64 x 64 for 32 x 64. Everyone is used to having control over the top 3 levels of LOD by treating them as subdivision surfaces. I think losing that is more controversial than having to explain that the long thin sculpties trade LOD in one direction for the other and to model accordingly. If the LOD pops on some sizes are a problem, then the modeller should be using more sculpties of a smaller size. It puts the prim use / LOD precision equation directly in our hands. Note: The chart of ratios shows my figures with an 8 x 8 LOD0 option enabled. Qarl wrote:
so i think #3 is the most controversial. ... In extensive discussion in the Builder's forum, there has been no controversy at all about this. The only discussion has been how far to push it, e.g. the difference between Domino's and Drongle's tables. I suspect you really mean that #3 is a sticking point with you. If that's the case, can you tell us more? hey Omei -
just after i finish this comment, i'll post the jira to my sculptie discussion group, and we'll talk about it in my office hours tomorrow. (i'll save you a transcript if you can't attend.) but let me explain my own concern: the 2:1 ratio is perhaps the most important setting for the new aspect feature. this is because it gives the most even coverage of a sphere (there are twice as many lines of longitude as latitude.) and most shapes are sphere-like. right now sculpties create a square 1:1 covering - which sadly gives a very uneven coverage. but your proposals for #3 hurts 2:1 the most. almost making it not useful. looking at the charts (thanks again for the charts) both of you have 32x16 for your highrez 2:1. that gives nice coverage - but with the same limited resolution of the original 1:1 sculptie. in fact, since it is directly smaller than the 1:1 sculptie (which is 32x32) i can't see why i'd use 2:1 at all, unless i was trying to be efficient. ... that said - i also don't see your fundamental problem with non-powers-of-2. (i went on a bit about this back in the forums, but let me repeat myself here SL's basic prim geometry doesn't LOD on powers of 2. (the prim sphere has 24 verts at its highest rez.) when using NURBS based modeling packages - the artist can tessellate to any resolution - so it's a very similar system. now - i do understand how it's maddening for someone trying to control every exact point of every LOD with a mesh-based modeling tool. and i sympathize. but i feel the correct fix for this problem is for SL to support true mesh structures, and leave sculpties for the NURBS crowd. ... and my last concern (well, maybe not last but last for now Qarl, check the higher resolutions on my solution, I think 64 x 128 gives what you want.
64 x 128 x 3: 22,45 oh oh - maybe so. i didn't see that.
It's principle 2 in action. We need at least 44 x 90 pixels to properly represent that ratio
The changes we are asking for don't remove any features, they just make them consistent with the expectations the original sculpties gave us. The only known adverse effect will be on the currently unsupported map sizes below 64 x 64 such as 32 x 32. Adding principle 2 will fix the bug where that size gives degenerate faces, but it will also reduce LOD3 to be 16 x 16 faces where currently it would give 31 x 31 on planar mapping. Qarl wrote:
and my last concern (well, maybe not last but last for now As a fellow software developer, I completely agree with your second sentence, but not the first. Sometimes, a table is the easiest way to describe something. The fact that we're discussing the differences between proposals by referring to tables instead of algorithms suggests to me that this may be one of those instances. (I actually don't have a strong feeling here, other than to resist the notion that using or not using tables should be a goal in itself, rather than an implementation decision that comes into play after we figure out what the desired behavior is.) "but i feel the correct fix for this problem is for SL to support true mesh structures, and leave sculpties for the NURBS crowd." ..... (a) But from last weeks office hours, meshes may be very far away and (b) I have not understood how the proposal disadvantages the "NURBS crowd". (There are other solutions that maintain exact aspect ratios and power of two reductions with numbers of vertices between original and DM functions ... I'll see if I can make another table of them!).
"i really don't like the idea of using a look-up table." ..... (c) Omei said it exactly. Nothing can be more explicitly clear than a lookup table. Perhaps you mean that the thinking behind it needs to be describable? For that the algorithm is clearer, but a well written comment/prescription is much better for either. However, we don't need to waste any more time discussing this as we are all agreed on using an algorithmic function rather than a lookup function at this point. Domino said "...I think 64 x 128 gives what you want. "
In fact I think you can generalise that the higher dimensioned maps from Domino's function will all match the original function, but while the original function gives identical results for all maps with the same ratio, Domino's provides extra options from the low dimension maps. In other words, Domino's function fits the extra result sets into the redundant parameter space of the original function. If this is true, it should not disable anything that is needed by the "NURBS crowd". Furthermore, Domino's function with low map dimensions allows the generation of sculpties with low triangle counts, saving rendering load when it isn't needed. This will (partly? more than?) pay back for the small added load from the change of SCULPT_REZ_1 to 8 instead of 6. hey guys - i think i misunderstood you - i thought you meant to reduce all sculpt mesh resolutions to powers of 2. if your systems allows a 128x64 map to generate something around a 44x22 mesh - then i withdraw my concerns.
well, not all of them - i do still feel strongly about the lookup table business. as you say, i don't much care about the implementation - but the logical description of it. it's sorta an Occam's razor for software - if its smallest description is some giant table... something must be amiss. (but it sounds like both your proposals do have a simple description.) Qarl wrote: "we'll talk about it in my office hours tomorrow. (i'll save you a transcript if you can't attend.) "
Thanks, Qarl. As I suspected, I wasn't able to break away from work to attend, Is the transcript posted somewhere? Omei -
here's a partial transcript (sadly a lot of the discussion was lost when our sim went down, and i forgot to save what i had before the relog. Drongle was present, perhaps he has the rest.) [11:28] Qarl Linden: heya. we're back i guess.... Sorry, I couldn't make the office hours.
As the 8 x 8 minimum LOD0 option seems like a non starter, Drongle came up with a solution to the 4 x 9 ratios, which I've simplified somewhat. After setting the vertices value but before the s & t calculations something like: if width != height: will limit the oblong sculpties to 4 x 8 at the minimum LOD. It has no effect on the higher LODs or square shapes. (sorry for multiple edits again!)
Yuu Nakamichi: what are Domino's concerns regarding the non-power-of two degradations? Minimal really now. My main concerns are maintaining the 2n pixels to represent n vertices and that 3 as the minimum face value isn't good for a lot of shapes. I explored a lot of options and listened to what everyone else wanted and as it happened, the changes to fix my issues also meant that map sizes too small for a ratio, degrade to power of two results in the majority of cases. When we add normal prim editing tools on sculpties into the equation, the 2 pixels per vertex to get the full sculptie (and non-power of two sizes) actually gives a little more flexibility. With cuts it leaves extra positions and the pixels used for the LODs would change with each cut, so a nurbs surface like sculptie makes sense. So now I think the best solution is something like my test python code: def fixed_size( width, height, detail ): (each '.' is an identation level) Chosen Few: How about just disallow anything bigger than 128x128 to be applied in the sculpt map field from this point on? Being able to use bigger maps along with normal prim editing offers a fairly clean solution to animated sculpties. A 256 x 256 map could hold 16 frames of a 1:1 sculptie, just update the start and end cuts to use the appropriate part of the map. Updating the prim properties should force a graphics update, so the sculptie would change shape as the frame was changed. I have added some files that describe the suggested changes in some detail.
sculpt_calc_mesh_resolutions_versions.txt sculpt_calc_mesh_resolution_versions.xls; sculpt_calc_mesh_res_dom.png; sculpt_calc_mesh_res_ext.png Although I prefer the output "extra" option quite strongly, because I think it will give smoother lod changes and because it bhas more segments that can be used for complex angular shapes, I have to admit that it is longer and less intellectually satisfying. Maybe Domino can shorten my cumbersome addition at the end, as he did the earlier one. The functions were tested in the Borland C++ builder compiler. I cannot guarantee that they will behave identically with other compilers, but I don't know any reason why not. Drongle, just looking at your new version. What's the "just in case" part for? 64 x 128 and 128 x 64 should both work and at first glance it looks like you are disabling this by reversing the ratio.
Domino. The truncation depends on having s>t (truncs=trunct*ratio must be integer). I was thinking it doesn't matter which way round the map was, but now that you make me think about it, I see that it does if the stitching is not the same on both dimensions (cylinder).
I added stuff to make it work both ways. It gets uglier and uglier! I've attached my python test script for exploring the results from the changes. I think it's a good compromise between the various ways sculpties could be used. I'm not yet convinced that the benefits of power of two LODs on the maximum sizes are worth losing ~200 faces. So the function in the script doesn't have Drongle's latest suggestions.
I am inclined to agree. On reflection (mental, that is) I think the most useful dimensions for the sharp edged stuff are the ones that do satisfy the power-of-two rule (ie w x h = 4^n). That means there is plenty of scope for making sculpties that need this property. Personally, I would not work with the dimensions that juggle about with the aspect ratio and use strange numbers like 51, but I don't have to. However, while I enjoyed working out the more "perfect" scheme, it is unsatisfactorily cumbersome and I would be happy to see it left to gather dust as an intellectual curiosity.
So are we all agreed on this course, so that we can unanimously recommend it to Qarl? I note that the 6x6 at lod0 for the square maps is strictly only needed for 64x64 for backward compatibility, but is presently applied with the other square ones too ... that's ok with me. Anyone object? Lastly, Domino, I don't have python so I can't check. I use R for testing, and there I have done conversions to integer on all the assignments to s and t to get out the same numbers as from C+. I am sure this is because of the implicit cast on that assignment in C+. Could you check whether you get the same numbers as in my "Domino" table, or whether you would if you added the int() cast to each assignment? Just so we are sure we are talking about exactly the same thing. PS - The loss of 400 triangles might just as well be considered a performance advantage an accuracy disadvantage PPS - I should change my code to use your more effcient AND ... Done Yes, the Domino table is correct. My attached test script gives identical results to it.
The things it changes from the rc4 version are: Maximum sculpty size is limited to map width / 2 and map height / 2. Minimum faces in any direction is limited to 4. 4 x 9 is considered a non useful result and is corrected to 4 x 8 for oblong sculpties. Drongle and Domino, I'm happy with the current sculpt_calc_mesh_res_dom.png, which I think is what you two have agreed on. At this point, I think we're just making small adjustments to address Qarl's specific concerns, and as far as I can tell, this addresses all he has expressed so far.
Thanks for keeping on top of this. I think we have unanimity then. So it is up to Qarl now.
To summarise.... We prefer the shorter function that requires only small modifications to the existing code. This makes available optimal dimensions for all aspect ratios for organic sculpties, including the important 2:1 (64x128), and for many aspect ratios for sharp edged sculpties with accurate LOD subdivision on a subset of pixels. It replaces the redundancy in the original function with the option of low-triangle versions that may be used to improve performance where appropriate. It maintains backward compatability for the old 64x64 map. We think this deals with all the issues Qarl raised with the original proposal(s). I guess the only open question is to check that the outputs work with the downstream stuff to give the expected rendered results. I can't help here as I don't have Visual Studio. Drongle said "I can't help here as I don't have Visual Studio."
Alas, you can't get off the hook that easily I was hoping from something he said in the forum that Domino was prepared to make a patch. But he didn't say so explicitly, so I may have been mis-representing him. FWIW, as part of investigating the feasibility of VWR-2615 (http://jira.secondlife.com/browse/VWR-2615 Omei Turnbull said "I was hoping from something he said in the forum that Domino was prepared to make a patch. But he didn't say so explicitly, so I may have been mis-representing him"
I don't have a current build environment either. For speed I've just done a patch against the http://byteme.org.uk I've changed more than discussed to add better catching of images with 0 width or height which may or may not be related to // weird crash bug - DEV-11158 I've attached
Thanks Domino, for rescuing me from Omei's challenge.
However, your change to the test for zero made me look closer. The original function returns s and t for the default square sculpt map when w==0 or h==0. But the patched function returns the zero(s). I don't know, but I imagine this might be a problem for the calling function (divide by 0?). Other parameters less than 8 also make rather silly returns (including zeros again for 2x2 and 3x3). Therefore I suggest we should add a range test right at the start, to guarantee that the default 4x4 will be returned for all smaller dimensions, including zeros. (Note that 1x1 or 1x2 also gives vertices==0 after the shift, and one vertex in any dimension has to be fairly useless!). if (width < 8) width = 8; Since the old function works, I assume that it is acceptable to return numbers greater than the dimensions even if these are zero. I had ignored this because I couldn't imagine where the zeros might come from. Better to have this in than to wait and see if consequences are dire? PS. Assuming that sculpt_sides can never return less than 6, this should mean that the test for zero can be removed? So it's only one extra conditional statement. That's why I moved the check in the later function. Any 0s that get returned are caught and you should get the default sculptie sphere rather than trying to create one from invalid map values. I did consider whether the requested_sizeS & requested_sizeT would need setting at that point. It depends what mPath->generate and mProfile->generate do with zeros. Setting them to sculpt_sides(mDetail) is the correct action if the generates need the correct LOD requested.
if (requested_sizeS == 0 || requested_sizeT == 0 || sculpt_components < 3 || sculpt_data == NULL) { sculpt_level = -1; data_is_empty = TRUE; requested_sizeS = sculpt_sides(mDetail); requested_sizeT = requested_sizeS; }There's oddities in map sizes below 8 x 8, but as this size gives 4 x 4 faces which is the smallest supported size, that's to be expected. The size* == 0s could be changed to < 4 in the above snippet to totally block these sizes. The 0s thing is for when the client draws a sculptie before the sculptie map has downloaded as far as I know, so it's a different case than undersized sculpties. I've checked the generate and it would end up with a divide by zero.
Has anyone done a test build yet? I've just noticed in my python code I was returning t,s (not s,t) so the ratio might be the wrong way around in the patch. If so then
s = (S32)(fsqrtf(vertices / ((F32) width / (F32) height))); should be: t = (S32)(fsqrtf(vertices / ((F32) width / (F32) height))); The development version of my Blender scripts now supports these sculpties on both new sculpties (Add - Mesh - Sculpt Mesh) and importing maps ( File - Import - Second Life Sculptie). So if the math was confusing anyone, they can try them out instead of scratching their head
http://dominodesigns.info/second_life/blender_scripts_git.html Please post any feedback on the scripts to the forum http://forums.secondlife.com/showthread.php?t=203571 Added vwr-9384-ratios.txt which shows the full range of supported ratios (post patch) and shows the results for the number of faces each ratio gives including the changes from pre-patch.
hey guys - one question:
i'm sorta opposed to the & 0xfff8 in the code - which i'm guessing is an attempt to lock the numbers to powers of 2. my concern is nit-picky for sure - but i don't like the idea of forced powers of 2. do you mind terribly if i remove it (it seems to affect only the lowest LOD.) The & 0xfff8 targets one specific issue. That's the 4 x 9 faces result which it adjust to 4 x 8. That makes the LODs across the majority of the oblong ratios much cleaner.
Without & 0xfff8 32 x 128 LOD3: 16,64 With & 0xfff8 32 x 128 LOD3: 16,64 This makes the difference between LOD0 having almost no relation to the previous LODs and being an exact subset. Looking at the significant pixels of the sculpt map helps make the difference obvious: 32 x 128 LOD1: 4,16 32 x 128 LOD0: 4,9 32 x 128 LOD0: 4,8 For geometric style sculpties this is a very big thing so I'd really hate to see it gone. hm. well, one issue i have with it is that it is intentionally obfuscating its purpose. wouldn't
if ((s == 4) && (t == 9)) be more clear? It would, but you also need to catch the reverse ratio where s==9 so it's an ugly solution imho.
Would adding a comment such as // Mask for oblong sculpties to set minimum faces to 32 rather than 36 be enough? that's my problem too - imho - the logic is ugly regardless of how it's expressed in the code.
as just one example - what happens when SL starts letting you upload textures that aren't powers of 2? Qarl said "what happens when SL starts letting you upload textures that aren't powers of 2?"
We get lots of new interesting ratios to use 9 x 9 LOD3: 5,4 Although Drongle really wanted power of two results across everything, the original intention was to "strongly favour" them and that's what the patch does. It's minor adjustments that give great results on power of two textures and sensible results on everything else. Odd ball sizes are something that were considered as they could be introduced via profile and path cuts without any changes to the texture pipeline. Qarl said "that's my problem too - imho - the logic is ugly regardless of how it's expressed in the code."
Qarl, are you really having a problem with the algorithmic logic? Or is it really the principle behind the algorithm, i.e. 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. I suspect most of the builders who are supporting this don't understand or care much about the algorithmic details. But I think they do feel strongly about being able to manage LOD degradation. guys - i'm trying to keep the sculptie definition as clean as possible. but:
"if the sculptmap is non-square, then reduce the number of available vertices to the nearest multiple of 8" doesn't sound clean at all to me. given that this only affects you for the lowest LOD - and given that all this is just a hack to tide you over until true meshes come along - and given that everything works fine for the typical sculptie user - and given that i'm conceding to you for roughly 95% of your use cases: can we please just compromise here and drop this requirement? please? Omei said "I suspect most of the builders who are supporting this don't understand or care much about the algorithmic details. But I think they do feel strongly about being able to manage LOD degradation."
That's me, in a nutshell. I defer to the opinions of Omei, Domino, and Drongle, about whether Qarl's request is an acceptable compromise, but the issue in general is extremely important. In the near future, I plan to implement tools in Prim Composer for 3ds Max for managing LOD similar to what Domino has done in Blender. Qarl. I am puzzled by your reasoning in favour of 4x9. The logical series of return values from sculpt_sides() would be 32, 16, 8, 4, for the four lod steps. I guess the comment shows why you changed this, but that is where the neatness was broken, by introducing the 6. If there is a kludge, that is it, as indicated in the comment....
"const S32 SCULPT_REZ_1 = 6; // changed from 4 to 6 - 6 looks round whereas 4 looks square" Without this everything would be 4x4 anyway and neatness would rule supreme. So that gives us the 6x6 for the lowest lod for the square maps, which we left for backward compatibility. But it also gives the 4x9 (or 9x4) for the oblongs, and that is really ugly. It is not logical, it is an artefact of breaking the logical series of returns from sculpt_sides(). So I would prefer the 4x8 even arguing from the purely aesthetic values you are starting from, quite apart from the fact that 4x9 produces serious problems for designing to cope with lod. The mask form was an optimisation by Domino requiring one less conditional than my version. It is a bit obscure, but a comment can make it clear, just as does the existing comment for the otherwise obscure value of SCULPT_REZ_1 (which does not, by the way, explain 4x9). I think this has just about the same clarity/logicality status "if (width != height) vertices &= 0xFFFFFFF8; // change 36 to 32, to avoid problems with LOD switch to 4x9 quads, other values unchanged" The other thing is that keeping to 4x8 does stick to the map aspect ratio as far as possible, whereas 4x9 breaks it. I sort of hate making this comment because you have been so helpful, and it seems a bit mean, but it is my honest point of view Anyway, I guess you do have the final say. If you feel that strongly, I am sure we will grin and bear it. /Drongle sneaks away wondering if he will ever be allowed into Q again I've done a quick sculptie with a 4 x 8 base and two levels of detail which is attached as oblong_planter.tga
The image 8_or_9.png shows the effect of removing the & 0xfff8. The mesh on the left is an import without the modification and shows how the map is read for 4 x 9 faces. The middle one is 4 x 8 and the one on the right is the full sculptie. I can't see how removing the & 0xfff8 is even an option personally. Domino. Still getting no-such-file-or-directory error for your new attachments. Can you redo them?
Odd, they were working after the original upload. I've replaced them now.
well - i'd argue your graphic is a bit misleading - here's an in-world shot of the difference.
unless there's an objection, i'm going to implement everything but the ^2 thing - and you guys are more than welcome to try to get a different linden to take-up your cause. sound good? Misleading in what way?
I'm unclear what your in world shot is showing. Are you assuming the lowest LOD will only be seen when the object is far off? One of the use cases I'm considering is vehicles built for racing where sculpties are useful due to the fixed prim count. Often many of the racers will have their detail settings on the lowest to ensure the fastest frame rate. There is a very real need for the lowest LODs to look good close up. Domino - please let me know what you want me to do: 1) implement everything but the ^2, or 2) bow-out and let someone else go with this.
Qarl,
If I understand correctly, you really only consider a few bitmap sizes to be important for the "organic" shapes you have always considered to be the intended use for sculpties. If that's true, might you identify those sizes, and how you would like them to behave? Then all the others could be optimized for "geometric" sculpties. (Not that I really think there is a sharp distinction between the two.) My motivation in being persistent about this discussion is to make the full range of bitmap sizes useful, not to take something away from you. We all owe you for creating sculpties in the first place. We could modify principle 3) to read: 3) Modify the LOD reduction algorithm to: 3a) for bitmap sizes designated as being for organic sculpties, favor getting the maximum number of faces at each LOD. Failing to do this makes organic sculpties too box-ish at lowest LOD, and 3b) for all other bitmap sizes, 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. and the code could make that distinction explicit. It makes sense to me to acknowledge this distinction up front rather than trying to make it fall out of a "uniform" formula and then debating the aesthetic merits of the resulting code. Qarl said "Domino - please let me know what you want me to do: 1) implement everything but the ^2, or 2) bow-out and let someone else go with this."
I'd prefer not to make a decision until we've had chance to drum up support from another Linden, but if you feel that strongly about it I'd suggest doing both. Implement 1 and we'll raise another Jira specifically for the other issue which you could bow out off. Do you have any recommendations on who else would be interested in that area of code that we could talk to? excellent. so i'm going to put this work into the maint-viewer-11 branch. as for another linden - i'd recommend Tofu - he's inclined to both graphics and jira-patches. or you could let it fall into the normal jira pipe - i think Bridie holds office hours once a week to triage patches. (or maybe that's Liana? not sure.)
Pity, because I really can't see why Qarl doesn't want this simple no-cost improvement that has no detriment to organics, but it's much better to put up with this than to sacrifice the whole thing. So I agree with Qarl's proposed action. Thanks much, Qarl, for taking (nearly) all this forward. Domino, please feel free to quote any of my arguments in a new jira.
Thanks Drongle. I'm going to have a good long think about it and see if the logic can be refined before I post a jira on it.
It might be that rewriting the "sculpt_sides" function to a "sculpt_faces" one that is ratio aware might be a cleaner solution. The 4 x 9 problem comes because that function and it's use was designed for square ratios where width equals height, so perhaps addressing it there would be more acceptable. this issue should be implemented. right, as for now scilpties mostly are more like spheres, but it will change with progression of software\plugin etc.
The status of this is still OPEN. Does that mean that it hasn't been implemented in the viewer yet?
This was committed to maint-viewer-11 a while back, which I believe puts it on track to be in the 1.23 release when that comes out
Although Qarl's changes did get into RC 1.23.1, they surfaced another problem (yes, again) with lossless compression. See https://jira.secondlife.com/browse/VWR-8551
 . Without a fix to VWR-8551, Qarl's changes aren't very useful. Fixed in 1.23.4, released on 06/15/2009.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Modify the calculation of sculpty mesh size to eliminate bad texture mapping and bad LOD transitions
so i think #3 is the most controversial - tell me more about it. problems i see are: that either the aspect ratio will wildly vary (you won't get 1:2, you'll get either 1:1 or 1:4) or you'll only get half as many verts. but maybe i don't understand?