Drongle McMahon

Must be a version thing then. I'm still using 2.66a and got the opposite result. The UV map list is in the "UV Maps" section of the "Object properties" tab (triangle icon) of the "Properties" panel/editor (which I keep on the right). Here's a picture. When I combined two meshes esch with one UV map (different names), the combined mesh had only one map in the list. By "index" I mean the position it comes in the list (which is most likely the order they are in memory). So I am guessing what happens if each mesh had more than one map. I'll try it and add result. ETA - Yes. With two objects, each with two UV maps, and all four maps with different names, joining them left just two maps with the names from the last selected mesh (ie the one with the brighter selection highlight). The first had both of the first listed maps, superimposed, and the second had both of the second listed maps. So maps with the same index were overlayed/combined.

"The reason you ended up with 3 uv's is because each object had a unique name assigned to their UV when you combined them" I thought that too, but when I tried it, there was only a single map, with one of the names and the two mappings overlapped. The other name was just lost. I guess it combines maps with the same index in the lists of the joined meshes. So it must be something more than that.

I don't know one, but how did those you showed get their names? Maybe there's a clue there?

I guess the staples are separate objects? There is a minimum dimension of 0.01m (1cm). If you upload an object with a smaller dimension, it will be stretched to that size. The solution here is to make the staples part of the same object as the rest. If you ever really need such small objects, then you can add some extra geometry to fill the space and texture it with default transparent texture so that it's not visible.

I don't know how you got three. Did you start out with them as separate objects? SL will only use one map for one object; so you do have to have all the materials in one UV map. That doesn't mean you have to have the UVs for different materials non-overlapping. They can overlap freely, as they won't be used together. In other words, unwrap each material separately, using the whole UV area for each (and doing any futher overlapping you want, of course). Now when you select everything, the uv edit view will show the overlapping maps, but when you select by material in the 3D view, the uv view will show just the map for that material (as long as synch select is off). I don't know a way to re-order the UV maps in the list. So unless you get the correct mapping in the top one, you will have to delete the others (in a copy, if you still need them). I think Aquila recently did a nice illustration of using one map with overlapping for different materials.

"...you only get a "one pixel" color, not a tiled pattern." That is the most common effect. It appears that the uploader uses uninitialised memory to make the UV map. If that's all zeroes, you get the one-pixel result. In other cases, you get ramdom mapping (unless they changed it recently. It can be different each time you upload. Depends what happens to be in the referenced memory. Here's a pic. Top two have no UV map.

Could it be Multiple UV maps?

I don't understand what you mean by "tiled" vs "mapped". Pictures might explain. Also, I think you need to tell us what software you are using. One possibility is that you have two different UV maps in the 3D program and the wrong one is being used in SL.

The UV map is uploaded as part of the dae file. It is a list of where each 3D vertex is on the 2D texture plane. That tells the renderer how to stretch an applied texture over the mesh surface. Using the uploaded UV map IS the default mapping for mesh. It is possible to make a collada (dae) file without UV map data. In that case the outcome when you apply a texture is unpredictable. The texture is a different matter. That does not get included in the colladafile, although it can be referenced there. You can upload textures at the same time as the collada file, but I don't recommend that for several reasons, including the fact that it gets uploaded, and you pay a charge, each time you change the mesh. Also, multiple copies accumulate in unexpected places in your inventory. So I recommend uploading textures separately and applying them inworld. That way you can also use local textures, making any necessary changes before you pay the upload fee.

Looks like you are right. I hadn't looked at a sculpty since early mesh beta! When did that change? I see there are some un-mesh-like effects on normal prims too. In fact the default torus CH (that is the phsyics shape of a sculpty) is not constant with size, like mesh CH, but has a step increase at 5m and 25m. So it's 1.8 if it's small, but more when it'sbigger than those sizes. Hmm. Is that documented anywhere? It doesn't happen with the sculpty, which stays at 1.8! I was assuming that sculpties behaved like other prims when they were converted to the new accounting. Those generally (i.e. when they are not compatible with Havok primitives) get triangle-based physics shapes, which you can see in the physics shape view, and which can have very high physics weights that increase with decreasing size. For some reason, sculpties appear to retain their default shape. So the accounting is changed, but the shape isn't.

Except that the download weight of a sculpty is now capped at 2.0, while its physics weight is uncapped. Consequently this sort of problem is probably more likely to involve physics weights. However, setting to Convex hull will not always solve the problem*. If a sculpty has a lot of convex curved surfaces, which is common, the Convex hull can still have a large physics weight. The advantage is that it isn't size dependent, so that it doesn't explode, like the triangle-based weight does, if the object is small. *But setting it to "None" will!

If you are using Blender, you can see the effect of one-sided rendering by turning on 'Backface Culling' in the 'Display' section of the Properties panel to the right of the 3D view.

Yes. I can agree that the intended results were most likely developed by careful and rational consideration. However, the results actually realised could perhaps have benefited from some more thorough investigation.

"I'm sure Falcon Linden did some excessive research before he came up with the physics weight calculation algorithm." I'm not so sure, Arton. Have you forgotten my threads on triangle-based physics weights? Especially episodes three and four. The observations there are that the order of triangles in the collada file, and even the order of vertices within the triangles, can drastically and unpredictably affect the physics weight for identical geometries. I suppose the triangle and vertex order could drastically affect the work needed by the engine, so that the numbers do indeed reflect that, but if that is the case then either the SL server or the engine should optimise the order before using the shapes!

