Drongle McMahon

The position of the manipulator is easy. With default settings, the pivot/origin is the median point of the selected vertices. That is a point where there are equal numbers of vertices on each side of it in each dimension. Because there are a lot of vertices in the hemispheres, thisis dragged upwards and rightywards, in x and y directions, because the missing fifth hemisphere means there are more vertices in thoise directions from the centre. You can change the pivot.origin location in one of the icons at the bottom of the 3D view. The squeezing of the mapping in one corner is less obvious. I made something as near as possible to your geometry (but see below) and this didn't happen (with default mapping). However, there is something strange going on because I can see only three rings of faces around the edges in your 3D view, while there are six in the UV map. This suggests there are some faces so narrow (even zero?) that we can't see them in this view. In that case. there may be some differences in the geometry in the 'hidden' rings. The visible result in the UV map appears to be that the outer edge of the distorted corner has only two segments around the curve, while the others have three. Thus there may be some differences in the geometry that we can't see in the 3D view, because they are too small, that affect the unwrapping differently at the distorted corner.

If you have more than eight materials allocated to faces in the collada file, the uploader will now deal with that by splitting the object into two (or more if > 16 materials) separate objects before doing the upload. This is a kludge to make it look as if you can have more than eight materials per object, when in fact you can't. The separated objects appear inworld as linked objects. There is no way round this. If you have to use more than eight materials, then you would be better off splitting the object up yourself, so that you do at least control the process. The effect you describe with the face editing sounds like a symptom that happens when multiple materials have the same name. There are at least two known causes for this (apart from the obvious when they have the same name in the input). First, if you have more than 21844 triangles in a material, the uploader secretly makes additional materials, but these have the same name. Second, spaces in material names cause truncation, which can end up with materials with identical names (Blender replaces spaces with underscores in the exporter, but this can happen with other software). In either case, the result is a sort of master/slave relationship where edits to the slaves are reverted by edits to the master, or by relogging. Other users don't see the edits to the slaves at all - in that way, they behave like local textures. Finally, if you have both effects, more than eight materials and more than 21844 triangles in them, you can end up with some very unpleasant effects.

Select one rectangular face; In the UV map editor, select each edge and align it vertically (WL) or horizontally (WI) as appropriate; Select all faces in 3D view; UV map with "Follow Active Quads" option (UF).

This wall has high numbers of repeats of the texture in both horizontal and vertical directions. Each of the squares you can see will contain one copy of the applied texture. This is called tiling. It only works properly with special tileable textures which are made so that you don't see seam where the repeats join each other. You can change the repeats in each dimension by selecting the face you are working on (Select face in the edit dialog) and changing the numbers in the texture tab of the edit dialog. It's a good idea to have a backup of your house, if you can, before doing thios sort of thing. I once forgot the Select face checkbox and accidentally textured a whole house, inside and out, with wallpaper. I had to get a replacement house!

Can't say much about how the physics shape dispolay works in the Alchemy viewer. In the LL viewer, you can see differences between the uploads with the two viewers (assuming that's what each pair is). I 'm not sure which is which, but I can guess from what I know about the default convex hull shape generated by the LL viewer. This is always shrunken inside the visible mesh by a small amout (a fixed proporttion - details in older threads here). So I would be failrly confident that the ones where that is evident are the ones uploaded with the LL viewer. We can then see that the shape uplaoded with the other viewer is different, as it fills the whole space. That doesn't really explain the difference in phsyics weights though. They bot seem to preserve quite a lot of vertices from the irregular top of the pillar. You might see differences that could explain the difference if you can look very closely. Unfortunately the convex hull display doesn't include the vertices. So it's difficult to see. In your later post, I guess you have used the cube physics shape, because we can now see the expected simple box. In this case, the LL viewer does not shrink the shape. The physics weights are 0.4 (rounded up from the expected 0.36). This is almost certainly acceptable, unless you need some detailed physical interaction with the irregularities at the top of the pillar. If you clicked "Analyze", then you will have this shape whether you set the type inworld to "Convex Hull" or "Prim". This is because the uploader (LL) will use the phsyocs mesh provided to make the default convex hull. In the case of the cube, the "Analyze" will then produce exactloy the same convex hull. If you don't press "Analyze", then the "Prim" type shape will be a triangle-base shape. Thje default convex hull will still be the same, but if you set it to "Prim" it will use the triangle-based shape, and for an object this size, that may have a higher phsyics weight. You can see the edges of the triangles in the physics shape display of triangle-based shapes. The two most important things you need to remember about physics shapes are, first, that for each object the phsyics shape will be stretched/squashed to fit the bounds of the visible mesk, and, seconds, that you need one physics mesh object for each visible mesh object. From now on, these should obey the new naming convention: So if an object is called "anobject", its LOD meshes are called "anobject_LOD2", "anobject_LOD1", "anobject_LOD0", and the physics mesh is called "anobject_PHYS". (Just note that this applies to the object names, NOT the file names as stated in the wiki!).

