Drongle McMahon

Hopefully to make it as clear as possible, here is what Chosen is suggesting (I think). First, the meash on the left with the two materials; then the UV map*. Now the textures. This can be either all five together, as shown here, or five separate textures 1/5 the size. If you use the one texture, it's more to upload for each new viewer, but it will give very fast changes. You change the textures of each material(=SL face) independently by using 5 horizontal repeats and setting the correct horizontal offset (or whatever for the appropriate layout). If the texture is to be changed rarely, use five separate textures and change by changing the texture. One or two of the small textures will have to be loaded by new viewers. *Note that UV maps and textures are completely separate things. The UV map is part of the mesh data. The texture is not, even though you can upload it with the mesh if you like. In SL, you can only have one UV map. It is just a list of the positions of each triangle's vertices in the 2D texture space. It is independent of the assignment of materials (face textures in SL) to those triangles. The UV map display, with or without a texture, is just a convenient way of showing and editing it.

"clearly not a backface culling issue" Not so clear to me. Here is a picture of a cylinder with a patch of inverted normals without (left) and with (right) backface culling. Naturally, when you can't see the triangles, it looks as if they are missing.

To see the mesh in Blender with one-sided faces, as it will appear inworld, check "Backface Culling" in the "Display" section of the Properties panel on the right of the 3D view.

Yes. It looks like more than 8 materials. The uploader just removes all triangles with the 9th and higher materials. That's why parts of the model are missing. What is there looks alright to me.

Try this. It's just a cube. <?xml version="1.0" encoding="utf-8"?><COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1"> <asset> <unit name="meter" meter="1"/> <up_axis>Z_UP</up_axis> </asset> <library_images/> <library_geometries> <geometry id="C" name="Cube"> <mesh> <source id="Cp"> <float_array id="Cpa" count="24">-1 -1 -1 -1 1 -1 1 1 -1 1 -1 -1 -1 -1 1 -1 1 1 1 1 1 1 -1 1</float_array> <technique_common> <accessor source="#Cpa" count="8" stride="3"> <param name="X" type="float"/> <param name="Y" type="float"/> <param name="Z" type="float"/> </accessor> </technique_common> </source> <source id="Cn"> <float_array id="Cna" count="18">-1 0 0 0 1 0 1 0 0 0 -1 0 0 0 -1 0 0 1</float_array> <technique_common> <accessor source="#Cna" count="6" stride="3"> <param name="X" type="float"/> <param name="Y" type="float"/> <param name="Z" type="float"/> </accessor> </technique_common> </source> <source id="Cm"> <float_array id="Cma" count="48">1 0 0 0 0 1 1 1 0 1 1 1 1 0 0 0 1 1 0 1 0 0 1 0 0 0 1 0 1 1 0 1 0 0 0 1 1 1 1 0 1 0 1 1 0 1 0 0</float_array> <technique_common> <accessor source="#Cma" count="24" stride="2"> <param name="S" type="float"/> <param name="T" type="float"/> </accessor> </technique_common> </source> <vertices id="Cv"> <input semantic="POSITION" source="#Cp"/> </vertices> <polylist count="6"> <input semantic="VERTEX" source="#Cv" offset="0"/> <input semantic="NORMAL" source="#Cn" offset="1"/> <input semantic="TEXCOORD" source="#Cm" offset="2" set="0"/> <vcount>4 4 4 4 4 4 </vcount> <p>1 0 0 0 0 1 4 0 2 5 0 3 5 1 4 6 1 5 2 1 6 1 1 7 6 2 8 7 2 9 3 2 10 2 2 11 0 3 12 3 3 13 7 3 14 4 3 15 0 4 16 1 4 17 2 4 18 3 4 19 7 5 20 6 5 21 5 5 22 4 5 23</p> </polylist> </mesh> <extra><technique profile="MAYA"><double_sided>1</double_sided></technique></extra> </geometry> </library_geometries> <library_controllers/> <library_visual_scenes> <visual_scene id="Scene" name="Scene"> <node id="Cube" name="Cube" type="NODE"> <matrix sid="transform">1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1</matrix> <instance_geometry url="#C"/> </node> </visual_scene> </library_visual_scenes> <scene> <instance_visual_scene url="#Scene"/> </scene></COLLADA>

Yes. Something has gone wrong. To be honest, I'm not sure these files work with the current viewers. They were made a very long time ago before the beta became open. They were also not well optimised for the current LI calculation system. I did make some updated versions of mine, but I don't think they got as far as being placed there.

I have experienced crashes at that point (as soon as opening the file) when I used a collada file with a mistake in it - when the number of triangles in theb triangle list doesn't match the number in the <polylist> tah. I made a jira saying it should be detected with an error message, not a crash. However, I don't think this should ever happen unless you are manually editing the collada, as I was. It may be the crash is an error in the collada dom library that is not caught by the LL code. In that case, a similar effect could happen with other collada errors.