There are all sorts of different answers to you questions, depending on the knowledge and the priorities of the person making the house. There are many threads in this forum discussing various aspects of the questions. Most of all, you need to learn and experiment. Most of all, you need to understand levels of detail, physics shapes and UV mapping. Try out simple things first, usung the beta grid so that you don't have to pay for uploading.

While looking at the conditions where this artefact happens, to prepare a jira, I found a different workaround that doesn't give the hard edges. You just make the inside and outside of the glass different materials. You can still set them up with the same texture and specular settings. Here is a picture, left with one material, right with a separate material inside. I am guessing this is a manifestation of the alpha sorting bug. It seems to happen only where all four alpha surfaces overlap. I think it depends on the order the triangles are presented to opengl, and that the viewer sends all triangles for one material, then all for the next material. (That doesn't seem to explain the effect of the edge split though.)

The Blender option is "Sort by Object name". It was put in by the SL Blender gang especially for SL. No idea if the Maya exporter has an equivalent, or some other way of ordering the <geometry> tags in the Collada file. You can look at the files manually. Search for "<geometry" and write down the order of the objects (I am assuming you have given them recognisable names). Then do the same with the files fo the other LODs.

Looks to me like problem [1], multiple mesh objects with the wrong ones being associated across the different LODs. Can you say whether there are multiple objects? (I don't know the Maya terminology - it means things which have different <instance_geometry> tags in the collada file). The uploader just uses the order the meshes appear in the Collada file to decide which goes with which at each LOD. So the order of the objects has to be the same at each LOD. In Blender, you can achieve this by alphabetical ordering of object names and choosing the right export option. I don't know how the order is controlled in Maya. Maybe someone else can tell you.

Ttwo questions: [1] Is your model one mesh object or several? [2] Are the bounding boxes of your LOD meshes the same as the corresponding high LOD meshes? If it is multiple objects, ending up in SL as a linkset, the LOD meshes can get associated with the wrong high LOD meshes unless they are in the same order in each exported LOD file. The LOD meshes get stretched or squashed to make their bounding boxes fit those of the high LOD meshes. So if they start out different, the low LOD meshes will be distorted. This is even worse if your objects have different rotations and/or scaling that appear end up in the collada node tags (in Blender, this means Object mode rotations/scaling), as the bouding box is that before these are applied. Otherwise, I will wait for the pictures....You can get good equal-scale inworld pictures of the LOD meshes by lowering RendeVolumeLODFactor until the LOD switches, although the uploader previews may be enough. PS. Or is it just the textures that are messed up? The V maps of the LODs have to be consistent to get consistent texturing.

I think your point about DMCA filings is interesting. You still own the copyright, but (I understand) you have given LL the new broad license, which explicitly includes the right to sublicense. Now if you file a DMCA notice against someone who has copybotted your stuff, could LL simply decide to sublicense the stolen content to the theif, thereby relieving themselves of the need to take down the content? Of course they don't have to, but it would appear that they have given themselves the means of ignoring DMCAs from anyone who has agreed to the ToS, although they would still have to act on filings from others. I don't know. I am only guessing because I am not a lawyer.

If you use the Edge split modifier, with explicitly marked sharp edges instead of an angle setting, you have the greatest possible control of which edges are sharp. It's possible you might be able to get what you want bthat way. However, since I don't inderstand the source of the shading artefact, I don't know what will and what will not work. I thinkn the artefact should be cinsidered a bug anyway, If we can get it more acurately tied down, a jira might be worth trying.

Another thing to note: It's not the angle that counts. Although there is a checkbox next to the Crease angle spinner, it doesn't do what you would expect. It only changes whether you can change the spinner. Even if you check it, if you don't also change the spinner, you will not get generated normals. If you change it to 75.1 and then back to 75.0, you will get the generated normals and lose the artefact, even if you then uncheck the checkbox! Crazy or what? You can see whether the generate normals is active by looking at the vertex count. When some of the edges get sharpened (which is what this does), the vertex count increases. Then it doesn't go back when you unxheck the box!!! This is just not how it should be. Originally there was no checkbox, and the function was activated only by changing the angle. A checkbox was requested, and they put it in, but it's not working as it should - turning the function on and off. It's just turning the spinner on and off!!! This was leadimng you to the wrong conclusion. When you left it at the default 75.0, it was not using it at all, even though you checked the box. I will have to make a new jira! (Done).

Yes. Generate normals has a similar effect to using the edge split modifier. So i'ts something to do with the interpolation of normals around the edges of vthe glass. Why that should have the effect so far from the edge, I can't imagine. It seems to only happen with the double-walled object. Making a glass with no inside (horrible of course) there was none of this artefact. ETA - note, it is "Crease", not "Grease".

Try applying edge split modifier. It worked for me. Not sur why.

RenderVolumeLODFactor (rvlf) can be set in Advanced->Show debug settings. It is also changed by the object detail slider. The default is 1.125, except for Ultra quality where it is 2.0. Many people now set it to 4.0, to avoid seeing ugly LODs of many sculpts. So that's why I chose those values.