Good point Arton. The Havok library is certainly used for the decomposition when you click Analyze. I guess it is likely used for the default convex hull generation too, although I don't know that for certain. If it is, then that could indeed make all the difference. It's also possible that that viewer uses a higher LOD for the default physics shape. The change from the high to the low LOD in the LL viewer was quite a long time ago, but.... However, I suppose that can't explain differences between the two grids, when using the same viewer?

I don't know why you are seeing that difference. I made something similar and ithad identical weights on both grids. So I can't offer any explanation. If you can take snapshots of the physics shapes (Develop menu->Render Metadata->Physics Shapes) we might be able to see something different.

Well, it's only necessary from the LI point of view if the physics weight is higher than the download weight. However, it is good practice to always make a simple physics shape in order to minimise the work the physics engine has to do, even if it doesn't save LI (unless, oif course, you are going to set the physics shape type to "None"). It also means you control the physics precisely. It is sometimes surprising to see how high physics weights can be with something like your pillar. Even the convex hull can still have many vertices, and thence a high weight, when it has an irregular surface like the ragged top of your pillar. Only the indented vertices will be left out. Small details have no discernable effect on the collision behaviour, but can greatly increase the physics weight.

If you used your own low LOD, with default physics, then that should have been the same result on both grids for the default shape. If you weren't using the default shape, it would depend on settings. For this model, I would use a simple cube phsyics shape (which will get stetched to fit by the uploader) and click "Analyze", which should always give you a physics weight of 0.36. "Ok, so basically on the beta grid I can only test the way my models look. Got that." I wouldn't say that. While it's possible for the weights to be different, it should be very rare, especially as there have been no chnages to these parts of the system for a long time, as far as I know. My point is really just that it isn't absolutely guaranteed. I would still guess that there is some other cause for the differences you saw.

Are you using explicit LOD meshes and physics? If not, you need to know that the automatic LOD generator is non-deterministic. That means it can generate different results on different occasions for the same input. The default physics shape is generated from the low LOD mesh, unless you tell the uploader otherwise. So the physics weight of the default shape can also vary substantially as the result of the variation in the LOD generator. The only good solution to these efefcts is to make your own LOD and phsyics meshes, which is advisable for other reasons too. If you aren't doing that already, I would suggest you try that. The download, physics and server weights are now calculated by the server. The beta grid is where LL test changes to the server code. So there is no guarantee that it will always be the same as the main grid. As far as the display weight is concerned, I don't know whather that's calculated by the server or the viewer. You observations would suggest the latter.

Oh, well remembered ChinRey. That's pretty definitive. I we look at cubes of different size, we can see that the inward displacement of the collision shape is constant, irrespective of size. This is presumably to counteract the ~0.1m float gap between the avatar and a mesh physics shape, so that the avatar appears to be standing exactly on the visible cube.  The torus convex hull is a bit unusual, as it isn't symetrical in the direction of the hole. Here are three objects with the phsyics revealed by the pathfinding method. On the left is a sculpty (default map). Next is a torus with physics shape set to convex hull, and on the right is the same torus with the physics shape set to Prim. In the top row, duplicates of the same objects have been rotated to look at the other end. In the torus (apart from a bit of strange triangulation for the convex hull) the physics shape has faces flat in the vertical plane, but at the other it's an edge that protrudes. The shape is actually a 9x9 torus. The convex hull, but apparently not the Prim shape, has the same inset from the visible shape as the cube. The physics of the sculpty (left) has the same geometry, subdivisions and and asymmetry, as the convex hull of the torus. That gives us extra confirmatiuon that it is the convex hull of a torus. It's interesting that the asymmetry means that both torus and sculpties might sometimes show different behaviour depending on which end they are stood.  Also, the small number of faces around the perimeter of the torus physics explains why it rolls badly. If you look at a sdphere, its physics is a subdivided icosohedron, which is much smoother, allowing it to roll much more easily.