It was definately something else then :matte-motes-smile:

Assuming that's mostly quads, yes, well below the limit. But I thought you only got the problem when the pillows were there? Were the pillows separate objects, and if not, what were their counts? Not that it matters, but it would be interesting to know.

"pillows with (tho not part of) the main mesh" If you mean that they were separate objects (<geometry>s in collada), then that would be strange, and not really consistent with this explanation. Each object is uploaded independently, as if they were uploaded separately, except for adding the relative scale/rotation/location transformations to be applied on rezzing as a linkset. So the counters should all be reset for each, just as if they were separately uploaded. On the other hand, if you mean just not connected, then omitting the pillows could avoid the holes, because the counters are not restarted. Then they are rezzed as one prim, not a linkset. So it's good you solved it one way or another, but it's still worth keeping the 21844 limit in mind. I would have expected that would be enough for the whole thing with a couch like this, with appropriate use of smooth shading. You need to be kind to the residents' gpus. Certainly, anything that exceeds the 174752 triangles, where holes start to appear, is too high poly for efficient display. Of course, that's only about 85 sculpties, as far as the gpu is concerned, and lots of people think nothing of using such numbers!

Since you have holes, and you mention texture issues on the pillows when they are included, it does sound like the effects of much too high poly count, although it's not clear from the picture. You can see by looking at the triangle counts reported in the uploader. If that is below 21844 (as it should be), then the following is irrelevant. This is a bug that has been reported in a jira (BUG-1001, for those that have unrestricted access). When the triangle count for a material passes 21844, the uploader secretly starts a new material, complete with a new triangle list. It goes on doing this beyond the 8 material limit (more than 174752 total triangles if it's all one material in the collada file), but the extra materials are culled before the upload, leaving holes. Where there are edges between different materials, the vertices along them have to be duplicated in each of the triangle lists. The secret materials cause many such edges. So they cause a rapid increase in vertex count, which increases the download weight. The extent of the download weight increase depends on how the triangles are distributed between the materials, which depends on the order that they appear in the collada file. That depends on the 3D software and the collada exporter. So does the distribution of the holes that appear when the secret material count exceeds 8. The effect of the extra materials on texturing is strange. It's not the same as having explicitly different materials, perhaps because the secret materials all have the same material name. At first, you can set different textures or colours on each, by dropping or using "Select Face", but then it starts behaving as if they were all one material. Perhaps this effect could describe the texture issues you mentioned? There is a picture of these effects in this thread. You should be able to tell whether you have run into this issue if you look at the triangle counts of the meshes involved, as reported in the uploader. If the holes are caused this way, there will be less triangles than you expect from the poly count (x2 fo quads) in the authoring software, becaus the dropped triangles do not get included in the uploader count. If your triangle count is below 21844, then it is nothing to do with this bug.

Were the changes in LI due to download weight or to physics weight? (More Info link from edit dialog).

Ha! I never even noticed the bevel modifier. :matte-motes-frown: They don't leave us any fun! It's not so versatile in 2.65 though...no segment count. But the Edge->Bevel operator does have segment count. So you can make all these nice toplogies without reapplying it as I did. However, it leaves gaps between the sides in the UV map. So the subsurf modifier wins there.

Even better - same nice topology anf faster. Also, if you UV map the cube, the map will survive through all this... 1. Apply subsurf modifier, Catmull-Clark, 2 levels, to cube. 2. Loop cut and slide, scroll to four cuts... 3. ...and cut. 4. Same in other dimensions. 5. Select unwanted edges... 6. ...and Dissolve them (with dissolve vertices). 7. Delete top vertices. 8. Apply modifier (obj mode). 9. Select unwanted edges... 10. ...and Dissolve. 11. Solidify and add edge split modifier, as before. 12. Corner detail.

"I can't see a way to delete them in the same single step as deleting the top faces." Strange. It works for me; delete key->Faces, whether it's in face, edge or vertex select mode, removes the selected faces and any edges between them, but not edges shared with unselected faces. To delete the faces without deleting the edges, I have to do delete->Only faces. Delete->Faces & edges destroys the sides as well. This is in 2.65. I'm not terribly confident about the new delete modes though.

Here's another one. Gives better topology at corners. 1. Add cube; subdivde twice. 2. Transform-to-sphere. 3. Add 2x array modifiers in X and Y. 4. Apply in object mode and back to edit mode. 5. Select inner vertices from top... 6. ...and upper vertices from side. 7. Delete them. 8. From top, select facing edgeloops and bridge them. 9. Same at the bottom. 10. Then same again in other direction. 11. Select top edge loop. 12. Extrude it. 13. Select all and solidify faces. 14. Shade all faces smooth; add edge split modifier. 15. Rendered 16. Detail of corner topology.

