Drongle McMahon

Ah. Where are the colours coming from? Are they just material colours, or are you applying and uploading textures? If it's the latter, it could be a UV mapping issue. If not, then I don't know. I never upload textures with the model (for a number of good reasons*), so I don't know how well the uploader preview deals with texturing/colouring so may objects at once. You might get something different when you complete the upload and observe inworld. Have you done that? (You can use the Aditi grid to avoid costs). You could see if joining helps here, but there will be texturing anomalies if you end up with more than 21844 triangles in any material. *1) paying both mesh and texture fee every time you change either. 2) proliferation of hidden copies of textures in inventory. 3) redundant repet uploads (and fees) for general-pupose textures. 4) reports of other problems here.

What exactly is it you see as the problem? Just the upload fee? Otherwise, the preview in the uploader looks correct to me, apart from being rotated (which Gaia's suggestion would fix - or perhaps you rotated the preview?). However, the numbers in the Blender picture say there are 135 objects, with a total of 50090 triangles. Now I can't tell whether all those objects are in the exported file, but from those where I can see the selection outline, it looks like they may be. If that is the case, then 117 L$ seems a very low fee for uploading 135 objects. There is no reason I can think of why you would want this to consist of so many objects, ot so many triangles. The result will be high LI as well as high upload fee and an excessive amount of work for your GPU. You can sinply combine all the objects into one by selecting them all and doing Object->Join. You can use up to eight materials for the parts of the joined mesh that will have different textures. You are likely to run into other problems is any of the materials has more than 21844 triangles. But the triangle count should anyway be drastically reduced. You clearly have a level of detail that is far smaller than it will be possible to see in SL. Without being able to see more of the detail, it's difficult to say where the reduction is best, but you can do a lot of reduction by selecting edge loops and using Delete->Dissolve. (Do one each of the identical parts, then duplicate it to replace the others, to save work). One common explanation for excessive triangle counts is the use of subdivision to obtain smooth-looking surfaces. This is hugely wasteful. Instead, many fewer faces should be set to use smooth shading, to achieve the same effect. Sharp edges can be kept where needed by using the edge-split modifier. Smooth shading will reduce the LI a great deal even before the triangle count is then loweredm because vertices on sharp edhes get duplicated in the uploader. In you third post, it looks as if you have some inverted normals. To see this effect in Blender, check the "Backface Culling" option in the Display section of the Properties panel in the 3D view. This will make the faces one-sided, as they always are in SL. Select the offending faces and do Mesh->Normals->Flip to get the normals correct.

I want to second your nomination of the atrocious inworld search as the foremost failing of SL. The destruction of the previously usable serach is the sole reason my inworld activity has declined to zero (excep on Aditi). If you can't find stuff to do, buy, look at, then you do, but or look at anything and the whoe; thing becomes essentuially pointless. I was left with an occasional bit of building, but then that was stopped by the ToS change. That takes second place though, as building is not so universally important to all residents.

Normal maps (tangent-based) look predominantly blue because the colour of each pixel defines the vector of the normal at that point relative to the tangent. The blue channel is the component perpendicular to the unmodified surface (the default normal), while the read and green define the components in the UV plane. The default normal has RGB values 127,127,255. So it's a light blue. Tinting more or less red or green tilts the normal away from the perpendicular. Here's a picture of a simple normal map (left) and the effect it has on the shading of a flat surface under oblique lighting. (both from normalmap in gimp)

No simple answer.You have to cinsider: (1) Smaller meshes will switch to lower LOD at smaller distances. Depending on the details of the lower LODs, switching of different parts at different distances can be disconcerting. (2) Joining smaller parts will increase their LOD switch distance, and will therefore increase the LI to more than that of the separate parts. (3) Each mesh can only have eight materials. So if you need more, you need separate meshes. You ptobably need to do a lot of experiments to decide which is best, and the choice will depend on how you are going to use the object. When considering LOD switch effects, it may be worth remembering that many viewers wil have the default RenderVolumeLODFactor of 1.125. If what others see is important, it is worth testing with that setting.

Your picture shows some strange shading aroud the top. I think you can mend that by making the top edge sharp. To do that, select the edges around the top and do Mesh->Edges->Mark sharp. Then add the Edge Split modifier, uncheck the Edge Angle box and check the Sharp Edges box. This gives you precise control over which edges are treated as sharp and which are shaded across smoothly. Note that the vertices along the sharp edges are duplicated when you upload (with apply modifiers) which can increase the LI if there are very many. Also, if you combine with a subsurf modifier, the edge split must come after it. Otherwise the split edges will be peeled back from the edges.

Not completely clear, but it sounds as if when you put the texture on you unexpectedly saw the whole texture repeated on parts of the surface, even though the repeats were set to 1. That sounds like a UV mapping problem. If different parts of the mesh surface have overlapping UV mappping, then they will receice the same texture, giving repeated texturing. his can happen if you select and unwrap those surfaces separately instead of all together. It can also happen with some of the projection mapping methods. If the parts with overlapping maps are different materials, then that should be ok, because you are going to apply different textures to each. But if they are all the same material, you will get the repeated texture effect you describe. To make sure whether this is the problem, you could apply this test textures to the mesh and show us the result. (Make sure both repeats are set to 1.)

I don't see why not. In fact there is an even simpler way to add the floor. Just make it completely unattached to the hull, so that its edges are hidden within the double walls of the hull. Of course, the double walls have to be thick enough for that. As far as the subsurf is concerned, there's nothing to stop you using it, as long as no material has more than 21844 triangles (see here), but it will give you needlessly high poly counts, which means high LI and high load on the gpu of anyone looking at it. If you use it and then remove redundant edge loops, it can be quite useful. However, you are advised to use smooth shading instead as far as you can (with the edge split modifier if you need some sharp edges). Direct views of the surfaces will be fine. It's along the edges of the silhouette that smooth shading doesn't help, and that determines how much subdivision you need.

Ah yes. The pinching is the result of adding the floor to a mesh with only one side. The edges along the joint of floor and walls have three faces joining at the same edge. This is one of those "non-manifold" structures that you have to avoid. (You can detect them with Select->Non Manifold). The subsurface algorithm can't deal properly with this structure. If you make the hull with a proper inside (eg: Mesh->Faces->Solidify). You need this to see the inside surfaces anyway. Then remove those parts that you aren't going to see and close the hole with the floor. If you need to have a visible inside below the floor too, then you make that as a separate disconnected sirface. The picture shows these two stages in transverse section, along with your model on the left. These models will not show the same artefact if you add a subsurf modifier, but you will still get other problems to solve with creasing etc. Better to avoid subsurf altogether, As aquila said, you can make a much more polygon-efficient model without it. If you do use subsurf, you can remove a lot of the redundant edge loops with Dissolve.

Not quite sue what you mean. Possibly: Try creasing the edges you want to keep intact (picture; 0.5 in the middle, 1.0 top and bottom), using Mesh->Edges->Edge crease (or shift-E).

If you upload a single dae file with multiple objects, then you can either accept the default phyics shapes (for each object that will be the convex hull of the low LOD visual mesh), or you must specify a physics shape for each one. If they are simple flat walls, that's easy - any smple box will do. Otherwise, you have to make sure the physics shapes are in the same order in the dae file as are the high LOD meshes. Each gets stretched and/or squashed to fit the bounding box of the corresponding high LOD mesh, and the correspondence just depends on the order in the two files. So you can get strange results if the wrong physics mesh gets associated with the wrong visible mesh, which happens if the order is different. There is an alternative approach that lets you use a single physics mesh for the whole thing. To do that, you upload the physics shape separately and link it to the rest of the meshes with the physics mesh as the root. The you set the physics shape type of the physics mesh to "Prim" and all the others to "None", and make the physics mesh invisible. You will have to learn how to make low-weight physics shapes work for convex structures, and as mentioned by Dora, the download weight of the physics mesh may be large and will be added to the overall structure. Generally I don't recommend this approach.

Yes. Too much to learn to put it in one forum post. To encourage you, here is a prim cylinder textured with diffuse, normal (bumpiness) and specu;ar maps. The maps were all made from your picture in a few minutes in Gimp. The normal map used the Normalmap plugin (inverting green channel). Various amounts of blurring ere added in layers, and layer masks were added to make the alpha channels of the normal and specular maps. All derived from your texture. It will take you a lot of experimentation and/or tutorial following, but it's worth it. Of course you gave to have advanced lighting to see the effects, and you have to adjust the 'Glossiness' and 'Environment' soinners to get the efffects you want. ETA added a version of the normal map without alpha channel at the bottom right, because the background showing through obscures what the noamal map really looks like. (The alpha is the specular exponent).

Yes. Could be some wierd material maps. Check that shininess (specular map) and bumpiness (normal map) are set to None, or usng Blank maps.

Indeed, it all depends entirely on the terms of the license you purchased. The far-reaching changes in the LL terms of service made last year caused some third party texture sellers to forbid the uploading of their textures to SL, when they had previously explicitly allowed it. These changes have led to a great deal of confusion and some disagreement about the inplications, for textures, mesh sounds, animations etc. So you will not be alone in taking whatever view you settle on. For myself, it is a matter of great regret that the new terms seem to place such extreme constraints on the use of third party content. I think our purpose here is only to make sure you (and other silent readers) were aware of the issues. The IP questionaire for mesh upload was written before the ToS changes. So it can't really be assumed that it addresses the new issues.

That picture shows only the part (tab) of yje uploader for the visible meshes - you can make four, each with less detail, that are seen as you get further away (LOD meshes). The button you pointed at with the arrow is just to select which one is shown in the preview. It's nothing to do with the physics.The physics is on the next tab. There, you can select one of the visible meshes for the physics, or you can use a completely new one. I am not sure what you have done here. Let me try to explain a bit. There are two ways of using a mesh physics shape. 1. You can use the "Physics" tab of the uploader to add a physics shape mesh. If you don't do that, then the uploader will make a physics shape for you. It will always make the one that gets used if you set the type to Convex hull on the features tab. This is a convex hull for the whole mesh, like a shrink-wrap around it. If your model has several meshes, then each one will get its own convex hull shape. It is made from the low LOD (third) mesh on the first tab (the one you show). If you do tell it to use a sifferent mesh on the Physics tab, then it will use the convex hull of that instead. You can tell it to use one of the four LOD meshes from the first tab, or you can give it a new mesh (as you seem to have done. It will also make another physics shape that you can select by setting the type to "Prim". The other settings on the physics tab control how it does that. If you have multiple mesh onjects in your model, and supply a new physics mesh, then there should be exactly one object in the physics mesh for each object in the visible mesh, and they have to be in the same order. That can cause difficult problems. These kinds of physics shapes are all part of the uploaded visible mesh. 2. (I think this may be what are trying to do) You can upload a model without using the physics tab at all, so that it just has the default "Convex hull" shape (or shapes if there are multiple ,eshes), then separately upload another mesh for the physics shape. You link the physics mesh to the other mesh(es) with the physics mesh as the root (selected first before linking). Then you set the physics shape type of the other, visible meshes to "None" and the physics mesh shape to "Prim", and make the physics mesh invisible ("default transparent" texture). "None" is like using "Phantom" prims with an invsible physics prim, except that the pieces can all remain linked, and it is much better for performance of the physics engine which just ignores the "None" parts. Since the physics is now not part of the mesh, there is no problem associating the parts of multiple-mesh models, nor with fitting the physics shape to the bounding box. So if you do use multiple linked parts, this approach may be easier. If it's true that you are using mthod 2, then your physics mesh should be invisible. So it's UV mapping wouldn't matter at all. Could it be that you were trying to do this, but you put the new mesh in the "Medium" slot as you show in the picture? If you have multiple objects for the visible mesh, but only one in the physics mesh, then you can't use the physics tab to make it part of the model. It will get associated with just one of the visible meshes and it will be squashed to fit it. So in that case you can only use the second approach - completely separate upload (unless you do some horribly complicated stuff). (Now we just need someone :matte-motes-wink: to make a picture that will make this easy to understand:matte-motes-smile:)

I had a look, and I think this is the problem... Because they are all linksets, the LOD (level-of-detail) switches independently for each part, and nearer than they would for the wholw thing in one mes, because they are smaller. Now, your medium LOD model has a UV map that doesn't correspond to the high LOD one. The result is that the texturing is from a different part of the texture when the LOD switches. I am guessing that you just happened to be at the appropriate distances when you saw the texture change because of the LOD switch. If that's right, you are going to have to redo the UV map of the medium (and lower) LOD, so that the corresponding surfaces recieve the same textures as at the high LOD. In more general terms, this object would almost certainly be better as a single mesh (or at least as larger parts) so that the LOD switches at the same distance for the whole thing. This will push up the download weight, but at the moment the server weight is the highest (8, =0.5/mesh), and joining the meshes will reduce that. Go for a very simple low LOD mesh for the whole joined thing to keep the LI down.

Where is it?

Chic, I think there is one exception, the CC0 license. That doesn't even require attribution, and makes no restrictions on any form of redistribution. It's not used very widely, but for example, some sound files from freesound use it (fortunately).

No. I don't think it's likely to have anything to do with physics shapes.

Interesting. Is there anywhere we could inspect the vbridge in it's two states, linked and unlinked? On Aditi, maybe? I'm not sure what the separated pieces are, but my only wild guess is that the affected pillars are accidentally duplicated in the geometry, with one of the duplicates having incorrect UV mappping. Then for some reason, the one that's visible switches when the linkset receives some sort of delayed update.

I second what Kwakelde says. The key is making the mesh UV map(s) in such va way that they can be used with general-pupose textures. Where that is possible, performance saving can be substantial. The problem is that these savings are not immediately obvious in the marketplace or on inspection of the object. So there is no incentive for the profit-oriented creator to do the extra work required. Still, we can encourage and hope, I suppose.

In case you have not already done so, if you are considering uploading purchased content, you might want to read section 2.3 of the ToS very carefully and consider its compatability with the license/terms of the potential purchase.

Ah! If you aren't on a Linden grid, then everything I said about physics could be wrong. The physics is done entirely on the server, and the server code of the LL servers is not open source. So there are certain to be differences with other grids. In fact they may even use different (versions of) physics engines.

Depends to some extent on whether you are using triangle-based (no Analyze) or hull-based (Analyze) shapes. In fact both can be penetrated occasionally, more easily the higher the speed you collide with them. If you use thick shapes, then for hulls (Analyzed) you are unlikely to get through and the physics engine pushes you back out. For triangle-based shapes, if you penetrate the first surface you can get stuck between them! Also, you need to remove the edges of thickened triangle-based shapes because the narrow triangles escalate physics weight horribly. Often triangle-based walls are the cheaper option for physics weight, although their weights are very unpredictable (depend on triangle and vertex order in the dae file). However, hull-based shapes may perform better. To get the best control of the hull-based shapes, and lowest weights, make the shape up entirely of separate non-overlapping convex shapes - so the result is exactly what you provide, with no changes to eliminate concavities. Make the distaces between the parts very small to avoid leaky joints. Of course this is more work than letting the Analyze function do it for you. So if you get acceptable weights that way, there's no need to worry. ETA - For some reason, triangle-based shapes seem to be more easily prnrtrated from the "back" - i.e. the side opposite where the normal sticks out, that doesn't get textured. I was never able to analyze that effect in detail, but it might explain some of the inside/outside differences (if you are using triangle-based shapes).

Is the bounding box of your physics shape mesh the same as that of the high LOD mesh? If not, it gets stretched (or squashed) until it is, in each direction, xyz..