Drongle McMahon

Were you using any auto-LODs? The GLOD thing that does the automatic LOD generation can produce different results each time it is run on the same mesh, and that can sometimes result in substantially different LI.

For what it's worth, I have put in another jira (BUG-41239)suggesting that the 21844 triangle per material limit for <polylist> geometry should be avoided, so that they would behave just like triangles, making this sort of complication much rarer. Don't hold your breath!

OK. I found in the source code how this happens. Basically, when the uploader decides to start the new material, it creates a new face with default values for the "Extents" *(the min and max vertex positions in each dimension). These are the unit cube around the origin, for some reason I can't fathom. So for the new material, it behaves as if it had detected vertices at the corners of that cube although it didn't. Now as it reads in more vertices, one of the limits will never be changed if all the real vertices lie to one side. Thus we are left with the bounding box that includes these ghost vertices. Should be very easy to correct this with two lines of code, copying the extents from the face before the split into the new face. I will do a jira. I hope nobody has been using this as a feature! * For the technically minded, this happens at line 551 in lldaeloader.cpp, in function load_face_from_dom_polylist, where the default constructor for LLVolumeFace is used. That is in llvolume.cpp, lines 4562-4586. (current source). The load_face_from_dom_triangles function does the same. So it would presumably have the same effect if yoiu did get a material split, although that is less common and needs many more triangles. ETA: BUG-41232

Or ... if it's only the bottom that matters, and you can put up with some obstruction above, move the origin to exactly 0.5m above the bottom of the mesh. (Still, the best thing is to redfuce the triangle count.)

Let me offer a more precise definition of the effect (bug) ... If a material in the high LOD mesh gets split into more than one material because (a) it is specified in a <polylist>, and (b) it has more than 21844 triangles, then the bounding box will include the unit cube (1x1x1m) around the origin of the coordinates in the collada file, irrespective of where the actiual geometry lies with respect to that origin. This causes the behaviour shown here by Aquila. It also explains the effect on the physics of your cloth. That had more than 21844 triangles, and was therefore split into two materials. Consequently, it's bounding box will stretch at least 0.5m from the collada (Blender) origin in each dimension. That goes below the bottom of the geometry. Then the physics shape is stretched to fill that bounding box. It doesn't matter that the origin is inside the geometry; the effect will still happen if the mesh is thin enough in one dimension (z in your case). In the larger mesh, which includes the bench, the offending unit cube is entirely withing the bounding box of the geometry, and therefore has no effect. Still looking for it in the source code. Should be easier with the better definition.

I did a few experiments, with results that surprised me a lot. It's not just physics. At least with a mesh cube which has abour 27k triangles, so that there is a secret second material made, the transformation calculations are affected in such a way that the origin is now included in the bounding box, although there is no geometry there. (In fact it's a little more than just the origin). So even if you just upload a 27k cube 2x2x2m after moving the geometry 3,3,4 m in x,y,z, and use default LODs and physics, you get this large bounding box, 4.5x4.5x5.5m, with the actual cube in one corner, with the pivot/origin outside the geometry. Because of that, any uploaded LOD or physics gets expanded to this bounding box. So it's the maths that's supposed to shift the origin to the center of the geometry that fails after the material split. I haven't been able to find out where this happens in the source code yet. Anyone know if there's already a jira for this?

I suppose you mean [X+Y-Z+] ? Erm...No. I'm pretty sure I mean normal maps for SL should be X+Y+Z+, while the one for the stone wall in the OP was X+Y-Z+. I even retested it to make sure. Here is a picture with normal maps baked from a plane with a protruding part sphere to a flat plane in Blender: X+Y+Z+ (Blender default) on the left; X+Y-Z+ on the right (you can change the swizzle in Blender bakes). These are viewed at noon, with the sun directly overhead. So the left one, X+Y+Z+, gives the correct shading, while the other one doesn't. The same maps show the same shading effects in Blender, which is listed in the cited polycount article as being X+Y+Z+. ETA. I don't think there's really a right or wrong here, is there? Different sofware/shaders use different swizzle, at least according to the polycount article.

The "swizzle" of the normal map [X+Y-Z+] is wrong for SL. It has to be [X+Y+Z+]. That means the green values are interpreted as the opposite direction. You can correct this by inverting the green channel (because the green value is interpreted as a signed integer vector, it will remain normalized). Here is a cube in SL using your map on the left, and with with inverted green in the middle. At first sight, mirroring in the vertical axis has a similar effect (on the right), but that invertes the pattern of the stones too! For SL maps, the normal map should look as if lighted by cyan from above and by magenta from the right. You can read more about swizzle here (together with the more subtle but more intractable effects of different tangent basis). The swizzles of various packages are listed there too.