There must be dozens of ways of rounding corners. Here are a couple... A. Rounding after making box. 1. Select top of floor. 2. Inset face to wall thickness. {mesh->faces->inset} 3. Extrude walls. {E' rtn; pull up} 4. Delete top faces; select loop {Alt+click} 5. Dissolve (including verts) {mesh->dissolve}; select edges. 6. Bevel edges. {mesh->egdes->bevel} 7. Deselct top edges. 8. Deselect bottom edges. 9. Bevel again. 10. Select top edges. 11. Bridge edge loops. {mesh->edges->bridge} 12. Select all except top faces and smooth shade faces. {mesh->faces->shade smooth} 13. Select tiny triangle. 14. Merge at center {Alt+M; center}; repeat for each corner. 15. Object mode view. 16. Rendered view. B. Start with rounding. 1. Sphere, 12 segments, 6 rings. 2. Delete vertices in top half. 3. Extrude. {E; rtn; pull up} 4. Select edges and edge split to get quadrants. {mesh->edges->split} 5. Select two quadrants {select verts and ctrl+L}. 6. Move. 7. Repeat at right angles. 8. Select edge loops. 9. Bridge edge loops. {mesh->edges->bridge} 10. Repeat for other sides, then fill the base rectangle. {F} 11. Select all and solidify faces. {mesh->faces->solidify} 12. Smooth faces and apply edge split modifier with 45 degree angle; render.

What I mean is that perfect boxes/spheres/cylinders weigh only 0.1 when they are used by linking in undistorted traditional prims (and setting the mesh to "None"). It doesn't matter whether their shape type is Prim or Convex Hull. If you provide an identical shape as a physics mesh, as part of the upload, it is not recognised as such and so you don't get the 0.1 weight, whichever shape type you use, and whether it is "Analyzed" or not. If it's a cylinder or sphere, the weight will be higher whether it's shape type is Prim or Convex hull.

Perhaps also - what are the vertex and triangle counts shown in the uploader?

"Apparently Havok loves cubes" Yes, but the problem is that it only recognizes them when you link them as prims to make the physics shape. If you make a physics mesh that is a perfect cube (or cylinder or sphere), whether analyzed or not, it doesn't recognize it and doesn't make the saving engine resource and physics weight that it could. So only the linked prim method can get you those efficiencies.

Yes. Aditi isn't allowing upload: error messgae is "Error while requesting upload permissions".

"First thing this suggests is that it's probably better to use inworld prims for simple shapes" There are a restricted set of "simple" shapes that correspond to the primitives in the physics engine. They are (1) any box that has no distortions other than stretching along the three axes, (2) a perfect sphere, with exactly the same stretch on all three axes, (3) a cylinder with a perfectly circular cross section and no distortions. These are recognised by the system and scored as 0.1 physics weight. Make the slightes distortion, and their weights will jump (if connected to mesh). So as long as you stick to these restrictions, you can make very cheap physics shapes this way. This is specially good for spheres and cylinders which are otherwise quite expensive, even as convex hulls, because of their curved convex surfaces. However, there are two risks. First, they can get unlinked. Second, they can get stretched (with edit-linked) so that they don;t satisfy the rules any more and the weight jumps. So for items with mod permissions, they are not very safe. "I really want to use mesh, is the server cost or the physics cost the better one to optimise?" It sounds silly, but whichever is the higher. Otherwise your optimisation has no effect on LI. However, server weight is only an issue for the very simplest shapes. Physics weights are more often higher than download weight, and therefore the cause of high LI, than people realise. This is especially the case with small curved objects.

Also, test the changes on a copy. If the physics weight goes too high, it can cause the object to be returned. It's even possible to get a physics weight greater than 15,000, so that it can never be rezzed again, even in an empty region-sized sandbox. Hopefully, that would be rare.

If you mean Simple deform->Bend, then yes. I never used it, but if you look at the bounding box while tweaking its parameters, you can see that it has all sorts of effects that could have the same sort of results. When I tried, after applying the modifier, apply rotation and scale did make the bounding box normal, but I have no idea whether that will always work. I guess there may be similar problems with many modifiers. So looking at the bounding box is always a good idea.

The physics mesh, like the lower LOD meshes, gets stretched or squashed to fit the bounding box of your high LOD mesh. So you have got a bigger bounding box than you think. HGere is how that can happen. A is the original cylinder, and is its bounding box (switch 3D display mode in Blender). Now I go back to normal vew, into edit mode, and rotate the cylinder, as in C. Now the boundin box is bigger (D). The physics mesh will stretch to fit it, If I rotate the cylinder back in object mode, the large bounding box doesn't shrink, it just rotates (E). So even though the cylinder looks straight (F), it still has the larger rotated bounding box. When it's uploaded, it does exactly what you describe with the physics mesh (G). Look at the bounding box in Blender. If this is what happened, then you need to apply rotation and scale, not to the physics mesh, but to the high LOD mesh. That will shring the bounding box back to where it started.