Drongle McMahon

I don't think you can ever get the effect you are looking for from the planar honeycomb texture you are using. It will always give you either distortions or seams or both. I ams assuming you want nice regular rings of equally spaced cells. To map these onto a cone, what you need is circular rings with numbers of cells proportional to the radius. Then you can use the overhead projection UV map to get ir seamlessly applied. Here are two examples.  The top one uses rings of circles. That's easy to make, and the rings are correct, but the component circles are distorted into ellipses. So we can do better, at the bottom, by using rings of ellipses that compensate for that distortion. Here are the two textures.  And here is the uv map on top of the ellipse texture. The texture was simply made by using the spin tool on a mesh circle that was first stretched into an ellipse. Then an array mdifier was applied, and spin with n=5 x ring number. A screen capture from above (orthographic view) was modified in Gimp to get the final texture. 

"I'd split it into smaller meshes" I would have thought this not such a good idea, because of un-coordinated LOD switching. However, I had a go at making a similar pergola in one piece. It turned out that the wrought squiggles were small enough that they degraded quite badly before the first LOD switch, simply because there weren't enough pixels. So it would have been better for them to switch earlier (eg to alpha panels). That would only happen if they were smaller sub-models. So I end up agreeing with you. "everything below (highest LOD) almost HAS to be an impostor" Again I agree. That does seem to be the only way to overcome ugly effects because of detail too small to render. I ended up with 102,000 triangles in the highest LOD (lots of exta geometry to get rounded corner highlights but flat sides), then "impostors" at all the remainig LODs. The LI of that was 33. The same high LOD with autoLODs had LI 472, and it looked worse. I have mode some pictures that I might add below. I should go back and split it into smaller meshes as you prescribe above. Not sure I have the time though. I think the best thig would be to have the squiggles replaced by impostors at the first switch, on smaller mesh parts, then to have the main framework all one piece and not becoming alpha until the second switch.

A bit more that might be useful after you have solved the error from Aquila's answer - This is a triangle-based shape (no "Analyze"), which is appropriate for this building. However, the triangle count is 254 and I can only see nine walls. I can see enough diagonals to see that the four walls with doors have 9 triangles on each side. So that's 18x4 = 72 triangles. Then you seem to have seven walls without doors, which accounts for another 4x7 = 28 triangles. That's 100 so far. The edges of these walls, if I have seen them correctly, would add 144 triangles, giving us 244 in all. The remaining 10 could be in the floor I can't see and/or in the offending triangles Aquila pointed out. These numbers lead me to believe you left the narrow edges of the walls in your physics mesh. I so, these narrow triangles will give you an excessive physics weight, even if you get rid of the error-causing ones. So you should delete all the narrow edge faces. They don't contribute to the collision behaviour of the walls anyway. You could also reduce the triangles per side for the door walls from 9 to 5, by using a two-segment "curve" instead of four. You could replace the ctwo adjacent walls at each end with one. If you are prepared to accept a little bit less accurate collisions, you could use just one plane per wall instead of having both sides.

"If the mesh upload error reporter could also do this. That would be good." That's the truth! There are just too many things that might cause this error. Meanwhile, the most effective way of getting answers here is probably to give us access to the physics mesh dae file, say whether you clicked "Analyze", and tell us all the parameters if you did. Also, what the numbers at the bottom of the physics tab were (before and/or after "Analyze"), and exactly at what point the error occurred (immediate, calculate button, or upload button). Pictures of the physics mesh might help, but it's hard to know at this point.

"Different materials with the same data, is it?" Don't think I understand what you are saying here. The materials define the "faces" in SL, That is, the surfaces that you can apply different textures to. The reason for this (and some other) limits is the nature of the internal data format which uses 16-bit values (apparently) for some indices. If you want to see more detail about this one, you can look at jira BUG-1001. "The impact sky rocketed to 3910+." Again. I can't comment usefully without more information. Have you gone on and uploaded?* Some errors only get detected then. There is a problem if your high LOD has > 21844 triangles and the lower ones then don't have the extra material the uploader generates, but that usually gives an error message and blocks the upload. *if not, can I assume you aren't getting confused by non-european number format : 3.456,00 vs 3,456.00.