If I understand better now, then, unless you have access to the avatar mesh itself, you could not add appropriately UV mapped geometry for overlaying the transparent animated texture (any layers already there, like tatoo or clothing layers, would not be appropriately mapped). However, it's theoretically possible for you to make a rigged mesh overlay consisting of the animated stripes, with approriate UV mapping to transpose the linear texture animation into whatever sinuous motion you are after. Effectively, that would be wearing the stripes as tight fitting clothes. I'm not sure that that would be at all easy though, especially without the mesh itself, even if you have access to the dummy the creator says is coming. ETA. Having watched a youtube about using glow stripes on the av, I see that this is done by wearing a second copy of the same av with the (mostly) transparent textures on. However, that would not have the right UV mapping for the kind of texture animation I imagine you want using just the llSetTextureAnim smooth animation of a single texture. UV mapping is the key.

Which texture needs to be animated? Is the rainbow running along the narrow strip, or is it moving in the large texture behind the static strip? If the latter, is the rainbow's movement following the curve of the strip? Is the curve of the strip fixed, or do you need to be abler to change it inworld? I ask these because there is a lot you can do with mesh and careful UV mapping to achieve complicated texture animations withgout using huge amounts of texture resource, and your case may have that kind of solution.

I think it will still happen with triangles, but at a higher number of them. I can't do the experiment though (yet), as I only have Blender. I'll have to go back to the source code and see if I can see why the bb changes with the split and offset origin. Ugh.

The physics gets stretched to the extents of the bounding box (bb). So it looks like there is some extra, invisible geometry there in the visual mesh, that extends the bb. Would have to see the dae file to see for sure. What package did you make the cloth with, and how was it exported? There could be differences from either. Are there means to setect stray vertices etc?

Looks like too low setting for "Glossiness" (specular exponent). Specular reflection as added to the diffuse reflection (in contrast to environmental reflection, which replaces diffuse reflection) and can have this kind of washing out effect if it is too unsharp. The specular reflection at any particular location is determined by a combination of the geometry with three other factors. It's sharpness, that is the tightness with which it is constrained around the angle of perfect refletion depends on the specular exponent, which is controlled spatially by the values in the specular exponent map (in the alpha channel of the normal map) and globally by the value of the "Glossiness" setting. The combination these two factors appears to be multiplicative. Then the intensity and colour are controlled spatially by the specular map RGB channels and globally by the setting of the specular color. Also, as the reflection is sharpened, more reflection gets concentrated into smaller areas, which increases the intensity there. It is very easy for the reflection to become saturating, obscuring the diffuse texture completely. So the way to reduce this washing-out effect is to increase glossiness, directky and/or by darkening the a;lpha channel of the normal map, and/or to decrease the intensity of the specular reflection by darkening the specular map and/or darkeing the specular color. You have to play around to find the mosr effective values. They will depend on what lighting conditions you will be using. Here is an example. There are five discs with the same diffuse texture. The one on the left has no normal or specular map. the next four all have the same normal map, which is supposed to make the gold parts appear to protrude. It also has an alpha channel that modulates the specular exponent spatially. The second disc also has a specular map applied, but in the last three it is blank white, as in your example. The glossiness is set to 20 for the third disc, which exhibits the washout effect with the light from a local light above the camera. In the fourth, this is partially mitigated by setting a gray specular colour to reduce its intensity. \in the last, instead, the glossiness is set to 128 instead. Neither of these is as effective as using the proper specular map. For what it may be worth, here are the normal and specular maps RGB (half size). The alpha channels of both were identical to the specular map as shown here.

"Is there any reason why scripting wouldn't be preferrable over this method?" Is there any reason it would be preferable? I'm not sure whether you mean scripted editing of the collada file or scripted addition of a vertex. Either way, I would expect most would find it easier to do it this simply in the tool they are using already. Of course, if you spend a lot of time scripting, your preferences might get inverted. ETA: Ah ... from Arton's post, I guess you may have meant scripting the rotation about a different axis. I wouldn't have described that as offsetting the pivot. As he says, that would save the LI penalty, but then you burden the server instead. Anyway, as I hate rotation maths ...

"You can reuse baked textures too" Yes indeed. In my experience, that is very good for high resolution detail with minimum texture area, but, the way I have ever used it, you have to be extremely accurate in the geometry to get the ao to match perfectly. Here's an example I did during the beta. Not sure I would find the time nowadays. It was a real pain getting the pillars arranged to match exactly. It also restrained the geometry a lot. The savings are not nearly as high as using only tiles though.   ETA: Damn. Why does the forum software degrade these images so badly? .... Replaced. ETA: Note that this was all before Advanced Lighting.

