Drongle McMahon

The logic behind the calculations for the download weight (usually the same thing as LI) are based on the areas in which the LOD models are seen given a renderVolumeLODFactor (RVLF) setting of 1, a draw distance od 181m, and more or less assuming independent random distribution of objects and cameras in a 2D distribution. It's a good attempt to represent real cost, but these assumptions are not very convincing. First, it seems most people now use higher RVLF, so they are exposed to the higher LODs within much greater areas. Second, and more importantly, real object and camera distributions are highly non-uniform, especially with attachments, because avatars (and therefore their cameras) tend to cluster, and static objects tend to be concentrated where avatars are likely to congregate. Consequently, the apparent reward (in resource saving) of using very low detail lowest LOD is substantally overestimated. That means that this trick does not produce the resource savings that the LI appears to indicate, especially for attachments. Therefore is it not reasonable to regard the technique as a subterfuge to undermine the intent of the LI system, by consuming more resource while incurrring only an underestimated cost?

"will get by the Linden limit filters" :matte-motes-agape: ??? I thought the whole problem was that there aren't any for attachments?

I don't know how the prim export dimensions are done. S I can't comment on how to make them fit better. You can always stretch the whole mesh after you import it, which would deal with overall errors in the dimensions, but not with relative errors, foe example in the locations of inner walls. The models I made were fron scratch in Blender. To make them fit, you could use the exported models as a guide template, but if its dimensions are wrong, that won't be any better, So the best way to do it would be to make accurate measurements inworld (stretch a cube to the dimension and read the dimension from the edir dialog), and build to those. Turn on edge length display in Blender to check and adjust them. As /i mentioned, making separate meshes for each room would simplify fitting, as thery can be individually stretched to fit, but would cost more in nphysics weight. The way to do that would be to make them separate objects in Blender and import together. Trhat will make a linkset. As LeprKhaun pointed out, if you already have the extra walls as prims, then you don't really need the wallpaper to have physics if it fits properly. So you should be able to make meshes with inward-facing normals, like the triangle-based one but simpler, maybe just a cube for each room. Put the texture on those and just stretcvh to fit. At the extreme, you could use a separate flat plane object for each wall, with required cutouts for doors etc. Each simple mesh like this, when they are linked in a linkset, would cost 0.5 LI. Instead of using phantom, which still taxes the physics engine, they should have their physics shape type set to "None" after they are linked to one of you extra wall prims which remains as the root of the linkset (last selected before linking).

"I surely can't be the only one to ever try to upload something with more than one UV map" No. It has come up a few times. Usually it just results in highly distorted textures. I think the uploader chooses just one, and if it's the wrong one, you get problems. I guess in your case the wrong UV map was more fragmented, which could end up with it having more unique complete vertex data points than with a less fragmented map, because the vertices get duplicates when they appear on two sides of a UV seam. That could lead to the index overflow when the rest of the mesh data comes from using the less fragmented map.

