Drongle McMahon

OK. I did some experiments. I would definately call this a new bug. It's quite complicated, so I will try to explain the relevant background. First, there is a mechanism whereby the physics shape type used by the server switches from Prim to Convex hull without telling the viewer. This happens when one dimension of an object reaches a certain minimum. This minimum used to be 0.01m, but was made much bigger some time ago. This broke a lot of content, including thin walls like yours. It doesn't show up on the Physics Shapes display because the change is hidden from the viewer. So you can only detect it by trying to walk through (bug #1). This is what is stopping you from going through the door although the display says it's there. However, you provoked me into some experiments that reveal another situation that certainly did not happen last time I tried anything like this. The effect doesn't need a doo, just two square planes opposite each other. Direction of normals doesn't matter. If you upload this as a thin wall (Aditi or main grid), and set it to shape type Prim, it looks fine while it's thin, because it's secretly using convex hull, as described above. However, if you stretch it so as to move the planes apart, when it reaches the point where it switches to actually use Prim type, there is a sudden and huge invreae in the physics weight, to several thousands! (bug#2). This is certainly new behaviour to me. With the example I started with, a wall with door holes, the physics weight went above 15000, and it disappeared amid some error messages saying the parcel was full. Did you look a\t the LI and physics weight of the wall you stretched to be thicker? The effect can be mitigated by making just a single face linking the two planes. However, this causes a relatively small, but still large increase in the physics weight because it has to be narrow triangles. Consequenly, this has essentially broken the use of flat planes to make efficient physics shapes for buildings while maintaining wall thickness. The effect depends on having two planes. A single plane can be stretched without problem. A door in it can be walked through even if it is squashed to minimum thickness. (I would love someone to explain that.) Unfortunately, I am not going to submit a jira for this. Since I am not allowed to see what others have submitted, I can't tell if someone else has already submitted one. It takes a substantial amouint of work to prepare a jira with a good reproduction and test files. This is completely wated if someone else has already done it. LL obviously doesn't care if my time is wasted, but I do.Furthermore, there would be no opportunity there to clarify the problem by discussion with others. I would be grateful if anyone else knows whether this affects contenty uploded before the problem appeared - in other words whether it's a physics engine change or an uploader change. I can't test that because all the suitable content I has was lost with the Aditi password change bug. Any other opinions as to whetherv this is a bug? My guess would be that these problems were brought in with changes made for pathfinding. The timing is about right for that.

"So when you say traingle based its not how it is modelled in Blender but how the Uploader is treating the physics mesh ?" Yes, exactly. The Analyze button makes the uploader use the physics mesh (or the low-LOD mesh if you don't specify one) to make a series of convex hulls that approximate the mesh.How it does that depends on the mesh and the settings, and whether you then use the Simplify button. You can see that it has done this because the bottom below of step 3 tells you how many hulls there are. (In this case, it has made six flat planes, with four corners each, because you used the Surface method.) When you don't "Analyze", the physics shape will be exactly those triangles that the physics mesh is made of, and they will show up with thier edges in the physics shape view. The uploader will show the triangle count, but no hull count. You certainly should be able to walk through the door in the triangle-based shape you show, as you can clearly see the hole. If you can't, something else must be wrong. Either of these shapes needs the "Prim" shape type setting to use it. Otherwise, the shape will be the single default convex hull which will always fill in the door. The physics engine treats these shapes very differently when it has to detect collisions. More efficient algorithms can be used for convex hulls, and they don't depend on the size. So the physics weight of the Analyzed shape doesn't vary with the size of the mesh. With a triangle-based shape, it has to test for collisions with each triangle. For some reason, this is more work for small triangle. So the physics weight is higher the smaller the mesh is (and therefore its triangles are). Generally, physics weights are smaller for large objects with only large triangles. For smaller objects, the physics weight of the Analyzed shape will be smaller.

I guess ypu got there while I was making this picture. Never mind, it might be useful to someone else. Maev's suggestion of making the triangle-based physics shape is best when it's part of a building mesh, but (a) to do this, do not extruse the wall to make it thick. That will leave thin triangles along the edges which will increase the physics weight. If you want the more accurate collisions from a thicker wall, then you can do the extrusion and delete the edge faces. (b) to get a triangle- based shape, you must NOT press "Analyse". The picture is another way, when you want the doorway to be self-contained. It uses small boxes for the physics shape which is bad for a triangle-based shape. So it's a hull-based (Analysed" shape. At the bottom left is the Blender 3D window showing two separate objects, the visual mesh darker and the physics mesh lighter orange. Note that the boxes comprising the physics mesh are as simple as possible and not overlapping. Simplicity keeps the physics weight low and non-overlap avoids probelms with the "Analyse" function. At the top is the upload dialog, with the physics tab selected (pink). The physics mesh is set to "From File" and the dsae of the physics mesh is selected (orange). Now you leave the method set to "Surface" (or solid - with non-overlappinf boxes, either will work) (blue). Then you click the "Analyse" button (green). When thec analysing is done, the dialog will tell you the number of hulls and vertices (red). In the preview, the explode slider has been used to show the components of the physics mesh (yellow) separately from the visual mesh (white). The last three panels at the bottom show the imported mes - first in normal view, then in physics shape view (Develop->Render Metadata->Physics Shapes). First is the physics shape when the physics shape type is set to "Convex hull", which you can't walk through; second is the physics shape when its type is set tp "Prim", which you can walk through.

That will be the case when server baking is implemented. It isn't implemented yet. When it is, it is still a good idea to use the smaller textures because there could be a different source of lag if the baking servers and the internal network get overloaded.

"can you explain again" ... I'll try ... Now - For your avatar, all the textures get sent to you from the asset server at their original size (actually, there will often be copies in the texture cache on your hard dis, in which case they don't have to be downloaded). Your viewer then changes them to 512x512 (if they sren't already) anf uses them to make the baked textures with all the system clothing layers combined into one 512x512 image. The viewer then send that baked image back to the server whenever you become visible in a new sim. The servers send it to any other viewers that need to display you. So (ignoring the original upload) that is three trips onver the internet between clients and servers before anyone can see you. With server baking - there is a special server for making the baked 512x512 textures from the layered images. The original textures go there instead of to your client. Then the baked texture goes straight to the sim server which sends it to all the clients that need it, including yours. Now that last download is the only internet traffic needed. The other two steps happen inside the internal SL network in their server farm. As long as the capacity of the baking server is sufficient, this will remove any lag due to waiting for the internet transmissions that have been eliminated.

As far as I understand it, the textures will go from the asset server to a baking server, get resized and composited there, then sent to the sim server(s), then the baked texture will be sent (512x512) to all viewers including the one belonging to the avatar. So steps 1-3 are all taking place in the server farm instead of over the server-client link. The av's viewer is relieved of the compositing task, of downloading the raw textures and of uploading the baked texture.

First question - which kind of weight is cotributing most to your LI? You can see by looking aty the "More Info" link from the edit dialog. It's the highest of server, download and physics weights that becomes the LI. You might need to unlink the pieces to see the individual weights too. If it's server weight, you can reduce it by joining parts into one mesh, although this will increase download weight by affecting the size and the LOD switching. If it's download weight, you need to work on reducing the detail of the lower LOD mesh (which one depends on size). If it's physics weight, it's easy to reduce it by making simpler physics shapes.

One aspect of this seems to have escaped attention (unless I simply missed it, in which case ignore me). When textures are uploaded at 1024x1024, they are subject to lossy JPEG2000 compression at that size, the result is uploaded and downloaded to the viewer at that size, then resampled in the viewer before baking. So the sequence is JPEG@1024 then resample. However, if they are resampled to 512x512 before upload, the JPEG2000 compression is done on the 512x512 image. The sequence is resample then JPEG@512. Thus in addition to the possible effects of different resampling methods, the two procedures differ by the resolution at which they are exposed to the effects of the lossy compression. Is it possible that degradation is greater with compression at 512x512 than at 1024x1024? (My instinct says that is likely, but I am too ignorant to be certain - someone should test this, but it's going to depend on the compression ratio applied). Concerning lag - the only viewer that will download the larger textures is the one whose avatar is wearing the textures. Others seeing it will still only dowload the baked 512x512 texture. So the effect is not as bad as, for example, using 1024x1024 textures on attacments which will quadruple the dowload for everyone in viewing range. I believe the baking is soon going to be moved from the viewer to a dedicated server. If and when that happens, the only bandwidth affected will be that between servers. All this leads me to think, while largely agreeing with Chosen, that it is much more important to discourage the use of large textures on attachments, including all mesh clothes, than their use as components of the baked avatar textures (skin and syste clothing).

In Blender, you can have (parts of) a UV map outside the main 0:1 square, and when it comes into SL it behaves as if the texture was tiled infinitely in both ndimensions. So in that context, your tiling would work. However, I have never inspected such a case in the collada file. So don't know whether UV corrdinates are rounded to 0:1 by the exporter. I would guess not. In which case it would work in other contexts too (whether or not the uploader does adjust it). Of course you still have to use different materials if you want to apply different textures, but it would allow you to look at all their UV maps next to each other.

Physics shapes are no difficult. Just make sure they fit the same bounding box as the visible mesh. Then add them on the physics tab of the uploader. Simplest is to use non-overlapping simple shapes, but all in one mesh, and click the "Analyse" button. You still have to set shape type to "Prim" inworld to use it. You can use the simple physics with the more complex visual mesh to keep the LI low while still having complex visible shape. From what you say, I guess you were using two separate box meshes? If you specify a physics mesh and don't press "Analyse", you get a triangle-based physics shape. This gets much more expensive very rapidly if it has small triangles, which would be the case for thin legs. Even if you did use "Analyse", the chair legs would still give you a shape made of many convex hulls (use explode view to see them), whch can also be expensive. The rule is to use a simple shapes as possioble to get the collision behaviour your object needs, and to use "Analyze" unless the object is very large (landscapes and buildings, for example).

I guess this is a long-standing bug. So old that everyone can still see the jira! My guess is they can't be bothered to fix it because the workaround is easy.

Or, you can make a physics mesh with boxes for base and back, ans set physics shape type to "Prim". SitTarget is probably better though, as it's adjustable.

Ah. I am always in orthographic view. Also, you can only see the backround images if you are looking exactly along the axes (numpad keys). However, you can scale and offset them in the properties panel (2.64 at least), so you don't need empties for that.

2.64: 3D view, View->Properties; then in Prperties bar, expand "Background Images". You can specify different images for each direction.

Ok. The secret is out. It's because I've been installing my steam blowout preventers...

In Blender 2.49, you can get triangulation three ways, triangulte in Blender, triangulate in the collada exporter, or let the uploader triangulate (it will not upload quad data). They will all give different results whch can affect shading if the quads are not flat. So the only way to control it precisely is to triagulate in Blender before export and adjusty that if you need to. That can be VERY tedious. I guess in 2.6 etc, the collada exporter uses the Blender triangulation, but you still have to do it first if you want the opportunity to adjust it.

Develop->Show Info->Show Render Info (toggle on). This will show the triangle count of the selection near the bottom (as long as something is selected!). See the picture. Note that it depends on the level of detail the selection is displaying with, so it will change with distance.

Somehow I doubt that. My jira BUG-101 was submitted 14th Sept. It was marked as Resolved; (Status Accepted; Resolution Released; Fix Version/s None) on 17th Sept. It is not fixed in the latest beta viewer (266708, Nov 7th). I'd love to invite you to look at it, but of course you can't. I have to agree with Gadget, that the jira is now essentially useless to anyone other the select few with privileged access. It doesn't even give worthwhile feedback to the submitter, let alone the rest of us. I don't see any point in contributing to it in future.

Quite likely you are having this known issue. Good news is that there is a fix on the way.

I am puzzled by the shadows in these pictures. They don't look like shadows that would be cast on any particular surface. Are they just an enhancement to the illustration, or are they part of the meshes?

I don't know the actual numbers, but the colour indicates the magnitude of the physics weight, that is the strain it puts on the physics engine. Blue is nice and simple, going from green to yellow to orange to red as the weight becomes excessive.

The first question is always whether it is download weight or physics weight that is producing the land impact. It will be whichever is the higher of the two, and you can see which by using the "More Info" link in the edir dialog. Reducing download weight usually requires appropriate minimisation of geometry (triangles and vertices) and making good LOD meshes. Reducing physics weight is usually best achieved by making a very simple physics mesh. However, the best choices depend on the particular case.

If you upload the textures with the mesh, you have to pay the full fee whenever either is modified. If you keep the uploads separate, you only have to pay for the part that is modified. What if you want to have a dozen different texture options for one mesh? Are you going to pay the mesh upload fee for each one? As far as I can see, there is no real advantage to uploading the textures with the mesh, and there is this clear disadvantage.

As I don't use Firestorm, I can't make a good guess for the situation you describe. Hopefully someone who does will come along. Doesn't sound like a mesh authorisation issue though.

To be horribly technical, and probably not as helpful as Rolig, the UV map is just the collection of positions in the 2D texture image space* that correspond to each vertex in 3D space. When the texture is applied. it is done one triangle at a time. The texture from the triangle defined by the UV coordinates of the three vertices making the triangle is stretched to fit the triangle in 3D space that is made with the same three vertices. One consequence of this is that the textuire continues across any two triangles sharing an edge in the 2D UV map. Thus the texture covered by a UV "island" consisting of many triangles appears stretched over the corresponsing 3D triangles. The representation of the UV map in the authoring software is simply a drawing of the vertices and polygons in the 2D texture space. Superimposing this on the texture shows which areas of the texture will be allocated to which polygons of the mesh surface. This leads to the useful and accurate dress pattern analogy. Texture stretching may be different in direction and amount for different triangles, leading to distortion of the texture in the 3D surface. The task of the modeller is to ensure that any such distortions (such as the direction of woodgrain) is consistent with the desired appearance of the textured mesh. Sometimes, the pattern does not flow across adges. These edges are the UV seams, separating the UV islands. In these cases, the UV coordinates for a single 3D vertex are different depending on which triangle is being textured. In the SL data format, this requires the whole data for that vertex to be duplicated. This is why seams and fragmented UV maps (many islands) increase download weight and usually increase land impact. However, fewer seams generally leads to greater texture distortion on the 3D mesh. So a compromise has to be arrived at. *Generally the texture space is treated as periodic, so positions that fall outside the defined texture area are treated as being on a plane which has the texture infinitely repeated in all directions.