First: If you have any material with more than 21844 triangles, you are likely to run into texturing problems because the uploader secretly adds new materials. You will save yourself trouble by using multiple materials each with less than 21844 triangles. Second: There are limits to what the automatic LOD generator can achieve, especially with complex meshes like this. It will often fail to reach the levels of decimation you set with the triangle counts. You will always do much better and have LODs that look better if you make your own LOD meshes. Third: For this kind of object, the only technique that will get you a low LI is to use a "billboard" method at the lowest LOD(s). This means using a simple very mesh with am alpha texture that's a picture of the ironwork (see below). If you use this for the lowest two ODs, you can get very low LI. Fourth: You can see when it's the download weight and when it's the physics weight that's keeping your LI high by clicking the "More Info" link in the edit dialog. Whichever is higher will become the LI. For this gazebo to be one you can walk into, you will need to provide a very simple physics shape. See this recent thread for discussion of a similar case.

There are many ways this error can be caused. However, your description of the delay in seeing the red cross disappear suggests you have a very large number of triangles. In that case, you might consider whether it could be the problem described in message 6 in this thread. If it is, the simple fix is to reduce the number of triangles in your mesh. That's always a good idea anyway.

Just one more note that may help. To put a texture on that's only on an accessible face at lowest LOD, you can dial RenderVolumeLODFactor down to 0. Then zoom in and out a touch and the lowest LOD will appear. Dial it back up when you are done, or the world will look terrible.

We found the answer for the display weight - it's the effect of uploading textures with the models, as I discussed in the last post. There were six objects each using the same three textures. When they were uploaded together, that just makes the three textures in the asset database, as the uploader knows they are the same. When they are uploaded separately, that makes eighteen textures in the database, because it doesn't. The display weight counts the number of "unique" textures, and because SL treats each upload of the same texture as unique, it penalises the linkset with the separately uploaded pieces. It's quite right to do so, because it actually has to download eighteen different textures, and put all eighteen into the gpu, even though they are really three textures each copied six times! If the textures were uploaded separately and applied inworld, that wouldn't happen.

"I usually upload them with the models" Of course it's up to you if you want to do that for convenience, but there are a couple of implications you might want to consider. First, you pay the L$ upload cost every time you include the same texture in a new upload. So that's every time you upload it with an altered mesh, or every time you reuse it on a different model. That doesn't matter on Aditi, of course. Second, each of those uploads will make a new folder in you inventory (Textures>Objectname>Objecname-Texture n). Of course you can clean those up. Thirdly, and by far the most serious, each time you upload it, the texture will make a new entry in the SL asset database, with a new UUID. As far as the system is concerned, each upload is a different texture. Now it has to be downloaded again for each object it's used on which isn't a copy of the same upload event, instead of just once for all those objects. I like to re-use as many simple textures as possible, such as woodgrains or bricks, to minimise lag. That advantage is lost by uploading them with each object, as they have then become different textures as far as the asset system is concerned. This doesn't apply to the case where you use the same texture on several objects in a multi-object upload. In that case, the texture is only uploaded once. So if you are only going to use the texture for that one object-set, you don't compromise the lag saving. I'll have a look for your object on mesh sandbox 22 - assuming that's on Aditi.

