Torus Mesh Bug

Hello,

I took one of my chairs out of inventory this morning and discovered it's been completely borked by some change to the way in which the Tori mesh is rendered. I bug reported it of course, but I am posting this here so as to let everyone who bought the chair that I *know* that it's been bugered up and that it ain't my fault, it's those gosh darned Lindens! I also think it's kind of an interesting thing and I am interested to see if anyone else has experienced it.

There should be pictures below, but suffice to say the chair is made from two sections of Tori and one complete one.

Now it looks very simple, but in fact it took me weeks and weeks to get the sizing of eaach piece just right so that it fits precisely together and is absolutely seamless. The whole point of this piece in fact is the single seamless curve of it.

You can imagine my dismay when I took it out to sit on this morning and saw the giant divot on the left hand side. The texture mapping on that Torus is also screwed up and shows as a dark band on the right side.

After a bit of testing and trying to reproduce the error, it turns out that on the two pieces that are sections of tori, the profile of the torus is (as would be expected) a normal ovoid. On the piece that is a complete torus however, the profile has defaulted to an ovoid with a "cut-off" end.

Now, none of these three pieces are profile cut at all, and it's actually impossible to profile cut a torus to achieve this same "cut end" effect. It seems like it's strictly an artifact of how the system is drawing the mesh for the torus.

To make it really obvious, in the lower picture there are two otherwise identical tori, (one in fact drag-copied from the other) that are perfectly aligned on the grid, with only one difference. One is the afore-mentioned complete tori, the other has been path cut (not profile cut) to 0.95, which is generally the smallest path cut one normally makes.

I think this must be related to all that fooforaw about the spheres and cylinders not lining up recently becasue of the change they made to the mesh, but my impression was that that change was reversed after a big outcry about how it ruined a whole lot of content.

Could a Linden maybe post on this thread as to whether that change was in fact reversed, cause it looks like it wasn't from this point of view.

Apolgies to all if this is already a well-known thing and I am the only one in the dark, but I couldn't find anything on it.


.

Yes, I noticed this effect too and was *equally* annoyed.

Ah well.

Having had my home rezzers and the Caledon trains nerfed a bit for that one single day following the grid attack last week, well, I'm jaded now I guess.

Yep, I noticed this a while back. Back when Michi, Lex and I were complaining that we were getting 15, 9, or 6 sided polygons instead of circles they fixed it, by forcing the cross-section to be 24 sided if the cut values were anything other than 0.0 to 1.0. For most tori, its pretty unnoticeable that the cross-section has fewer sides than it should, becuase most tori are closed up. As shown here, there are other ways to get the torus to not close up, and yet the cut to be 0.0 to 1.0 (eg taper).

One way to get around it, though its nasty, is to replace the 0.0 to 1.0 torus with two tori, one 0.0 to 0.5 and the other 0.5 to 1.0, Horrible I know, and the lighting/shiny doesn't work as well as if its a single prim either. Doubling up the number of prims is bad in general, for one of my sculptures it would mean doubling the number of prims in the whole thing, so I found some other way to change the aesthetic and get around it.