I'm not sure what the problem is with your experiment, but I repeated it 9except usiong 32m instead of 64) with the results shown in the picture. Both sculpty (default map apple shape) and torus are 32x32x32. Torus is all defualt parameters, as when first rezzed. Both are rotated through 90 degrees about the Y axis, so that the torus dimple (and the flat top of the sculpty physics shape) are on the top. Note that this does NOT put the sculpty dimple on top. That is dimpled along the Z axis, while the torus dimples are along the X axis. The sculpty is transparent blue blank texture; torus is transparent yellow blank texture. Ruler divisions are 1m. In all cases, I flew up and then dropped down until I landed on the surface. On the left, the sculpty is Phantom and the torus is Convex Hull. In the middle, the sculpty is still Phantom, but the torus is Prim. On the right, the sculpty is Prim, and the torus is Phantom. So the position where the avatar came to rest on both the convex hull of the torus (left) and the Prim-type phsyics shape of the sculpty (right) are identical, as predicted is the phsyics shape os the sculpty is indeed the convex hull of the torus. Note that the visible geometry of this sculpty does not fill the whole of the space occupied by its physics shape. This is quite common with sculpties which do not use the entire range of RGB colour values in their maps, and thus do not use the entire dimensions of the bounding box.

"any idea why the Collada file linked to in message number 15 above, wont open in Blender" It seems to be the reference to the image file. If you delete the <library_images> section, and replace the <diffuse> section that refers to it with the <diffuse> section above (colour only), then it imports into Blender. Following re-export, I do get different results on upload. The re-exported file give normal LOD triangle counts. The original (without the image reference) gets a reduced triangle count for thge first LOD step, but then it's stuck for the remaining twp steps. The files are so different that it may be very hard to work out where the causative difference is. First thing will be to try removing the <controller> (the armature). By the way, I don't see the duplicates you mentioned. Just two parallel sheets (16 verts each) and a cylinder-like thing (24 verts). ETA: I am using the file from the first of Bonita's links.

It looks like your end walls are each all in one piece. In that case, they are not convex, having two concavities, the door and the indentation of the longer roof slope. For the technique of using non-overlapping boxes to guide the "Analyze" decomposition reliably, all the boxes have to be convex hulls already. Otherwise you are still likely to suffer from the limitations of the decomposition. So it should work if you make these something like the one in this picture.  ETA: Generally, I would probably have used a triangle-based physics mesh for this type of house, just because the physics weight is often lower, but that's a separate issue.

No Blender file, but the problem is there in the dae file. So if you can make that available, we might be able to find what's making the LOD generator choke, as we were able to do with the torus/shadfing case. The smaller the file the better for that kind of thing. So best if you can get it down to as simple a case as possible. There probably won't be a solution that can be fixed, because the GLOD library is third party, but maybe we can tell what topology has to be avoided.

The slm file (to use old settings when you upload with the same filename) system causes all sorts of unexpected problems. I don't think the tiny savings in entering settings is worth it. So I have it turned off by setting the debug setting "MeshImportUseSLM" to false. It's sticky, even through viewer updates. So once you've turned it off, it stays off unless you turn it back on. Then you can just forget about resetting, renaming, or deleting slm files, and all those problems go away.

Furthermore, Lag: "a period or term of penal servitude; prison sentence." So you can use the same word for the phenomenon and the just desert of those who cause it: "Lag for lag!" :matte-motes-grin:

Also, note that whatever physics shape mesh you provide, it will be stretched and/or squashed along each of the axes until it fits the bounding box of the main (high LOD) mesh. So making a smaller cube for the physics has no effect. There are some ways of defeating this effect that have been described in this forum before, in reference to doors and offset pivots.

"Am I the only one who can't help thinking how many polys we could have saved if SL had allowed for backfaces?" It might have saved a few*, but then it would have meant either nearly twice as many triangles to render (or twice as much calculation of occlusion to know what not to render). I think the consequent cost in lag would have been much higher than any benefit from avoiding mistakes (covering up laziness ?). In Blender it's fine to see the backfaces because it mnakes it easier to select, but in a real-time environment, I don't think it would be a good idea. *Not many - unless you want the same texture inside as outside, you'd have to make them a different material anyway, and the triangle count would go back up. If you don't get to see the inside, then you don't need the triangles anyway. ETA - actually. considering a bit more carefully, that is probably an exaggeration. Since any triangle can only be seen from one side, the renedring would only have to work out which side for each. That's still a pretty heavy burden though.