"I have had a much better TOTAL LAND IMPACT" from uploading in parts rather than as a linked object" It would be interesting to know the weights and the LOD triangle counts of the components uploaded in the two ways, to see what might (or might not) be making the difference. There is one possibility that comes to mind. The LI depends on, amongst other things, the size of the compressed data for the upload. Assuming the compression is done on the combined data, it's possible that compression could be more effective with the combined data. This is most likely to be the case with models having lots of identical normals, which could be the case with buildings with walls etc at right angles. However, I don't know if the compression is done that way, and I wouldn't expect the effect to be very large. Also, uploading together would be better, which is not* be in the direction you report. Meanwhile, I did an experiment to see if I could find a case where the "balancing" out of component LI differences from sharing the triangle budget would fail. I used two 8x8m 2-sided (duplicate & flip normals) planes subdivided into 32x32, project-from-view-bounds UV maps. In the first, the duplicates were left perfectly superimposed. In the second they were moved slightly apart. The LOD generator can't reduce the first at all, while it works normally on the second. Uploaded alone, the first had download weight (Dwt) =92.0 and all LODs the same. The second had Dwt=12.8, with progressive LODs. Uploaded together, the first was exactly the same, but the second had Dwt=1.6, as it was collapsed to one triangle at all three lower LODs. That's the result of sharing the triangle budget when half of the model can't be reduced. This was enough to have a significant effect on the LIs. Separately uploaded, the linkset LI was 105; uploaded together it was 94. However, this is the opposite way round from your report; so it doesn't offer any explanation of that. I believe the server weight depends only on the number of objects (prims) and whether the linkset is scripted, not on the complexity. At least that used to be the case. So I am not sure changes in server weight can account for the effects you see, unless there are differences in scripting? Did you ever check the server weights? It's certainly the case that the LI of linksets of simple meshes can be dominated by the server weights. *ETA: I had this the wrong way round. Changed appropriately

But why is the display cost so different now ??? Also, are they all UV mapped? Missing UV maps can also cause LI differences on seccessive uploads of the same files.

Thanks Arton.

You are right, and a simple experiment shows why this happens (probably). I uploaded a set of six Blender stock objects (gear, bolt, teapot, diamond, honeycomb(extruded), torus knot), both all at once and separately. Indeed the individual LIs are different when they are unlinked from the linkset than when they are individually uploaded. The biggest differences are in the download weight, although the physics weights differ too. The download weights are (2.9/1.1, 6.9/14.4, 4.2/3.7, 0.1/0.4, 2.6/0.1, 7.9/4.0) for together/alone objects in the order above. Note that some have higher weights alone while others have lower. In either case, the linkset, uploaded together or separately then linked, have roughly the same upload weights (24.6/23.4). There's the clue. Now we can look at the triangle and vertex counts at different LODs by using Develop-Show Info->Show Render Info and zooming and/or changing RenderVolumeLODFactor. The counts at high LOD are, of course, the same, but at lower LODs they are very different. For example, the bolt (triangles/verts) is 4980/8467, 621/1538, 309/766, 76/190 when uploaded as a linkset, but 4980/8476, 1244/3050, 309/770, 154/406 when uploaded alone. Similarly, the extruded honeycomb is 204/288, 102/166, 50/105, 50/105 and 204/288, 50/99, 12/34, 6/16. The differences are very obvious just by zooming in and out from the two object collections. So the answer is that the reason for these differences is that the triangle budget for the LOD generator is shared between the multiple objects when they are uploaded together. This results in much more drastic decimation of the objects with smaller triangles (like the bolt). That explains why the differences for the whole collection roughly balanced out, so that the total LI was nearly the same. This is presumably intended to remove smaller details first for the whole linkset. In this case the sizes were such that the download weight is dominated by the lowest LOD, and the differences between those in the download alternatives account for the differences in LI. The default physics convex hull is generated from the low LOD mesh. So the observed differences in physics weight are also explained by differences in the LOD meshes. I Guess I have never noticed this before because I nearly always make my own LOD meshes. I would suggest this provides yet another reason for not relying on the automatic LOD generator. Maybe someone would like to test this with custom LOD meshes, to make sure there isn't anything else going on.

Why are these files nirmally hidden? That seems very unhelpful. (I would never have noticed, as I turn show hidden on as soon as I start up a new computer).

