Drongle McMahon

"I've made LODs for the 3rd and 4th, but never for the 2nd, as it is pointless and saves you nothing." That all depends on the object size (details here). Below 5m radius, the effect of 2nd LOD is small, compared with the lower LODs, but between 10 and 30m the second LOD is by far the dominant influence and the lowest two LODs have no influence at all.

Ah yes. I forgot about glass. I nerver had more than one thing inside. So for those, I simply apply the inside texture to everything (ie no face selection), and then apply the remaining accessible ones with face selection, as usual.

Why? Generally, if part is hidden from view, then I can't think of any reason to edit it (since the only editing you can do is changing the texture). There is one notable exception - when you are using hidden triangles to store textures used at the lower LODs bu not visible on the high LOD. In that case, the SL face carrying that texture will be visible and selectable at the lowest LOD. To get at that without being too far away, just set RenderVolumeLODFactor to zero (Show Debug Settings in the Advanced menu). You might have to do a quick out-in zoom to get the LOD to switch, but usuall;y not. If there are faces only accessible at other LODs, you can find intermediate settings where that cause tose LODs to be shown. You can also use scripts to change the diffuse textures, but not normal and specular maps (yet).

Am I correct there? Yes. See the limits wiki entry, Lots of good stuff there, although some may not not be accurate. For example, the 64k vertex limit per mesh in the table is untrue. (Nal added the correct information beneath).

Difficult to say without some more information. What you describe is what you get if you upload a collada file with empty geometry (eg an empty object from Blender). Same thing for an empty collada file, which you get if you export "Only selected" with no object selected (Blender again). So there must be something that is stopping the upload recognising anything, even for the high LOD. First thing is to ask what software you are using, then some more details about the object(s). A quick way to check the dae file is to import it back into your software, if it has that facility. Another thing that might help is to inactivate the slm files, which are left next to the dae file by the uploader. These keep settings from the previous upload and that can sometimes create problems. Either delete the slm files, or make sure you click the "Clear Setting & Reset Form" button for each upload, or disable permanently by setting "MeshImportUseSLM" to false using Advanced->Show Debug Settings.

"... I am sure it will help some folks along the way." I second that. Aquila is very good at explaining things in ways people can understand easily. This contrasts starkly with my explanations that often leave people more puzzled than they were to start with. Thank you Aquila. Are you going to make a collection of your posts available somewhere?

You must have at least one UV map that has all the materials, because SL will only import one map. Aquila's post here and Gaia's tutorial explain how you can still use the full UV space for each material (Aquila) and bake the textures to different images although you have one UV map, where the UV islands for different materials overlap (Gaia). What Blender are you using? I am still using 2.66, where the "Only Active UV Layer" doesn't work* unless you have the first UV map in the list selected. This is because it tells the <polylist> tags to use the selected map, but still only exports the first. That leaves the reference in the <polylist> pointing to a map that isn't there. That produces the know effect of a garbled random UV map. I thought it was fixed in later versions. If you have the multi-material map first in the list and have it selected when you export, this will work ok even in 2.66. If you turn the "Only Active UV Layer" option off, the collada does contain both (or more) UV maps, so that the references do now point to something valid, but the <polylist> now refers to both. SL doesn't know which one to use, so it selects (I think, for two at least) the laast one. This will not work as you expect unless that's the one you wanted. * {Gaia; this is the one I sent you the IM about,a while ago}

That's the same sort of thing I am finding. I did a series of toruses with major and/or minor segment ncounts varying from 3 to 24. Too many results to list here, and it's very unclear what the effect is, as some combinations are more resistant to the LOD gemeration than others, and it's not simply regular. It is certainly only happening when there's no UV map or the map is collapsed to a single point, and only when it's smooth shading. It is also very dependent on the closed toroidal geometry. If you split even one vertex (on some of them at least), the effect goes away. That spoils the smooth shading, but where that's tolerable, that gives a work-around. Best of course is (a) always unwrap (b) make your own LODs. I am completely puzzles as to how having the UV map stops the effect. I suppose the GLOD functions are trying to make the UV map fit as well as the geometry, but then you would think it was easy if all vertices mapped to the same UV point - they still will in the LOD mesh. Can't see how the flat shading escapes it either. Oh well.... On reflection, I think we have to regard this as an unavoidable quirk of the GLOD library with un-uv-mapped toroidal geometry, and therefore expected behavior and not a bug. The work arounds are easy and really required for best practice anyway. It was an interesting find, all the same.

Here's a picture of the auto-generated lowest LOD of the skeleton inworld for (left-to-right): Smooth shaded, point-collapsed UV map; Smooth shaded, normal UV map; Flat shaded, point-collapsed UV map. Something has gone badly wrong with the LOD generator.