In the LL viewer, the function load_face_from_dom_triangles reads the triangle/vertex data into the viewer from the collada dom (document object model) after it has been read by the collada library. It uses another function, get_dom_sources, to get the locations of the position, normal and texture coordinate data. That function returns an error if it fails to get the requested pointers, which causes load_face_from_dom_triangles to return a BAD_ELEMENT error. So anything that causes a problem with any of the data will give the same problem in the LL viewer. It looks like the Firestorm viewer has a much more informative error message and/or detection, narrowing down the cause to a failure of a test in the TC (texture coordinate) data. Since I can't find the relevant file in the Firestorm source, I can't say exactlky what test produces that error. Someone who knows the Firestorm source might be able to say. However, it seems likely to be something to do with the UV map. Do you have a UV map? Do you have multiple UV maps? (the importer doesn't like that). ETA: looked at newer source code from LL viewer ... the error message is now there. I guess it just goes to the log when using the LL viewer. It's after the checks on the indices of the texture coords (tc). So it's surely a UV map problem... if (((i + tc_offset) > index_count) || ((idx[i+tc_offset]*2+1) > tc_count)) { llwarns << "Out of range TC indices." << llendl; return LLModel::BAD_ELEMENT; }

Here are two main alternative ways of making a cimbined wallpaper+physics shape. I hope this is something like your building. I have ignored the floors, assuming you are happy with thise as they are. For now, I'm also assuming the wallpaper is tyhe same throughout. In Blender, on the top left is a solid wall mesh, with the number of triangles minimised. Importing this as the physics and doing Analyze (solid) pruduces 16 hulls. The Prim-type physics weight inworld is 5.8, and that becomes the LI. The mesh on the right has single plane walls with. It's basically two boxes with the required cutouts, again manipulated to minimise the triangle count. Note, however, that the normals are flipped to face inwards where the wallpaper has to be visible from. Also, that bthere are no expensive narrow faces anywhere connecting the edges of the walls, just the main faces. This is uploaded as the physics mesh without Analyze, producing a triangle-based shape with 56 triangles[1]. The inworld Prim-type physics weight is 0.7. So the LI is just 1[2]. From that result, it looks like the triangle-based shape may be the best option for this kind and size of build. It can be imported using the same mesh as high LOD and physics. That has an LI of 1. The download weight is 0.1. The bottom of the picture shows the two models inworld, blue for triangle-based and red for Analyzed. In the middle, you can see how the triangle-based shape will fit into the house. If you need different patterns on different walls, you can use different materials, but that will require the use of more smaller triangles, which will increase the physics weight. To make the fitting easier, you could even make each room a different mesh, so that the imported model is a linkset. Then you can stretch each independently to fit it to the existing walls. Agian, this will increase the physics weight, and the LI will be a minimum of 0.5 (server weight) per room. Something in between, like making the two boxes here as separate mesh objects, migh be the best compromise. While watching me test these, Aquila suggested that you could save physics weight by usihng the whole mesh for the visble mesh, but just the additional walls in the physics mesh, relying on the physics of the existing walls where that is satisfactory. This could save a lot of weight. The only thinh to remember is that you must make the physics mesh fit the same bounding box as the visible mesh (otherwise the uploader stretches it to fit). So you might have to add a few extra walls to ensure that. Notes: [1] This can be reduced further to 36, by separating pieces to avoid triangulation. [2] This is with the design size of 11.8x10x10m. Triangle based weights get larger as the triangles get smaller. [3] Triangle-based weights are unpredictably variable, depending on the order of triangles or quads in the collada file. For example, the 36-triangle version had weights from 0.5 to 1.5 in a sample of five different triangle orders.

"you can not have normal maps without specular" Not quite true, I think. Normals affect diffuse reflection intensity as well as specular reflection. The effects are more subtle. butv thety are there. From left to right - 1) glossiness=0, environment=0; 2) g=0, e=0; 3) g=0, e=200; 4) g=50, e=200; 5) g=50, e=0. All except (1) have the same normal map (blank in 1). Local light above/in front of each. 3pm, sun from right. Glossiness=0 means no specular reflection. Environment=0 means no environmental reflection. ETA. Another example. This time, top right has normal map but no specular map; bottom left has specular map but no normal map; bottom right has both; top left has neither. All blank diffuse texture, 3pm looking downwards towards sun. All env=0, gloss=51. ETA2: whoops - had +/- wrong way round at top. Corrected.

I think you need to repeat the texture. Assuming it is alreadt tileable, then it depends on how you are doing the texturing. If you are simply applying the texture inworld, then just go to the texture tab of the edit dialog and set the repeats to the appropriate numbers in both horizontal and vertical directions. If you are combining the texture with, for example, an ambient occlusion map in gimp, then you need to make a repeated version in gimp. To do that, first reduce the size of the texture, Image->Scale Image, by an appropriate (power-of-two) factor, using cubic or sinc interpolation. Then use Filter->Map->Tile entering the original image dimensions to restore the size of the image with multiple repeats of the small version. Then proceed with the combining steps as before using the tiled image.

Hmm. I think we would need the blender file to work out the cause of this one, or at least the collada.

I couldn't reproduce the filled-in effect you show, even with the self-crossing ngon(s) you have. So I would also check the normals : Mesh->Normals->Recalculate Outside.

You can try just redoing the alignment and leaving the collada. If you want to look at it, use wordpad rather than notepad. It will recognise the line formatting. Even better is something like Notepad+++, which recognises the xml format. The relevant numbers are in a section something like this... <library_geometries> <geometry id="Cube-mesh" name="Cube"> <mesh> <source id="Cube-mesh-positions"> <float_array id="Cube-mesh-positions-array" count="24"> 0.1 1 -1 0.1 -1 -1 -0.1 -1 -1 -0.1 1 -1 0.1 1 1 0.100004 -1 1 -0.1 -1 1 -0.1 1 1 </float_array> The numbers are in triplets that give the the x,y,z for each vertex. This is from the bug report in the jira. Each wall is flat in the YZ plane. So the Xs should be 0.1 or -0.1. It's the "0.100004" that caused the high weight in this test case. Setting it to 0.1, like all the others, so that the vertices are perfectly aligned, removes the excess weight. Note that this was before the introduction of the automatic switch of triangle-based shapes to convex hull at a width of 0.5m. These walls were only 0.2m apart and I guess they would now be converted to convex hull unless there was more geometry increasing the x span of the shape. Yes. I tested it. The physics weight now jumps from 0.4 at 0.499m to 7987 at 0.5m !! Don't waste too much time on this just to satisfy my curiosity. Your solution of adding geometry works well and doesn't cost much.