By default, traditional prims use the legacy LI accounting. This means their LI is always 1. For example, if you rez a torus, its LI is 1, but if you use the edit dialog "More Info" link, you will see that its physics weight is 35. That is the triangle-based "Prim" type physics weight of the torus' mesh, but it isn't used by the LI sytem because this is a legacy prim. If you now go to the texture tab, click "Bumpiness" and select the blank normal map, you will see the LI jump to 35. This is because using any non-legacy feature switches the prim to use the new LI accounting. This includes materials (normal and/or specular maps), any alpha blending mode other than "Alpha blending", and any physics shape type other than "Prim". If you reset the "Bumpiness" to None, the LI goes back to 1. Now change the physics shape type to "Convex Hull". The LI goes up to 2, not 35. If you click the More Info link, you will see the physics weight is now 1.8, much less for the convex hull than for the triangle-based "Prim". It's just that this isn't obvious because the "Prim" weight doesn't get used by default. Thus if the new accounting is in effect, the "Convex hull" has lower LI han "Prim". If it isn't, the "Prim" has lower LI than the "Convex hull". That's for the torus. It will most often be true, but the numbers will depend in which kind of prim it is and which torture parameters have been applied. Unfortunately, the LI is calculated for a whole linkset at a time. This means that in linksets containing several legacy prims, like your ship, changes that make ANY of the linked prims use the new accounting make ALL of them use it! If you rez a cube and link it to the torus (after setting its shape back type to "Prim"), then use "Edit linked" to switch just the cube to shape type "Convex hull*", the LI of the linkset will jump to 35 because the linked torus is forced to use the new accounting too, although none of its own settings would make it do so. Unlink them and the LI of each will go back to 1. Relink and it will be 35. So the moral of all that is that setting the physics shape types of one or more prims in the ship linkset to "Convex hull" may reduce the physics weight IF it is already using new accounting. If not, it is likely to increase it because it will invoke new accounting. So will setting any prim to physics type "None" (except the root, which cannot be made "None"). However, those set to "None" will contribute no physics weight at all. So the best way of reducing the physics weight may be to set a lot of the constituent prims to "none". You should probably also look at this wiki page to read about the size-dependent "penalized" physics weight increase that happens when you make something physical. These wiki pages are often out of date. So it may well be that someone expert in vehicle making can add more information here. ETA *corrected - I had put "Prim" (legacy accounting) when it should say "Convex hull" (new accounting).

I suspect that Kwakelde interpreted the question the other way, since I think only having different numbers of objects would affect the server weight.

Is there perhaps some ambiguity in the question here? I read the question in the context of comparing uploads of the identical sets of mesh objects either together in a scene, or individually. In that case, all my understanding of the upload process suggests that all the weights and therefore the LI will be exactly the same, although I never explicitly tested it. In other words, the weights and LI of a mesh object is expected to be independent of which other objects may be uploaded at the same time. This is completely different from comparing the upload of separate objects (whether individually or in a single upload) with the uploading of a new mesh obtained by joining those component meshes, or, conversely, of comparing the upload of a single mesh with upload of a set of meshes produced by splitting it into separate objects. In those case there will generally be large effects on the weights and LI of the alternatives.

Is it all in one mesh object? The 0.01m lminimum dimension applies to each object separately. So the extra geometry has to be part of the same mesh.

Did your added geometry extend the bounding box in all three directions? What were the dimensions on the last tab of the uploader with the scale set to 1.00?

Interesting. I think you have discovered a whole new class of mesh that confounds the LOD generator (GLOD). I can reproduce this with a simple flat square plane subdivided into 8x8. Even just duplicating two rows (16 quads) without flipping normals, stops GLOD working from med-lowest. Duplicating the whole thing stops it completely. In this case, UV mapping or flat shading didn't help, but moving the duplicated ones 0.0001 in Z direction (perpendicular to the plane) let GLOD work poroperly again. It's good to have that documented because duplicating and flipping is going to be used a lot to make 2-sided things.

Have a look at this thread. You may be encountering the same effect. Essentially, the automatic LOD generator has problems with smooth shaded toroidal geometry (things shaped like a distorted torus) when you have no UV map, which can make it fail to reduce the triangle/vertex counts at lower LODs. This can be worked around by UV mapping and/or splitting some vertices (e.g by making a sharp edge). These probably work the same way, as vertices get split (duplicated) in the internal data format by UV seams or sharp edges. So that the vertex duplication seems to get round the problem with the LOD generator, whatever its source.