I have to imagine your recollections are inaccurate. As far as I remember, the inworld pivot/origin has always been the center of the xyz-aligned bounding box. During the beta, there was an experimental pivot offset mechanism, but it was discarded. However, if you are using Blender, there is are two simple ways to move the pivot. However, both of these are ways of extending the bounding box beyond the extent of the visible and physics meshes. That inevitably increases the LOD switch distance, and therefore the download weight. First is the invisible tab method, described in an old thread. The trick here is how to make sure the added tab doesn't get included in the physics. This is undocumented and is therefore not guaranteed to be everlasting. It's unlikely any changes would affect existing assets though. The second depends on an even more ubscure "feature", that I did actually report as a bug. So it may be even less likely to remain effective. Again, any change is unlikely to affect existing content. It depends on the detail of how the bounding box is initialised in the uploader, as a zero-sized box at the position of the first encountered geometric point. Subsequently, the box is updated whenever any corner of any triangle lies outside it. If the first point in the collada file is outside the bounding box of all triangles, then the final box will still include that outlying point. So all we need to do is to add a point in the appropriate place, and make it first in the list. Here is how to do it in Blender, for a simple door. There are variations, of course, in how to place the extra vertex. The crucial step is the sorting of the elements so that the extra point, not part of a triangle, is first.  1. A simple door. 2. Snap the cursor to where you want the pivot/origin. Set editing to cursor mode. 3. Extrude the opposite extreme point and mirror it in X, Y and Z. 4. Snap the cursor to the extra point. 5. Select all and sort elements (Mesh->Sort Elements->Cursor Distance). Here is the result inworld...  ETA: To get the physics right for this door, it is essential to use the high LOD, then to "Analyze", and to set the type to "Prim. Otherwise the whole bounding box will be solid with an invisible other half. If the door is more complex, then you could use a simple mesh like this as the physics mesh, remembering to Analyze and set to Prim. ETA: Also, don't forget to add the extra poit to all LODs and to redo the sorting before you export after any changes!

"reusing assets is by far the most important thing" And that's surely the most important advantage of using reuseable textures, tileable or otherwise, instead of baked textures. They can be used on a whole set of different models, so that you don't have to download a new baked texture for each. I guess it depends on how an area is set up, only really working of there are a lot of things made by the same person.

Here's an example of what I was trying to describe. This is a bowl with a very concave base and a double surface. Where you are looking through the outside and the base, there are thus up to eight surfaces you are looking through, but half always have their normals pointing away and are not rendered. So in effect we are looking through up to four rendered surfaces. The versions on the left were all exported without triangulation, while those on the right were triangulated by the exporter. At the bottom, all the surfaces are a single material. In the middle, the inside and the outside are each a different material. At the top, the main bowl and the concave base are further separated, so that there are four materials. The four material version removes all the artifact for this relatively simple geometry, because we are now never able to look through two rendered surfaces that share a material. In the middle, where we are looking through both the outer bowl and the base, and only there, we are now looking through both outside and inside materials twice, and the artifacts appear. They are different depending on whether the triangulation is done by the uploader (left) or exporter (right), but neither eliminates them. At the bottom, we are now looking through the same material everywhere (except through the opening at the top) - with the uploader triangulation (left), the artifacts are much less obtrusive where we are looking through only two layers, but are still very bad when we are looking through both bowl and base - with the exporter triangulation, the artifacts are terrible everywhere.  If you can arrange your geometry and materials so that you can avoid all views where you are looking through the same material twice, then you can avoid the artifact. Otherwise, you may be able to mitigate its severity by avoiding the exporter's triangulation (which produces the most damaging ordering in the triangle list).

With surfaces that convoluted, it may be impossible to arrange materials so that none overlap themselves from all points ov view. If you are using Blender, you might achieve some improvement by deselecting the "Triangulate" option in the colladaexport options, letting the oploader do the triangulation. (It seems that the Blender triangulation puts half of each quad in different halves of the triangle list.) That's not likely to remove the problem entirely though. Do you really need inside andoutside for this mesh? It looks to me as if you only ever see it from the outside.

Well. I finally wrote my script to do a specified (to power of two) rounding of vertex positions, normals, and/or UV cooordinates, in a collada file. The idea was to avoid vertex splitting cause by "wobble" as well as possibly correcting small misalignments. It worked as expected as far as the vertex count of the high LOD was concerned, but a very odd problem appeared with the basket-like table model we were using. After some applications, with particulat rounding stringencies, the resulting collada files couldn't be processed by GLOD. The vertex county stopped getting reduced after one or two steps, ending up with very high download weights. Now this model is rather like the cases we have discussed here before where toroidal geometry blocks GLOD. However, it is very surprising to me that simply changing the precision of the data can affect whether we see this behaviour or not. Some further investigation is warranted, I think, before I can recommend this approach. In practice, for this model using GLOD for a model using the bevel+transferred normals method to get rounded edges is completely useless anyway, because the normals, and so the shading, of the resulting mesh is badly messed up. In that sense, the GLOD sticking problem doesn't matter because you have to make LODs manually anyway.