There are some other things that used to match up but no longer do, to do with twists and profile cuts. That one has broken a number of other sculptures. Hopefully Dan Linden is continuing work on moving to polygons with powers of two sides (32, 16, 1, and can sort out some of the recent problems too.

I'm not sure I completely understand this statement.

My comment however would be that if what they did originally that was causing the problem with the mismatches was deemed to be a non-workable situation, why not simply revert to the way things were instead of this artificial forcing of tori to be a certain number of faces? Perhaps I am misunderstanding though as this tori is not tapered, and is closed in the sense of being not profile or path cut. Unless you mean the fact that it is an open curl instead of a donut?

I understand your solution, I thought of that myself, but as you say it would add a prim to my chair. I am also not sure it would work as even thoughI haven't tried it yet, the two profile cut "half" tori would still not be path cut and its the lack of a path cut that gives the deformed torus in this case.

EDIT - Tried this, it doesn't work. Only changing it from a non-path cut torus to a path cut torus removes the flat side artifact. In other words redesigning the curve of the chair and therefore the entire chair.

What's worse is that I have sold a lot of these chairs to a lot of people. Am I now expected to go around the world replacing chairs with new ones that have an extra prim just because for some unannounced reason they decided one day to change the torus? This seems fairly outrageous for the Lindens to expect this of me.

Again, I don't really understand what you mean by this, I guess it references conversations you have had with Dan, but I am hoping this means that LL is "still working on it" and that my work won't be destroyed?

As is becoming all too typical in Second Life, the thing that really bugs me about this is the abolute total lack of communication on the part of LL.

Here is a change that they made that affects the basic building blocks of the game, but if I did not read the forums and did not happen to read a part of the thread that you and Michi started, I would not even be aware of it. From what I have read since I posted this morning all I can see is:

- The torus was changed with no announcement.

- Only because you complained was it even changed back at all.

- They did not change it back to the way it was originally however.

- No Linden has apologised or mentioned that content might have been broken.

- No Linden has explained WHY they felt the need to change the torus in the first place.

- No Linden has talked to us about what their plans are for the future of the torus

- No Linden has said whether the broken content will be restored or not.

As users I feel we are more and more being simply left in the dark, run over as it were by the steamroller of ill-concieved developement at LL. HOw many frustrated builders are dealing with this in Second Life right now, unaware that the problem is not them but the fact that LL has changed the gorund rules sort of speak?

Truly unfair and "bad form" if you ask me (no pun intended).

When the path cut of a torus is 0.0 to 1.0, and none of the other parameters have been messed with, then you get a seamless surface, what I called a "closed" torus. When you change the cut this is no longer true, and the current torus mesh algorithm has the end circle, and any cross-section circle forced to be drawn at full detail (the "circle" is in fact a polygon with 24 sides).

In contrast, for a closed torus, the cross-section circle can be a polygon with fewer than 24 sides: 15, 9 or even 6.

One problem with this system, that you've hit, is that just because the path cut is 0.0 to 1.0 doesn't necessarily mean that you can't see that end circle, and it looks horrible when it has 6 sides. If the torus is twisted or tapered, or the radius delta changed, then you see the end circle. By the look of your chair you are using radius delta to get the curl.

The "two half tori" solution should work... I think you thought I meant to take a half by using profile cuts. Try doing it with path cuts instead.

Yes, I agree, it's not great to be messing about with content and then seeing if people notice. However, it does reasonably quickly tell one if people are impacted by changes that are being made.

I was using torii to make bamboo, it was messing up due to some 'popping' when the LOD kicked in, causing the bamboo to break at the joints. I bug reported it and to Torley as well, and it got corrected 2 updates ago.

This recent update reverted it back and actually managed to make it worse. I'm wondering why they need to mess with the LOD for torii.

Framerate I assume. Though getting the number of sides on the circles to powers of two would help with seams lining up nicely when viewed from a distance. That's some messing I'd welcome.

Actually, I noticed there is a noticeable pause now (about quarter second or less) when it switches LOD while zooming onto several spheres and torii.

It may have helped with framerates, but I'm more annoyed with the slight pause when zooming in and out while building. Not sure if anyone else experiences this.

The LOD engine has been very sluggish since they started tinkering with it around 1.6 or 1.7

Me understand now.

Yes this is exactly what I was doing (radius delta). So it seems that this is yet another "optimisation" they are trying out, possibly because of all the trouble lately with geometry even rendering at all. It seems the solution is that they should change the code to not optimise the mesh if the radius delta, twist, or taper has been changed as well, but then that is not much of an optimisation and I can see why they are trying hard not to do that.

The thing that I don't understand is that on a torus like this - even without changing the radius delta - it significantly alters the overall size and shape of the torus. I will test it tonight but I am reasonably sure that even without the delta numbers and even without seeing the end circles, the same effect would be there. One "edge" of the torus would still be flat and the overall width would still be reduced by a few percent.

Doh!

Yes of course.

I still disagree about the manner in which these changes are being made however. Communication with the actual users of the software might be a better approach. Also I would argue that the majority of the optimisations they have been making have had serious impact not only on content but on the user experience of the game as well.

I remember just last year when people used to get upset about the 'breaking of immersion" for instance when textures did not arrive right away and all you got was geometry. Now, most users wait for full minutes even for the geometry to arrive after tele-porting somewhere and we all accept this as "standard" now.

The actual user experience of playing SL has dropped quite substantially in quality IMO, mostly due to this rush to "optimisation." The only speed improvements of any note were when they changed the actual code base and the overall design not just throttled back on the server routines.

if our ladies did not carry around 255 tori on their heads maybe such optimizations would not be necessary.... lol but i know I know prim hair is purty... I agree....

So this is a bummer...


Troy

Yes, it would. I think that if the number of sides on the cross-section circle were a multiple of 4, then there would be a vertex rather than a flat edge at the "widest part" of the circle, and so the width would be correct. If we get powers of 2 then this would happen.

In any case the look of the torus is changed some, but I suspect in the majority of cases it doesn't matter much because it isn't necessary to match up the vertices with something else. If we can get away with drawing tori with 6 sided "circles" rather than 24 sided then we are saving drawing a large number of polygons, which presumably would speed things up quite a bit.

Agreed.

The solution would then be *either* powers of two (if that does indeed always give us a vertex on the edge), or removing the optimisation for everything except completely closed, non-tapered, non twisted, non-anything tori. Which is only a small number of tori, and thus not much of an improvement.

I wonder how long before anyone at home base says what they are intending on this front or whether my content is still going to be broken? It's certainly hard to know what to do without any official feedback on the matter.

Any Lindens out there that wish to comment?

I suspect we are in the aftermath of tradeoff wars.

The two contentious sides being rapid, immediate immersion -vs- sim performance.

Used to be, you got things served much faster but when anyone entered the sim, there was a huuuuuge lag spike as the sim took care of their needs.

Now, we wait-wait-wait but are not brought to a standstill when people arrive (as much) and the image cache doesn't make a sim thrash until restarted quite so regularly.

As for the rendering, I suspect all the clientside work is being done just to handle a world with a lot more people and content in it - to retain users that don't have insanely fast computers. Just a guess.

This is a fair assessment I think, but I would argue that there seems to be something definitely quite different (at least to me) these last few months.

Myself and most of the people I talk to have been arriving in completely blank sims a lot lately and that never happened until quite recently.

It also used to be, that if things were taking time ressing or the sim was slow that it showed up in the numbers like time dilation, FPS, ping and packet loss.

More and more lately I arrive in a sim and I am surrounded by green dots on the mini-map, yet to my eyes I am standing alone on an empty plain. The numbers all show excellent results, high FPS, low ping times, no time dilation, excellent script performance, no packet loss to speak of, etc...

Yet one can stand there for full minutes sometimes and still have only the occasional avatar or prim appear. Sometimes I get so bored waiting I just TP somewhere else.

Being not so technical minded, I don't know what is causing it, but there is something they have done in the last few updates that really changed things for the worse. As with most things in SL we will likely never really know, so all one can do is simply shrug and hope that the Lindens (Gods?) fix whatever it is they broke.

I think that is my major problem with the game nowadays, is that as a control freak it's very very hard to play a game where things just randomly screw up on such a regular basis with no real input or control on one's own part that will ever affect anything.

I don't suppose I will ever be happy again until the game is finally open sourced.

Or it could just be the population increase.

*Sim* performance has nothing to do with LOD changes. That's client performance. What bugs me, I guess, is that LOD keeps being reduced (or 'optimized') when in reality, entry level systems are getting faster....

I'm hoping that LL is starting to realize that even 'slight' LOD/tesselation changes tend to break a lot of in-world content... People use the properties of the prims they're given to the best of their abilities... sometimes that means viewing them as a set of polys, and not as the ideal of the primitive shape.

I hope there is an answer to this, soon, too. Primitives, unfortunately for the sake of change, are pretty entrenched in the world... Tweaking them should be done minimally if at all... Every time a 'slight' change was slipped in, the residency -has- noticed because it -has- broken content.

It looks like you have run into the build tool limits being enforced on rendering (or some such).

I have never had good luck with getting LL to undo changes they make to the mesh. I have always been a proponent of Prim Torture (I would actually like it if I didn't have to torture the prims to set the hidden attributes: make the attributes visable). Anyway, it seems every few releases they change the mesh in ways that are less then friendly to content.

A few revisions back they started enforcing the current build tool limits on rendering, which broke some of my art work that had been created before the build tool limits, and i have ever since been getting IM's from customers wondering what happened to the art they purchased. I informed LL, I sent a bug report, I talked to a bug hunter in-world, as you can surmise NOTHING HAPPENED. This isn't the first time. I reported a bug back in the summer of '04 that effected the rendering of all Torii shapes (torus, tube, sphere, ring (though rings came later)). It wasn't until I beat it over the head of a dev during the preview of 1.7 did it actually get any attention. I was very lucky to have run into a dev working on the graphics engine, as a result, it got fixed.

For a long time llSetPrimitiveParams was disable for attachments, here is the back story. Back in 1.3 they introduced llSetPrimitiveParams. Though my work and the work of others it was discovered that you could crash the client or sim with llSetPrimitiveParams. The 'solution' was to just unlink the bad prim and delete it. Of course this couldn't be done with attachments; so they axed the entire function for attachments. The root problem was that in some situations it was possible to cause a divide-by-zero. Neither the sim nor client at first were able to catch this (so they would just crash, instantly). As time has progressed both sim & client software have become resistant to prim-based crashes. The turnaround time on these crashes is very fast; to the point I haven't seen one in maybe 4 major revisions. A few revisions back, they quietly re-enabled llSetPrimitiveParams on attachments. What solution had they found? They made the sim & client software more robust. Why they didn't do this years earlier? Your guess is as good as mine.

History has show LL's attitude towards bugs has been: when bugs pop up in features, remove the features and only maybe years later fix the bugs.
I'm sorry if it sounds like I'm jaded but I've got reason.

The build too limits are for idiots who get confused by complex shapes. They were put in place to keep idiots from making complex shapes. They should not be used to keep complex shapes from rendering.

So I propose a check-box or hidden attribute(there are allot of hidden attributes) "Remove Build Tool Limits".

There have been numerous changes to mesh rendering over the years. The rule for revisions that limit content is this: They never get reverted. Only once every other blue moon is there an exception to this rule.

(i put a redirect in the "Current Version Feedback" forum)

This might be related to an issue that others have been seeing wtih their Network utilization. Esentially, they have the Network slider in SL turned up, but the client seems to think that it has been slid as low as possible.

The bandaid for this problem is to fiddle with the slider just a bit (i.e. move it a notch or two from where you normally have it) in order to 'remind' the client what it should be. I've found that if I am not getting any new textures, or stuff is just not appearing, that doing this will knock things loose and get data moving again. It's a pain, but I haven't been waiting around an unrezzed sim nearly as much as I was before using this trick.