Drongle McMahon

I would go even further with this one. After noting that you can never see more than half the cylindrical parts, or more than one circular end, you see that it is possible to use repeats for these, with a tileable texture so that vthere;s no join on the cylinder. That wat I came up with the following (made entirely in Blender). As far as I can make out, it has exactly the same amount of detail as the original (normally I would use less), although it's about half the number of triangles after eliminating the redundant ones. Its download weight is less than 0.5 at 0.5x0.5x0.6m. The UV mapping is shown in three sections, but these are actually stacked on top of each other, all one material. The picture on the left is inworld with a single 256x256 texture. That's 1/16 the data download and gpu memory of a 1024x1024. Not only is 100% of its area used, but it actually uses most of it four times over. Of course, there are limitations with this approach. If you want to bake shadows etc. as part of a larger scene, or if you need different labels on each end, you would have to use the kind of thing Chosen shows; the texture wouldn't be reusable, and it would need to be four times the data for the same detail. Another reason for that is that the ends should have a cross-cut grain texture different from the longditudinal one used here. That can be achieved in one material wiuth the unstacked mappings, or with this mapping and a different material. ETA: Maybe also worth reminding people in this context that increasing the number of UV islands increases the download weight. ETA: Also, note that the same effects as here can be achieved by using essentially Chosen's second map and setting repeats to 2x2. That way, you can still use the same map with a baked texture. So That's really the better solution.

Ah. Good. That's how it should be. You could probably even use double the curve/sphere segments in your high LOD mesh and still have LI=1. At this sort of size, the lowest LOD is overwhelmingly important in deciding the download weight.

Need to know: How big it is when rezzed (LI is usually depedent on size); whether you have set/made LOD meshes; How you have specvified the physics shape (if at all); Setting of physics shape type inworld; What are the download and physics weights - you can see the by clicking the "More Info" link in the edit dialog/floater. LI of 16 is certainly way too high.

"1. Nobody has to use any website if they don't like what's on it." :matte-motes-wink-tongue:

I have submitted jiras, although with very simplified cases and much less extensive data. They have been acceped and forwarded into the internal sytem, which means I have no further information on their potential fate unless or until something changes. I would have added these cases to them, but that's no lomger possible, which is another reason I put them here, so that at least the information is available.