Yes. That's another way of fixing it. Did you try realigning the planes too? I'd be interested to know if that worked - to see if it's that old bug. I don't think it will make much difference adding the longer face at the top instead of the shorter one you used. According to the definition in the wiki, the "average width" of the triangles in those two faces would be the same (the gap between the walls), so that they should have the same cost. However, I take the definitions in the wiki with a large pinch of salt as the actual weights are not consistent with the wiki for either triangle-based or hull-based shapes. So who knows? You may be right.

Not sure, but sometimes the update to the LI when you set it to Prim is delayed. The weightrs and LI data have to be fetched from the server. Maybe that gets slowed down sometimes. So it's not that unusual if it was shortly after changing the shape type. Otherwise, I don't know.

Analyze would produce a hull-based instead of a triangle-based physics shape. Usually that would be quite satisfactory as an alternative, especially with the simple model shown. However, there are circumstances, in more complex models, where it might not. First, if the walls are large, then the hull based shape is likely to have a higher physics weigh which might produce a higher LI. Second, for anything at all complex, unlike the triangle-based shape, the hull-based shape would be better made from solid components with the edges filled in (a simple change, of course). Otherwise closing of spaces during the decomposition (Analyze) is likely. Since the potential solution is even simpler, it's worth trying. I am assuming there is a good reason here for having decided on a triangle-based shape.

There was a bug (jira here) which causes huge physics weights when there is a miniscule displacement of one vertex of the first-listed triangle out of the precise vertical plane. The smaller the displacement, above a minimum, the larger was the effect. It was imported into the internal jira. So I don't know what happened to it after that. Since it was classified as trivial, quite possibly nothing. Sounds as if that is what you have run into, In that case, the excessive cost should go away if you realign the vertices so that the walls are exactly vertical. You can do that in your 3D program or by editing the collada file. To check that the collada exporter doesn't reintroduce the displacement, you really need to check the file, but first just upload it and see if it makes the difference. There are other problems with the triangle-based physics weight calculation that can produce similarly high weights. I have documented some of them in a few threads in this forum. Search for "Physics episode" if you are interested. Be warned though, it is a complicated issue.

As is explained in the wiki link given above, this function, available in the earliest mesh implementations, was deliberately removed because of the unacceptable effects on performance with animation done this way (aka lag). Flipping textures (or frame animation) of sculptmaps is also expensive on performance because the geometry has to be regenerated for each frame of the animation, although it may involve less download/cache accessing than with the old mesh asset. So the simple answer is no. It is not possible. You have either to use delete/rez, with the disadvantages you are aware of, or hiding alternate meshes with transparency. The latter incurs the LI cost of the extra geometry, and thereby accounts for the high resource consumption. Since attachments don't count against land LI capacity, this disincentive is not present for attchments, but cost in performance is still there.

I agree with Aquila's assesment. Make sure you have the same number of Blender objects in the exported models for pjysics as for the high LOD. Also, make sure you have applied rotation and scale for each object. (Then the rotations in object mode should all be zero, and the scales all 1 - I can only see how the two hulls we see came from one of your meshes if it was rotated). Finally, make sure the object names have the same alphabetic order in the physics mesh as their coresponding objects in the LOD mesh. I think your physics mesh could be quite a bit simpler too. Remember that the physics is invisible.

"...as it seems contradictory..." Not really, I think. That physics shape is solid boxes, each with an inward facing and an outward facing surface. So it is like the double skinned one that Aquila described last, and it resists penetration from both sides. The main potential problem is that it has all the narrow edges too. That could increase the triangle-based (not Analyzed) physics weight a lot. If it's still less than the download weight, then that won't affect the LI. If it isn't, then you could delete just those edge faces and the physics weight would be reduced without affecting the collision behavior. That would also reduce the collision detection work the server has to do.

Yes. I think it is a recent change, although I haven't done test for quite a while. Possibly a new version of the Havok physics engine. Something on the server anyway. I guess we could ask about recent changes at a server meeting.