No need for the daes,,,. I get similar results with Blender 2.66a. I did some experiments with one of your rings. It seems to be about the missing UV map. This is very odd, and I think it's new behavior. With no UV map, or with a UV map collapsed to one point, it would not reduce the vertex/triangles in the autoLOD meshes. With even two points in the UV map (ie half collapsed to one point, the other half to another point) it did the normal reduction. Now maybe a clue about where this came from... There used to be a bug (can't find the jira) where a missing UV map caused the uploader to used uninitialised data, giving random UV maps, so a model could be textured differently each time it was uploaded. Now I find that each time I upload my test model for this, it all gets textured with the same pixel. So maybe they fixed that to use all zeroes instead of random data. That would explain why it behaves the same as with the UV deliberately collapsed to a point. That doesn't explain why the single-point UV map should cause the GLOD LOD generator to fail to do anything, but it looks like this must be the case. Sure enough, If I make a UV map for your skeleton the autoLOD works as expected. So that's what you need to do. If I then collapse the UV map to a point, it goes back to the same numbers as before adding the UV map. I think they should make a missing UV map an error that aborts the upload, but if not then they should fix this effect on the LOD generator. I will do a jira for this, using my oddly mapped versions of your ring. ETA - uh-oh, not quite that simple. My model for the random UV bug (a subdivided cube transfomed to a sphere) doesn't show the LOD count effect. When it.s collapsed to a point, it still generates the expected LODs. That's like some of the skeleton, I guess, where some of the geometry gets reduced but then it hits the stop. So it;s not just the missing UV. It's a combination of that with some aspect of the geometry (and the smooth shading!). Will need more experiments before a jira, to try and identfy what aspect.

Can you give use the dae files for the single ring for smooth and flat?