1) Are you nuts? No. (But I would say that if I was....). I did consider the possibility until someone else was able to confirm the initial observations that started it all; the very different weights for the same geometry exported from different packages. I do enjoy puzzles though. 2) Do you get the feeling that the wiki (which I have not read) was written by someone who knows less about how mesh and physics weights work than you do? No. It was (mostly) written by Falcon Linden (at least, that's what the wiki edit page says). He knows infinitely more about mesh physics than I do. I only know what I can observe. 3) Do you worry that, if you do discover the underlying method to this apparent madness, it will change tomorrow? I've given up trying to understand the cause. It's too complicated (although the cause may be simple). I hoped to find a simple workaround to get consistent weights, but now I think I have to give that up too. I would be happy to see it change, but I can't comment on how likely that is. Clearly, many people, including me, failed to notice these discrepancies for a long time. That means people were able to accomodate to them without insurmountable problems. In view of that, it would be a reasonable decision to leave it as it is, especially to avoid breaking existing content. I think my interest was mostly aroused because it drew into question advice that I had given out about choosing between triangle-based and convex-hull based physics shapes for different kinds of models. With this sort of variation, any such advice becomes unreliable in any particular application.

I get a Maya 2013 price of £3480 for boxed version from the uk Autodesk site, but that includes 20% VAT. Before tax it's £2900, which is $4324. Not so bad when you consider that the value of £/$ is falling like a lead balloon at the moment.

Triangle-based physics weights - episode 4. The triangles of a triangle-based (not Analyzed) physics mesh are specified in the collada file in a <polylist> or <triangles> section, which lists triplets of vertices specifying each triangle. Episode 3 showed how the choice of which triangle came first, and the order of the three vertices specifying it, could have large effects on the physics weight of a simple physics shape such as a 12-sided cylinder, even though the resulting geometry remained identical. Unfortunately, the minimum weight could not be achieved directly in an export from Blender. Instead, it required manual editing of the collada file. However, if it's true that the first triangle is the most important factor, then it might be possible to get low weights by starting with an optimized collada file for a relatively simple mesh, importing that, and then building the rest of the physics mesh. When you do that, Blender does keep the imported mesh as the first thing in the collada <polylist>. So this is an investigation of that approach to lowering triangle-based physics weights. As a target model, I chose a roof supported by columns. Starting with four columns, this could be extended by adding extra pairs of columns. A suitable physics shape for the columns was a six-sided column. So the first step was to optimize the triangle order for such a column. It was 3m tall, open ended, and with 0.29m diameter so that bot x and y dimensions were at least 0.5m. This was investigated as for the 12 sided column in episode 3. Two orientations, points along x or y axes, and two directions for the diagonals were looked at. For each, all cyclic permutations of first triangle choice and of vertex order in that triangle were observed, with the results shown here. The range was 8-fold, from 0.6 to 4.8. Eight configurations had weight 0.6 (green), and one of those (outlined) was chosen as the collada file to import into Blender. The remainder of a four-column structure was made using normal Blender methods for the remaining columns, exactly the same dimensions, and for a single flat quad roof. Adding more column pairs and stretching the roof made six, eight and twelve column structures. However, the weights after upload of the exported collada files were quite high. So the exported was edited to repeat the complete set of rotations of triangle orders and first triangle vertex orders for the first, originally imported, column at the top of the <polylist>. The same configuration gave the lowest weight (yellow) for all models, although it was not that (top left) that had given the lowest weight for the isolated cylinder. Surprisingly, the lowest weight for four columns plus a roof was 0.7, only 0.1 higher than the lowest found for the isolated column. Clearly, this approach can produce very low weights, but it may not be with the configuration optimized for the isolated column. The lowest weight for the six column structure was also impressive, but the effect seemed to diminish as the number of columns increased. (The weights for models constructed completely in Blender were 2.7, 5.2, 8.4 and 11.8 for 4, 6, 8 and 12 columns, although this is likely to be highly variable depending on exact details of the construction.) So the process was repeated, first importing the isolated-column collada file new configuration found to be optimal for the multi-column structures, and then adding the remaining parts. The result was disappointing, giving weights of 0.9 (vs 0.7 for 4 columns), 2.1 (vs 1.2 for 6 columns) and 9.0 (vs 4.4 for 8 columns). Examination of the collada files revealed that the order of vertices in only the first triangle exported file was different from that in the imported single-column file that had been used to start the construction. Changing this to the original imported order gave weights of 0.6 and 1.3 for the 4 and 6 column structures. The former was even lower that the optimize value and equaled the best obtained for just a single column! However, the repaired order in the 8 column structure actually produced a higher weight, 15.9. Further inspection of that collada file revealed that the order of vertices in the quad defining the roof was different. Testing all four cyclic permutations of the vertex order for the roof quad gave weights of 15.9, 4.4, 5.8 and 4.5. So this part of the polylist was also having a large influence, even though it was nowhere near the top of the <polylist>. In conclusion, these experiments showed that optimization of the identity and vertex order of the first triangle in the <polylist> can achieve dramatic reductions in triangle-based physics weights for a given geometry. However, this may not be fully achieved by simply importing a previously optimized starting shape. The reduction in weights may become somewhat less effective, and/or less easy to achieve, as the complexity of the final mesh increases. Furthermore, elements other than that at the top of the <polylist> can sometimes be important in determining the weight. At least it is clear that some playing around with the order and orientation of parts of the mesh is likely to be effective in reducing the weight of these physics shapes, but I have not been able to find a general direct approach to optimization. The preferred solution would be a weight calculation that always produced the same weight for the same geometry, irrespective of the order of component elements in the collada. We will have to wait to see if that might be forthcoming. One problem will certainly be that existing models that have the lowest weights by chance might see substantial increases with a more consistent calculation, and that could cause problems including unexpected returns from increased LIs. ETA. Here's a picture of the eight-column version of the model. The triangulated column at the nearest corner is the imported one. The rest is added on in Blender. The columns are 3m high, 2.5m apart.

To be precise, the collision/physics shape of sculpted prims is, and always has been, the convex hull of a torus with equal inner ans outer radii (that is with no hole). Somewhere in the old forum is a thread where this is confirmed. (This is the thread Code linked to.) One consequence of this is that when you have a flattened sculpty, the apparently solid area depends on which is the flattened dimension. This is illustrated in the picture, where the corners you can fall through (yellow bounding box) are more obvious when the z axis is squashed (left) than when one of the others is squashed (right). These sculpties both use the full range of the RGB values and therefore fill the bounding box. The collision shape always fills the bounding box, but if a smaller range of RG and/or B is used, then the box will not be filled by the visible sculpty. In that case, the collsion shape will be larger than the visible shape. This would stop you falling through it up to, and even beyond the visible edges.

This is the automatic distance-dependant switching to a lower level of detail (LOD). Did you let the uploader generate the LOD meshes for you? Those are usually not satisfactory for this kind of mesh. I think you need to make an explicit LOD mesh, at least for the medium LOD.

Can't help because of my ignorance of Mesh Studio. However, it might bhelp if you could show a picture of the physics shape of your floor, by using menu item Develop->Show metadata->Physics shapes.

Warning: Reading the following may damage your brain. Proceed at your own risk. Having abandoned my attempt to work out what is causing the strange triangle-based physics weights, described in previous episodes, I have been trying instead to find some guiding priciples to minimize the weights. I should say at the outset that I have not really met with much success (yet). I started to look at the effects of triangle and vertex ordering for more practical shapes. In episode 3, I will describe some results with simple cylinders, where optimal conditions were found. Then in episode 4 I will describe some attempts to use that information where the cylinders are part of a more complex shape. The picture here shows the weights obtained for some 12-sided uncapped cylinders. The collada files used were made by manual editing of an initial file exported from Blender. They contain no UV map data and (mostly) no normal data, as that makes it easier to edit the order of triangles and vertices in the <polylist>. In many experiments, I never found any difference in the triangle-based physics weights resulting from the removal of the UV map and/or normals. When you triangulate a cylinder in Blender, the collada exported has a <polylist> with the triagles listed going around the cylinder, first those with edges at the top, then those with edges at the bottom. Autodesk exports have the triangles listed in order around the cylinder, not separated. This is more natural, as it places pairs of triangles comprising each quad face next to each other. So the data here is from files rearranged in that way. Using the original Blender order gave essentially identical weights, except for a vertical shift in part of the table. The table in the picture shows four sections representing different starting cylinders, as indicated in the diagrams at the top. In c12perp, the default cylinder is rotated 15 degrees so that it has faces perpendicular to the x and y axes. In c12pnts, it is the default cylinder with points on the axes. In the two sections on the left, the diagonals were as generated by triangulation in Blender. In the two on the right, the diagonals were then rotated, so that they connected the other two corners of each quad. The cylinders were all 2m tall and are scaled to be 0.5x0.5m in the xy plane, so as to avoid the hidden switch to convex hull for any smaller dimensions. Within each section, the only changes were to the orders of triangles in the <polylist> and to the order of the vertices in the first triangle in the list. The vertex positions were unchanged, so that the actual inworld geometry is identical. Vertical columns show the effects of cyclic permutation of the order of triangles in the <polylist>, bringing each triangle in turn, going around the cylinder, to the top of the list. The three columns for each row show the three cyclic permutations of the vertex order for the first triangle in the list. The vertex orders for the remainder of the triangles were kept in the original order. Non-cyclic vertex permutations, which alter the winding and the implied normal were not investigated. They do change the weights, but also change the physics behaviour. It is easier to walk through from the "back" of triangle-based shapes. The investigation was done this way because earlier experiments, randomising the order of other triangles, had indicated that only the choice of the first listed triangle affected the weight. However, some results showed that the vertex order in triangles elsewhere in the list, especially the second, can affect the weight. So only a tiny fraction of the possible orderings in the <polylist>, without altering the geometry, were actually investigated here. Red coloured cells in the table show absurdly high physics weights, of several thousands, that appear with some configurations. These greatly exceed the maximum limit implied in the physics weight wiki, showing something wrong with the clamping described there. The variation in the relatively sane weights is shown by the lengths of the blue bars. They range from 1.3 to 30.7, still over more than 20-fold. The lowest weights, below 2, are only found with the rotated normals, for either orientation of the base cylinder, and the lowest of all, 1.3, also required changing the vertex order as well as the triangle order. Note that in most faces (pairs of first triangle rows) there is a shared pattern with three cells each of two different values depending on the vertex rotation. This is a lot of work to find the <polylist> that gives the lowest weight. Is it possible to get there without editing the collada file? Perhaps by just rotating the cylinders so that the first listed triangle is at geometrical positions equivalent to thgose achieved by editing the polylist? Testing this for the c12pnts triangulated cylinder, rotating and exporting at 30 degree rotation intervals, so that there are always points on the axes is not promising. The range of weights found was 7.1 to 29.9 (excluding one silly one at 5904.2); at least 5x the minimum weight. Doing the same thing with rotated diagonals gave values between 3.1 and 9.4, and with an untriangulated cylinder, 3.2 to 8.3. The minimum of these is still more than twice the lowest weight in the table. So it seems that only by a tedious investigation can we obtain the lowest weight, and that this requires both rotating the diagonals from those produced by default triangulation and permutation og the order of vertices in the first triangle in the <polylist>. Similar, though not quite as extensive, investigations were done with 8, 6 and 4 sided cylinders. The general picture was similar, although the range of weights became less wide as the number of sides was reduced. Some weights of many thousands were found for the 8-sided cylinder, but not for the 6 or 4 sided cylinders. So the question is whether all this information can provide a way to mitigate the physics weights of more complex triangle-based physics shapes. At first sight, there is no hope, but if it's true that the first triangles have the greatest effect, then perhaps importing a manually optimised simple shape from its collada file, so that it's first in the triangle list, then building the rest of the complex shape onto it, will help at least to avoid the highest weights. Episode 4 will investigate this possibility. ETA : note that all this was done on Aditi - can't afford the uploads on Agni. Last I checked, there was no difference in the weight calculations between grids, but of course that situation is potentially fluid.

Sorry you guys, "A picture is worth a thousand words" but a thousand words is faster :matte-motes-evil-invert: eta : (or, at least, 171 words is faster!)

If you are using Blender... Just UV map the materials separately. There's no need for their UV maps not to overlap, as they will be using diffferent textures. Select just the faces belonging to a matyerial and then do the UV map whichever way you like. For the picture face, if you look straight at the face and choose Project fom view (bounds), it should automatically fill the whole UV plane. Otherwise, you can edit it in the UV editor to exactly fit the whole area. (Or you might shrink it ever so slightly to exclude the extreme edge and avoid possible edge-bleeding effects.) If you are baking textures, select the material faces, hide unselected, make a new image and bake, the show hidden and repeat. That way, each material will get baked to a separate image, and the overlapping of the UV maps will have no effect. If you are using something else, I'm sure the same approach is possible, but someone else will have to tell you the details.

In the SL internal data format, each material has a list of triangles and each triangle consists of three pointers to vertices (each vertex having position, normal and UV vdata). These indices are 16bit, which limits the vertex list, per material, to 65536. The code contains a check on the size of the vertex list that should give an error messgae when it reaches 65537 and, presumably, abort the upload. However, there is another check that limits the number of indices in the triangle list, which intervenes when the triangle count exceeds 21844 (65532/3). This will always be reached before the 64k vertex limit, even with completely fragmented UV or faceted triangle so that each triangle requires three unique vertex list entries. When it intervenes, it doesn't stop the upload, but instead it starts a new "pseudo-material", resetting the vertex list counter for the new material. So the 64k limit cannot ever be reached. (I can't see why this extra limit was introduced. There doesn't seem to be any need for a 16-bit counter or index into the triangle list, but who knows.) In fact, you can upload apparently unlimited numbers of triangles, but if you exceed 8x21844 (174752), the next ones go into a ninth pseudo-material (and so-on) which gets culled by the limit to eight materials. The culled triangles appear as holes. Which triangles appear in which pseudo-material seems to be dependent on the order they happen to be received by the uploader from the 3D authoring program and exporter, which can depend on the internals of those programs and on how the mesh was made. In a Blender mesh made by subdivision and finally triangulating, the triangles are scattered over the mesh surface in a Serpinski-fractal-like pattern. So are the holes that are left by going over the 174752 limit. I guess that is the result of adding the new faces at each subdivision to the end of the existing list inside Blender. I can understand why dropping a texture on the surface or selecting a face affects only one pseudo-face/ Both involve looking through the triangle lists to see which material was clicked. Then the code could just fill in the remainder of the triangles in the list where the hit was found. However, that doesn't explain the different behaviour for material 0 where all faces get the texture. I might look at the source for an explanation there. The scripted changes work the other way round - pick a list from its index and apply to those triangls. Scripts run on the server, so I can't look for this. I can say it's not just the fact that the pseudo-materials have the same name. Editing a simple collada file to make four materials on a panel have the same name doesn't produce any strange behaviour. This is consistent with the situation before material sorting by name was introduced to correctly assign materials at different LODs. Before that, the names were irrelevant and only the order in the collada file mattered.

"..try to be subtle and neutral as much as possible and make something that would work in both scenarios.." I just want to add even more agreement to that. My shadow above was for illustration. I would never actually use anything like that. Ugh! There's a problem with the viewer ambient occlusion on smooth surfaces though - just make a 10x10x10 half pathcut 95% hollow plain white sphere and look inside it while toggling ambient occlusion in preferences! The effects are much worse on various large mesh cylinders. The ao doesn't respect smooth shading.

Hopefully, you won't be using more than 21844 triangles now. However, in case anyone has to, I did a few more experiments with my >174752 triangle cube. If you set the texture in the edit dialog without using Select Face, it will set the same texture for all the triangle. What happens if you drop a texture on the mesh, or choose a texture from the dialog while usin Select Face, depends on which pseudo-face your drop/selectio falls on. On one of them, all the faces receive the texture. On all the others, it appeaers on just the selected face! To clarify this, I tried changing the colour by a sinple script. It turns out that if you change face 0, all the pseudo-faces get coloured. If you use any other face number, nothing happens. I assume this is a side-effect of the fact that the pseudo-materials all have the same name. Presumably the llSetColor works through a name-based face/material list that only has one entry (0) with all the triangles in it. It appears that the selection (explicit or by dropping) works differently, and only if you happen to have selected pseudo-face 0 does it then get applied to all others with the same name. I would have to look through the source code again to find out why this is. It's possible the behaviour of face 0 is supposed to happen for all the pseudo-faces, and that its failure is a(nother) bug. I'll have to make another jira with this new info to add it to the existing one for the holes.

"Blender now ... decimator with preserving UV capabilities" Yes. I haven't got round to trying it yet. I guess it can be a great time saver, but I do like precise control (although the decimnator might well do a better job than I do! :matte-motes-shocked:)

"...keep it in the same mesh / object. (you need to understand that independent objects have more weight / landimpact as when being in one object." In this case, I think the weight consideration leads to the opposite conclusion. Including the larger plane in the same mesh increases the bounding box "radius". The download weight part of the land impact (likely to be the deretrmining weight for this item) depends on the square of that radius. So it will increase substantially even though only two triangles are added. On the other hand, the download weights of separate meshes are added together before rounding to calculate the weight for a linkset. The plane will have the minimum download weight and will therefore add little to the weight of the linkset. To confirm this, I made a simple pergola like Ark's, with a shadow plane about twice the x and y dimensions of the pergola (that is a lot less than the Ark shows). Uploaded as a linkset of two separate objects/meshes, the LI was 4 (download weight 3.9). Uploaded with the plane combined into the same mesh, the LI was 8 (download weight 7.5). So combining the plane doubled the LI compared with linking it. The unlinked meshes (plane and pergola) had LIs of 1 (download weight 0.1) and 4 (download weight 3.9). With the linked prims, the physics type of the shadow plane can be set to "none", which is what you want for the shadow. With the plane in the mesh, you have to use special methods to make the physics of the plane disappear. So I think in this case, all these factors work in favour of using a separate object for the shadow plane. Here it is in Blender. The cube is 1m cubed. As you can see, the plane is too small for more slanted shadows. Edited - typos.

"Still my question is, how to separte the shade from the pergola?" Use a separate object in Blender, which will become a separate prim on upload. You can then upload them together (preserving relative location in the resulting linkset), or separately.

The trouble is that some people will have lighting and shadows enabled in their viewer, and the viewer shadows will conflict with whatever you provide (except at one time of day, perhaps). Others users will not, and would benefit from your shadow. For the ground shadow, you could provide a separate plane and the user could choose whether to use it. For shadows on the mesh, you are stuck. I guess you could provide two (or more for different conditions) textures, with and without the shadows*. If you are doing that, you could include the ground shadow plane in the mesh. You can bake any lighting you like to set up in Blender, but I don't know if you can bake to an image with an alpha channel for the transparent ground shadow. If not, I suppose you would have to edit it in photoshop/gimp after baking it with solid colour. What we need is a texture toggle that sets the transparency depending on the viewer setting for lighting and shadows! Anyone like to do the feature request? Can that setting be detected in a scipt, which could change the texture accordingly? (I hope not - that would be more lag!) *or you could use a whole-mesh shadow overlay mesh of the sort that has been discussed in recent threads here.

Yes. Decimate isn't usually very nice. It looks as if you have a mesh made of nice regular quads. If that's right, you could just select every second horizontal edge loop and use mesh->dissolve. That will reduce the triangle count in a regular way without affecting the UV map. You have to check the "dissolve vertices" option that comes up on the operator options when you use dissolve for this. Otherwise the vertices are left there and the triangles will come back when you upload.

I use Blender, and the different "black squares" appears randomly with different upload in Second life. That sounds a bit like what happens when some faces are unmapped - random mapping, often from one texture pixel. I think it's due to the use of uninitialised data where map data is missing. Turn on face select mode, deselect everything, turn on synchronied selection and select all in the UV window. Are all the faces in the 3D view selected? Also, apply a test vtexture by loading it in the UV edit window while the whole mesh is selected, choose disply - textured solid on the right of the 3D view and check that everything is textured as it should be. The texture on the pocket is different cause I use multi-texture, so 2 differents uv map. OK, that should explain the different scales. My mesh has 30055 (I have a belt in rope) so what is the problem with that ? There is a part of the source code that starts a new "hidden" material (but with the same name) when the triangle count for one material exceeds 21844. When you check "select faces" and apply a colour (and I assume texture - I didn't test that*), it gets applied to only the "hidden" material, leaving others unchanged. You have to select the unchanged bits and apply it there too. Strangely, if you keep applying new colours, it eventually starts affecting the whole area (I don't understand that on. Probably something to do with the same niming.) If this is your problem, then that should be the solution. The test meshes I investigated this with were all triagulated and the aberrant colours were triangular. If you are uploading quads, that may explain the difference. The amount of dark patches seems abou right with the triangle count you have given. On the other hand, I would suggest that 30k triangles is very excessive for this item. There is no LI-like penalty for attached mesh, but it still affects the fps by giving the gpu too much work, especially for the wearer who sees the highest LOD all the time, but also for everyone else with possibly less powerful graphics cards. The simplest solution would be to simplify the mesh. Halving would take it below the 21844, but I would suggest being more drastic. Use smooth shading, not high poly density, foe smoothness. *ETA: So I tested it. Effects of adding textures with selec faces and dialog, or by dropping them on the mesh, is the same as for colours. More below.

Looks like a UV mapping problem to me. There are three kinds of area. Two seem to have the same texture but with different scaling. So those are mapped with different ratio of mesh area to UV area. The third looks like a solid brown colour which could be one pixel from the same texture. That would happen where the UV map of that area was completely collapsed to a point, so that the whole area receives the pixel colour at that point. I don't know what software you are using, but it probably has the facility to look at the texturing before you upload it. That would reveal these sorts of problems. Also, you can select parts of the mesh geometry and see where the corresponding vertices appear in the UV map. It's possible that you UV mapped the separate pieces separately, so tyhat they gor different scaling. The collapsed parts could have escaped mapping altogether, or could have been constrained by inappropriate UV seams. You need to make sure all vertices are selected and then redo the mapping. Then apply a texture in the 3D program to make sure there are noi problems because of bad seams. There is another problem that can arise if your mesh has more than 21844 trianles, but I don't think that's the problem here.

Me too. Can't login for two days. I don't get an error. It jusy hangs. What's going on?