A bit more ... Seams have no existence outside of Blender, either in obj or dae files, because they are only instructions to the UV unwrapping function in Blender. Once the UV map is generated, what is marked as a seam has no further effect. So it isn't included in the exported files, which have no means of carrying that information anyway. That's why they aren't there in the re-imported model from obj file. The reason you don't see the effects of inverted normals, by default, in Blender is that the 3D view uses two-sided rendering - both sides of any polygon are shaded. In SL, only one side (the one with the normal sticking out of it) is rendered. So if the normal is inverted, you see only the back surface, which should be invisible. You can preview this behaviour in Blender by turning on "Backface culling", using the checkbox in the "Shading" section of the Properties panel, usually to the right of the 3D view. That way you can save the effort of uploading to identify the inverted normal problem. To see the (face) normals, click the rightmost of the three box icons in the "Mesh Display" section of the Properties panel in Edit mode. Pulling an extruded face in the direction opposite to its normals is one way you can get inverted normals.

I'm going to make myself unpopular by bringing up another questionable aspect of baked specular effects. Genuine specular reflections depend on both the incident light angle and the camera angle. When you bake, there is no camera. Instead (at least in Cycles, as far as I can tell*) each pixel is essentially rendered as seen by a camera looking at it along the normal of the surface at the middle of the area corresponding to that pixel. On a complex surface, this means that each pixel receives highlights for a different camera angle. So the baked result doesn't actually represent the highlights that would be seen with any real camera. In additipon to beiong unable to respond to changes in lighting or movement of the camera, such baked highlights don't even accurately represent the highlights from any actual setup of lighting and camera. The fact that those skilled in their use can nevertheless produce effects that satisfy many observers is testament not only to their skill, but even more to the gullibility of our perceptions. *I would be interested if any one would like to try to convince me otherwise.

To make the landscape accurately walkable, you need to use a triangle-based shape (i.e. Not analysed) using the high LOD mesh on the physics tab. Then you have to set the physics shape type to "Prim" inworld. The physics weight reported by the uploader is irrelevant. It's for the default convex hull shape which will not be walkable. Unfortunately you can't see the Prim type physics weight until you have rezzed it inworld. For a 64x64 mesh, only the high LOD counts, so there is no point in making lower LODs. Your mesh appears to have 5000+ triangles,and that accounts for the high download weight, which will be equal to or less than the LI. With that many, consequently small triangles, you are bound to have a high physics weight too, most likely higher than the download weight, which may increase the LI further. The example I showed above, LI=23, has only 504 triangles. Just to emphasize what Arton said, you can't upload a mesh with any dimension greater than (just under) 64m. If you do, any such domensions will be squashed down to (just under) 64m. If you want to upload something larger, you have to break it into a set of meshes each within that size limit. Although the uploader will annoyingly squash any 64x64 mesh a tiny bit, you can readjust it to exactly 64x64 inworld (I think).

In nobject mode, the vertex and face counts are for the whole scene, not just the selected object(s). My guess is that you have other objects there. Here is the 2 x subdiv cube on its own. Switch to edit mode to get the selected object counts.  ETA - the other two objects are the lamp and the camera - no vertices ot faces.

The key to getting low LI for walkable landscapes is to use larger triangles where you can. You can see the effect in simple 64x64m planes with squares of 1, 2, 4 and 8m sides. Their download/physics weights are 189/232, 47/29, 11,4, 2,0.5. For comparison, The SL land has squares of 1m, like the first of these. That would use 232 of the 937 prims available from the 64x64 area it occupies, about 25%. The picture here shows a 64x64 riverbed mesh. The smallest squares are 2x2m, in the river channel. The flat areas have much larger triangles. It has download weight 23.5 and physics weight 18.2; LI=23.  Mesh this size are always seen as the high LOD (except with perverse viewer settings) and you get no savings of LI at all by using lower detail LOD meshes. It's worth noting that it is possible to accidentally penetrate a triangle-based mesh landscape and get stuck underneath. So either provide a way out from underneath, or make sure your visitors know how to sit on something above ground to get out.

"watching my free money quickly dwindling" You used to be able to get more just by asking for it, but I don't know which Linden is there to ask any more.