"This will mean avatars will be able to walk through from the inside to outside" That intrigued me, becuase That had not apparently not been the case for many buildings I have made. I once did a long series nof tests which ended up with the conclusion that going through triangle-based walls happened occasionally, more if you wre moving at higher speed. There was a slight bias for it to happen nmore when you were moving in the direction of the face normal, but only slight. So I id some new tests. It looks like the behavior has changed quite a lot, making it much easier to penetrate in the normal direction (ie from the invisible back). This does indeed make it necessary to have both sides of triangle-based walls for the railcar model. I'm going to have ro do some rebuilding (or more likely demolishing) unless my walls are big enough alreaqdy. However, it's not quite that simple. I tried a wall (about 4x4)m consisting of a single quad, and the same size wall subdivided into 8x8 quads. The one with the small quads offered no resistance at all to walking through it from the back. Same thing if I reduced the height of the wall to about 1m. So it appears that the effect depends on the narrowness of the triangles. If you have big quads, you may be ok with one-sided walls. If you have smaller ones (as you need when you have windows) then you are going to need both sides. I also noted the return of a very old bug that I thought had gone away in the mesh beta. With the subdivided wall, even though it is exactly vertical, from the impenetrable (visible) side you can walk up it as if it was a slope! A wall isn't much use if you can simply walk over it! (In the original bug, this happened even with un-subdivided walls). PS: I left the test walls (as boxes) out at Mesh Sandbox 1:176,77 in case anyone wants to play with them before they get autoreturned. Blue=unsubdivided; orange=subdivided.

"Would THAT make a difference?" Basically, yes. I did some experimets with a cube with windows in each of it's six faces. This isn't as bad as your case, but the LOD generation stops after the first (medium) step, if and only if it has no UV map and it is smooth shaded. Looking at the LODs in the uploader, it makes a complete mess as the first step, with alternating normals etc, and that obviously stops it going further. This is indeed the phenomenon Aquila pointed to in that thread from last year. It's a problem with the GLOD library that the viewer uses to generate the LOD meshes. It's nothing to do specifically with the solidify modifier (a manually solidified one worked exactly the same). It's just that the solidify process produces torus-like toplolgy from the openings, which is susceptible to this problem. Making UV seams and/or and/or making sharp shaded edges causes the uploader to split the mesh along the affected edges, which you can see as an increase in the vertex count (but not the triangle count). So it looks like the GLOD functions are applied after that split, and that having the split edges somehow avoids the problems that get it stuck. Quite why your railcar should stop at the first step, I don't know, but it is likely something to do with the details of the geometry. I can't quite see how the roof is joined to the walls. There could be problems there. (Select non-manifold to see where some problems might be). Otherwise, I think the GLOD library is probably always going to have problems with torus-like toplogies with unsplit edges, including those that can be generated by the solidify modifier. ---- The physics shape shown (I presume) in your second picture should decompose (Analyze) into 8 hulls with 64b total vertices. These numbers should be visible at the bottom of the physics tab after you click Analyze. That would have a physics weight of 8*0.36 = 2.88, which would round up to 3. I think that's what you said your physics weight was before applying the solidify modifier. That makes me guess that you may have applied the solidify modifier to this physics shape. You should not do that. The parts are already solid. You could very likely get a lower physics weight from a simple triangle mesh, but if it's already lower than the download weight, that will not affect thev LI.

I am having difficulty understanding your first question. When you say the uploader "refused to generate any lower numbers", what were you expecting? What should have been lower, and what should it have been lower than? The change to LI when you switch the physics shape type to Prim indicates that the physics weight of the uploaded physics shape is higher than the download weight of the LOD meshes. Without knowing exactly what you used as the mesh for generating the physics shape, it is difficult to offer an explanation. Whatever it was, your description suggests a much simpler physics shape mesh would have been sufficient. It is almost always necessary to provide a specially designed physics mesh to optimise the physics weight. It all depends what you need the physics for. If you are going to analyze, it's best to use non-overlapping boxes. Note that you don't need holes for the windows, which reduces those walls from four boxes to one each. In this case, maybe the same for the doors too? The solidify madifier does essentially exactly what you describe as the alternative (duplicate, displace, flip, bridge edges), except that it's a bit more intelligent with corners, and the edge bridging is optional. Anyway, it does (usually) double the vertices and may more than double the triangles. So a doubling of the download weight, which is roughly proportional to the amount of geometry, is to be expected if the whole thing is solidified (you can solidify just selected parts by using the solidify operator.) Pics to follow if Aquila doesn't make some first!

"Is it possible to have one analyzed cube-based upload for the smaller parts and a non-analyzed planes upload for the big parts linked into one object in SL" Possible only if you upload them separately and link them inworld. The "Analyze" applies to the whole of an upload, whether it's one mesh or many (which end up as a linkset). So you can't mix them in one upload.

Hehe.:matte-motes-sour: Yes, of course. Shows how silly I can be. I guess I never tried to use anyone else's textures since I was a newbie and made myself a jacket from the carpet in the wellcome area. That must be in the library, I suppose.

Right click the floor and choose Edit; Check the "Select Face" button near the top of the edit dialog; Click the Texture tab; Click the small texture preview box - the texture chooser will appear - on it there is a small eye dropper - Click that; Then click on the face that has the texture you want. This will copy the texture onto the floor. If you can't see the floor and the face with the wanted texture at the same time, then first transfer the texture to a newly rezzed cube as above, then move the cube and transfer the texture from it to the floor.