I think the shape was chosen because they wanted something vaguely round, but with flattened endss so that it could stand stably in one orientation. Sculpts were originally intended for "organic" shapes, by which was meant something blob like, rocks, apples etc.

with one side angled inwards it isn't a convex hull I guess I wasn't clear enough. The sculpty physics shape is the convex hull of the low LOD torus, not the torus itself. Here is another picture. Torus on left, sculpty on right, top ones rotated 180 degrees, so that you can seeboth ends. So the top left is what I meant by angled instead of flat. Both ends of the sculty have flat ends because they are the convex hulls of the shapes to their left. As you can see, the diameters of the flat faces (nonagons) is different at each end. That's all an inevitable consequence of having nine segments.*  Concerning the astronomical physics weights - I suppose it's just possible that whatever causes the weight calculation to be so high might actually also make a huge amount of work for the physics engine. In that case, it would be better it was left until the cauise was removed by updating the havok engine. It might be possible to determine this by looking at the effect on the region phsyics time after setting up collisions of similar objects with and without the excessive weights. *ETA That was wrong! In fact it depends on which axis you spin the minor circle in. If it's perpendicular to one edge, then you get a symetrical torus with the same structure at each end. If it's at 90 degrees to that, you get the SL version, with one flat annular end face. Same thing if you consider the axis fixed. Then it depends how you arient the minor circle before spinning it.

I can't find any explanation why size matters to triangle physics Not sure about that, but if you think of your avatar, or a flying prim, colliding with a small triangulated surface, you will be near enough to many triangles to require collision calculations for each. If the same triangles are made much bigger by stretching the surface, so you only get near one at a time, then there are that many less calculations to do. Nor can I find any explanation why long and narrow triangles are such a bad thing... No idea. Probably something to do with the details of how the collision detection calculations work. or why some twisted prim shapes end up with those astronomical physics weight figures That is certainly a bug. A jira on it was accepted, but then resolved as "Trivial" and "Unactionable" because changes to the calculations could affect existing content (also considered. I don't know whether the bug is in the Havok code or the SL code (on the server). If it's the Havok code, there must be a risk that weights could change if/;when a library update is adopted.

The physics weight of a prim cube is 0.060, a mesh cube 0.360 The physics weight of a prim cylinder is lower than that of a mesh triangle Because these are using the havok primitives - apply some torture to the prims and see what happens to the weights. I'm not sure if Havok treats the physics of a sculpt as 36 triangles or a single 14 sides convex hull (the calculated physics weight suggests triangles) but in either case it seems to be an unneccessarily complex shape The physics shape of all sculpts is the same - the convex hull of a torus with equal major and minor radii, fitted into the bounding box. The flat ends are in the YZ plane. Here is a picture. Two each of a prim torus, at the back, and a spiral stairs sculpty, at the front, all 2x2x2m. The ones to the right have been made into static obstacles to reveal the phsyics in pathfinding view. These are the Prim type shapes, but I suspect the sculpty is really always convex hull, because its physics weight (1.8) doesn't change with size. It is actually the low LOD of the torus, which has 162 triangles (9x9x2). It's a bit odd because the two ends are different. One has the flat faces you can see, while at the other they are angled. Consequently, the diameter of the flat face of the convex hull is different at either end! 

...yet we can have quite complex hulls as part of an analyzed physics with little or no increase in physics weight. Are you sure you aren't thinking of the physics weight the uploader displays, which is the default Convex Hull for the whole mesh. If you have an "Analyzed" physics shape, this will be the single complex hull containing of the whole collection of hull generated. It's weight will depend on the number of vertices, and thus on the complexity only of the outer surfaces of the collection. The phsyics weight of the analsis result will only be applied when you switch it to 2Prim" inworld. The weight of a physics model made from a single triangle is 0.200 Yes, I never tried a single triangle before. Very odd. The 0.2 is the (size-invariant) default CH weight, the same whether you analyze or not. Switching to Prim, the triangle-based weight is 0.5, strangely not varying with size, while the analyzed weight stays at 0.2. However, there is another very odd thing that has to be called a bug. The default CH are not where they shoud be. The visible mesh is in the middle of the bounding box in the direction perpendicular to the flat plane, and the phsyics shape view shows the physics there too. But it isn't. If you reveal the actual physics shapes by making them static pathfinding obstacles, then rebake the region, you can see the actial phsyics, as shown in the red triangles. The left pair is the default CH setting, while the right is the, correct, Prim setting. Both these are analyzed, but the behaviour is the same for triangle-based shapes. The nearer one is a triangle in the YZ plane, while the further away is a triangle in the XY plane. If you try walking over/through them, you see that the red triangles are indeed the actual physics shapes. Ugh!