"I'd simply inform my clients that I need them to give me access to an avatar that they own, which I would then use for uploading/building for their projects. (Some clients insist on this, anyway, so it shouldn't be a big deal.) That way, I could fulfill my obligations without having to agree to the new TOS myself." {Chosen Few} Slightly puzzled as to how that works ... 1. You are making the work for hire, so the client gets the IP. Using their Alt, you are acting as the agent of the client, so that the client is the "you" of the ToS, as far as both the affirmation of right to grant license and the identity of the uploader is concerned. LL gets the broad license because the uploading account accepted the ToS. Thhis is consistent with RL because the client does have the right to grant the license (it's their IP) and they accepted the ToS using the Alt account. 2. You are making the work for hire, so the client gets the IP. Using thier Alt, it is you, not they, who upload the content. While you (RL person) have not accepted the ToS, the act of uploading does not give LL the new rights, neither have you affirmed that you could grant them. The Client still has all the IP. They did accept the ToS, but they didn't upload the content. From your uploading, LL gets only the rights from the old ToS. The Client didn't upload. Therefore LL gets cno further rights (unless they count as the publisher*, having hired you?) *From ToS: ' "User Content" means any Content that a user of the Service has uploaded, published, or submitted to or through the Servers, Websites or other areas of the Service.' Is it one of these, or something different? It all comes down to the interpretation of "you" in the ToS. I assumed (at first; now I an just confused) it meant the RL person using the account when it was accepted. Or does it mean the RL person who owns the account; or either of those only when that RL person is using the active account when the ToS is accepted; or anyone using the active account; or anyone ever using the account? I don't see anything in the ToS explaining who "you" is. If my assumotion was right, that it was the RL person using the account when it was used to accept the account (thus applying also to any Alts), then there is still nothing to say whether it should apply by proxy to any other RL person using that account. Maybe your lawyer will feel kind enough to elighten us on that issue too? I did re-read the ToS looking for anything that was against the use of Alts by other people (to act as the main's agent, or whatever), and I saw is nothing against it.Only perhaps that, by giving you access, the owner of the Alt may accept responsibilty for your actions while using it.

"Link not behaving" ... try removing one"t" from "htttp".

"You agree as a rl person for the account your are loging in and clicking on the "agree button". You can disagree with one other alt and agree with another account." You can quite reasonably assert that view. I guess the important thing is how LL uses the information. If they record the agreement per account, and then use that to determine which content they can use the new license for and which they can't, then that is the effect. That might well be how it operates to begin with. However, suppose they accidentally used some content uploaded by you using the second, non-agreeing* account, and you chose to take legal action against them (or just a DMCA takedown). You have to do that as an RL IP holder. Now they can say that you agreed, even though you used only one of multiple Alt accounts to do so. I'm not saying that would happen, just that it appears to me to be within the scope of the ToS as written. *I say "non-agreeing" rather than "disagreeing" because you can't actually express disagreement (unless you write to LL explicitly doing so). Failing to accept seems likely to be because you disagree, but isn't necessarily so. You could have lost interest in using this Alt in SL for other reasons.

"then why does each of my ALTs have to review and agree to the TOS?" Because it's easier for them that way? As long as they don't have to make the links, even if they could. No doubt you are right about how difficult it might be for them to prove a RL association, but as I said, I don't think they have to. They want the rights, and they want to be able to say that the uploader affirmed they had the right to confer them. That's all they need. If it comes up in a dispute with you, then you have to give them RL data to proceed anyway. If it's a third party, they can just say it's the user's fault, they made the affirmation, here's all the information we have, you go and find them. So I don't see that they need the link, but they do need the agreement to be with a RL person, otherwise they can't claim a RL person made the affirmation. It's no use blaming the avatar because that only exists on their system. So it would still be them. At least, that's how I imagine it is. I would be glad to be wrong there.

No, but I didn't use my av name either, and LL knows my real name. I don't see how that matters though. If the agreement is not with the RL person controlling th av, then it couldn't carry any legal weight. You can't sue an av in a RL court. There is nothing in the ToS saying it applies only to the user content associated with the account from which you accept it. It just says "you user content". It is certainly my guess that the "you" here means you, the RL person, not you, the av. Otherwise it would say something like "this account". Whether LL knows your real name at the time is irrelevant, although it might affect the ease with which they could take action against you. However, they don't want to take action against you. They just want to deflect actions that you or others may take against them. I will agree that the ToS should explicitly clarify that, one way or the other, but, as in so many other ways, it seems clarity is not among the objectives of its authors. However.... "User Content" means any Content that a user of the Service has uploaded, published, or submitted to or through the Servers, Websites or other areas of the Service. Nothing there about association with one account, or that "the user" does not mean the RL person. ETA - I would say the av is part of the service, not the user of the service.

"create an alt and have the content free Alt account become a member" Interesting idea, but does it work? Surely, if it means anything, the ToS has to be accepted by a RL person, not a fictitious entity. In that case, would it not effectivly apply to all the Alts controlled by that person?

The fact, if true, that the wording is the result of indolent copying instead of due care in composition, doesn't really have much importance. It's the effects that matter. However, the implication that it is the result of laziness and lack of attention to the specific needs of SL is much more revealing bof the attitude of the authors to the concerns of their customers than is a letter of weightless hand-waving reassurances sent to bloggers. "Oh, don't waste time thinking about it. Just find the most exploitative terms you can out there, and copy them. We can always pretend we don't really mean it."

So, has "LISavers" gone? Or maybe "LILO" ... oh no, that went long ago! "LOLI"?

Possibly - It sounds as if you are seeing the effects of single-sided rendering. In Blender 3D view, by default, everything is rendered 2-sided. In SL, everything is rendered 1-sided. So in SL, one side of every mesh face is transparent. If you want to see the difference in Blender, check "Backface Culling" in the "Display" section of the Properties panel on the right of the 3D view. If the wrong side is rendered visible, then you probably have to invert the normals of the affected faces. That can be done by selecting the faces then using Mesh->Normals->Flip Normals.

Does anyone know of a good diff utility that can monitor a web page every hour and put out an alarm whenever there is a change?

'Linden Lab’s right to “re-sell or otherwise alter abandoned parcels of SL’s mainland,” including, if and to the extent necessary, any user-created content incorporated into such parcels." ' Yes. That puzzled me too. How on earth could it ever be "necessary", since they can undoubtedly always remove all user content, including even terrain maps of islands? The only case I could think of was when they agree to transfer the land and contents of a user who has died, if the will so requested. Even then, that wouldn't be selling.

I see no reason to disagree with Chose on this issue. Chosen has described the position of people who cannot accept the ToS because they uploaded work for hire, for which they are not the copyright holder and therefore do not have the right to grant the rights demanded, and cannot affirm that they have that right. The number of people in that position is probably small, but there is another, much larger, class of user who is equally prevented from accepting the ToS. That is anyone who ever uploaded anything (texture, model, sound,...) which was not their own creation or in the public domain. For anything else, they don't have the right to grant the demanded license. Therefore they cannot affirm that they do, which they would be doing if they acceptd the ToS. I am pretty sure there will be hundreds, if not thousands of users in this situation. I would be surprised if a substantial proportion did not make the mistake of assuming it was not retrospective, and accepted the ToS, thus making a false affirmation. Given that this was quite forseeable in the absence of any explicit statement about the retroactive application, which could easily have been included, I think this is where the ToS is weakest. Even so, it doesn't look like much of a weakness to me.

I went and had a look at your houses at Ven River. I noticed a lot of external woodwork, windows and fences that must be sculpties, because they distorted badly at first LOD switch, quite visible with RenderVolumeLODFactor=2 (default for high graphics). So that's where I would start. Replacing these with good mesh, with single-plane alpha lowest-LOD, can eliminate LOD problems as well as and lowering LI. Have to do the whole lot, because linking sculpties to mesh will blow up the LI. They would be the same as sculpties as far as modifiability goes. Maybe get rid of sculpties first, then think about replacing walls and such with modular mesh?

And were it not for unions we would still have factories like those in Bangladesh, the ones our businesses prefer to use. There's plenty of unemployed, so we can afford to burn a few. I'm not going to defend excessive and ill-directed politicising that has badly corrupted modern unions. But I will defend the historic and indispensible contributions of unions in establishment of reasonable treatment of employees in a modern society. In that, they were indeed the driving force. All kinds of people do destructive things out of greed when they find themselves with too much power, but whose greed has done us more harm in recent decades, the unionised royal mail worker or the ununionised investment bank gambler? It is singling out one group and scapegoating them that always corrupts politics on either side. I'm going to stop at that. Not the right place for political rhetoric.