If you can change the linking so that the walls are the root prim (change order in upload, or unlink, then link after selecting the walls last), then you can set the physics shape type of the woodwork physics to "None". It will then be ingnored by the physics engine. The root prim can't be "None". Any others can.

without the proverbial cigar: Try unlinking it and moving the parts away from each other. It looks like that might belong to one of the other objects. ETA for example, if there was a nearly flat plane object (floor?) included in the physics file, that got associated with the window frame object, then the stretching to the bounding box would have drawn it up to that shape. Same if it were (wrongly) associated with the wall mesh and the wall's physics was associated with the frame mesh pbject.

Lots of points here. "The document i read specifically referred to making boxes, saying the physics engine was most efficient with those" The answer here is that it all depends. For many shapes, especially for smaller objects, boxes (i.e. Mesh Analyzed to produce sets of convex hulls) are the most efficient for the engine, and are therefore given the lowest physics weights. There are exceptions, and the two most common are probably large buildings and walkable landscapes. One of the reasons for this is that the weight of convex hull shapes is independent of size, while triangle-based shapes have weights inversely related to the smallest dimension of their triangles - so they get less expensive the larger they are, and vice-versa. That is a bit counter-intuitive. There are some problems with triangle-based shapes that the analysed shapes avoid. Because the collision detection is not continuous, objects moving fast enough can penetrate them (more easily in the direction opposite to the normals), That means you can get stuck between two parallel triangle-based walls. In contrast, if you find yourself inside a hull-based box, the physics engine will nudge you out again. There are also some strange properties of the triangle-based physics calculation that can lead to absurdly high physics weights, although these seldom arise in ordinary use. Somewhere (link coming if I can find it) there is some Havok documentation that describes the relative cpu resource used in collision detection for the different primitive" shapes used by the engine. In fact the most efficient are undistorted boxes, spheres and cylinders (as well as capsules that we don't have in SL). However, the only way to use these in SL is to use the corresponding regular prim, made invisible, linked to the visual mesh. That use is rather cumbersome, but can give very low physics weights. Unfortunately, the uploader does not recognise these shapes even if they are there in the physics mesh you upload. So it can't take advantage of the saving that would be possible by using Havok primitives for your solid walls, for example. That is very unlikely to change. Neither can it upload physics primitives defined in Blender. The second most efficient shapes are convex hulls. The Analyze thing takes advantage of that by breaking down your mesh into a series of convex hulls, each of which will work efficiently. Then there is the triangle primitive. That is the least efficient for a given mesh, especially if the triangles are small. However, if they are large and there are few of them, they can be more efficient than the convex hull, as is likely with your walls. For walls, this means omitting the narrow edges which would affect the weight disproportionally. Only experiment and experience can really teach you where the crossover is for these two shape types. "my "hull" not extending down as far as the walls" I was interpreting this as indicating that it was probably not the physics shape of the walls, but rather of one of the other meshes in the linkset, whose bounding box didn't reach to the bottom of the combined model - maybe the window frames. However, there is a peculiarity of the default convex hull (not shared by Analyzed, hull-based shapes)in that it doesn't fill the bounding box but is retracted from it by a fixed proportion of the xyz dimensions. This can be quite confusing for large meshes set to physics shape type "Convex Hull" (the default hull) as it means you can sink into the edges where the visible mesh is bigger than the collision shape. I reported this as a bug a long time ago, but nothing has changed. So I have to assume there was a reason for doing it that way. Anyway, the shrinkage doesn't affect either kind of shape you get with physics type "Prim". So those will be stretched to the bounding box of the high LOD mesh. "Is there a problem with doing the triangulation myself in blender" No. In fact it gives you more explicit control. However, quads look nicer and are generally easier to edit. You can get the default Blender triangulation in the exported file if you have the "Triangulate"* option checked in the exporter, although you won't have the opportunity to change the diagonal choices. For these walls, that is irrelevant because they are flat. *Be careful with "Triangulate" if you ever have custom normals in a visual mesh though. It can wreck them completely. ETA Heres the link about Havok collision detection.