Drongle McMahon

"How come, when Prim physics is enabled, the LI is reasonable when scaled to maximum size, but gets ridiculous when shrunk?" This is expected behaviour for mesh with triangle-based physics where the LI is the physics weight (i.e. when that is higher than the download weight). The physics engine has to do much more work if it has to consider collisions with many small triangles within the collision range of the potentially colliding object, than it does with a few large triangles in the case of the unshrunken mesh. So the physics weight calculation takes account of the size of triangles accordingly.

Here are some ways of getting the edge highlights.  On the left is a picture from Blender. At the top is the headboard with the edge split modifier. Next is the same model set to smooth shading, but with Auto Smooth switched on and its angle set to 87 degrees (Little triangle next to spanner = Object Data; Normal section at the top). This achieves the same effect as the edge split, but beware, the altered normals produced by Auto Smooth are NOT exported (yet). So in SL, this will look just like the wholly smooth shaded mesh. In the third model, the edges where we need highlights have been smoothed by adding a very narrow two-segment bevel, with the Profile set at 1.00 to keep the adjoining faces completely flat (Bevel parameters Amount=0.015, Segments=2, Profile=1.00). You can see the highlights along the smoothed edges (thanks to Matcap). However, there is an unwanted darkening along the bottom and back edges. This is where the shading conflicts with the sharp edges left by the 1.00 profile. The darkening can be reduced by using a real bevel with just one segment, but to keep the adjoining faces flat, we now have to use edited vertex normals along the bevelled edges. This is done by using the Data Transfer modifier to transfer the normals from the auto-smoothed model (details below). Now we still have the desirable edge highlights, but little or no darkening artefact is visible along the bottom edges. On the right are the models inworld. The auto-smoothed one is not there because the altered normals are not exported. However, you can see that the normals transferred by the data transfer modifiers are exported. So all the effects on the shading of the edges of these three models do appear inworld too. At the bottom is another way of obtaining the edge highlights. This is the edgesplit model, but with a normal map baked from the bevels2p1 model. Note that these have blank texture. The shading and highlights are solely from the inworld lighting, here with default 3pm daylight only, no local lights. Both the bevel methods add a lot of geometry, and this does increase the download weight. For this simple model, using the edgesplit model for medium and low LODs, and a simple model for lowest LOD and physics, the download weights are 0.1 for the edgesplit model and 0.4 for either bevelled model. All those end up with LI=1, but with more complex models, you can expect to pay for the improved highlighting with an LI penalty. In contrast, the normal map approach doesn't cost any LI, but does require an extra texture, unless you are already using a normal map, in which case it's free. The single bevel with edited normals does have one more advantage over either the double bevel or the normal map models. Because it does have a real bevel in the geometry, in close up views of the silhouette there is less obvious conflict between shading and outline. Here are some details of the vertex normals. The two at the right are the single-segment bevel model before and after adding the data transfer modifier.  And here is the data transfer modifier. The parameters changed from default are shown by the yellow rectangles. Note the it is essential that the origins of the source and destination meshes must be in exactly the same place for this to work. In his case, that is easily satisfied because they are duplicates of the same original mesh.  ETA:Two important things I forgot to mention! Note 1) With the two bevelled models, it is essential that you do upload with the edgesplit model for the lower LODs. If you rely on the auto-generated LODs, loss of the geometry and/or edited normals will cause the smooth shading to flow into the flat faces, causing an abrupt and unpleasant change in shading when the LOD switches. Note 2) When you export a model with transferred normals, you need to uncheck the Triangulate option in the collad export options panel. This is because any change in geometry, including triangulation, disrupts the custom normals, For the same reason, you must only add the data transfer modifier after you have completed all changes to the geometry.

I can't remember where the Round Cube came from. Maybe you can activate it in User Preferences/Addons? It's nice. There are some structures for which the sphere with cube-based mesh is much better than a UV sphere or ico sphere. Other variations, capsule etc, are also very useful.

The physics weight shown by the uploader is only for the default convex hull, which is used when the physics shape type is Convex Hull. It is indeed most frustrating that the Prim physics weight can only be obtained after uploading the mesh. There doesn't seem to be any good reason, as the weights are (now) all calculated by the server anyway. So the mesh has to be sent for that anyway. There has been at least one jira sking for inclusion of the Prim physics weight, that has been ignored for years. I am afraid there is no way round this. It is especially frustrating because of the idiosyncracies of the physics weight calculations, which do not operate in the manner described in the wiki, and which, in the case of triangle-based (not analyzed) shapes, are bizzare and unpredicatble. The only way to test Prim physics weights without paying the upload fee is to upload on the beta test grid, Aditi.

"I couldn't find anywhere to type in the object's dimension in Edit Mode" I don't think there is anywhere. You can select a face parallel to an axis and move it by typing in the sppropriate. Transform Location coordinate. I did the scaling in edit mode in the knowledge that the default cube is 2 x 2 x 2. So I just selected all and then typed 'SX1.5', 'SY0.05', 'SZ0.3'. It's a pity there isn't an Add->Cuboid, with a toolbox allowing you to type all three dimensions independently. Ah! There is, although it isn't called cuboid. Just do Add->Round Cube->Custom; leave Arc at 1 and type in dimensions. Experiment is the key to Blender knowledge.

To add Edge Split modifier (and others) ... Select object (either Object or Edit mode). The Object Properties panel is usually on the right. If it's not there, (make a window for it and) set the window type to Properties by choosing the icon shown at (1). Now click the spanner/wrench icon (2). This reveals the Add Modifier button (3), which will yield the list of available modifiers, wherein you can click the Edge Split item (4). The newly added modifier will appear in the modifier stack, with widgets to set its parameters (5). 

I think you must have scaled the cube in Object mode. If you do that, you need to do Object->Apply->Rotation & Scale before you edit in Edit mode. This is because the bevel is applied to the object before the Object-mode scaling. So the bevel gets scaled too. Lots of tools work that way. So it's (nearly) always best either to avoid scaling and rotation in Object mode, or to remember to Apply them. If you do the scaling in Edit mode after selecting everything, you will avoid this, and many similar problems.

Just to illustrate your point, here is another way of making it, and something about getting the shading right. 1. Scale your cube to 3.0 x 0.1 x 0.6. 2. Select the short upper corner edges. 3. Do Mesh-Edges->Bevel; setting amount to 0.3 and segments to 6, in the toolbox. 4. (Matcap shading to see effects). Now we have faceted edges from flat shading. 5. Set whole object (Object more) to Smooth shading -> unwanted smnooth shading of front. 6. Add the modifier "Edge Split", with default settings -. Now the rounded edge is smooth, but the rest are sharp. 7. Looking at the result in object mode, but perfectly sharp edges are not ver realistic. 8. Next lesson will be ways to make smooth edges that give proper edge highlights (two ways).  Note "8" is the step that is often left out. It's one reason why people think advanced lighting and materials don't work, because they don't see expected highlights. Slightly smoothed edges are essential for realistic edge highlights with advanced lighting and material.

'annoying habit of suffixing the mesh name with "_0"' There is a jira, which includes something resembling "explanation".

Sorting of materials by name is mentioned in this kb article. It also mentions ImporterLegacyMatching. While I guess it is ambiguous as written, I think that applies only to the object names (which are now also used to sort the object list) matching, not the material names. There is no common code involved in getting the names of objects and materials. By the way, see my comment there - the new naming scheme applies to object names, not file names.

Assuming HD is the high detail visible mesh, and lod are the lower detail meshes, they have to be in different files. So they can't be in one mesh. They are never rendered at the same time. They are alternatives. Which is rendered depends on how far away the object is from the camera, its size, and the setting of the RenderVolumeLODFactor setting (eg via Object Detail ... or via graphics quality). If this is a new project, you probably need to read this KB article so that you can use the new naming convention for objects in LOD files*, especially if you have multiple mesh objects. Multiple objects become a linkset inworld, which can be unlinked just like linksets made there. The naming convention is to ensure that each high-detail object gets associated with the correct object in the lower LODs. Note also that you need one object in the lower LOD file for each in the high LOD file, and that the lower LOD objects will be squashed or stretched to fit the bounding box of the corresponding high detail object. Both of those apply to the physics model objects too, in the physics file. *See my comment there - Although the main text suggest it, it is not the filenames that have to use the convention, it's the names of the objects inside them.

"Drongle made an analysis on this a few years back." A more complete analysis followed in this thread. Still very technical. As far as I know, nothing has changed.

You might also need to know the way the uploader associates each object from the physics file with each object from the visible mesh file. The preferred method now is to use a strict object naming convention, as described in the knowledge base.So if an object is called "myobject1" in the visual model, then its physics object has to be called "mymodel1_PHYS", and so on. However, if you don't get that right, it is supposed to fall back to the old system whereby objects are associated according to the alphabetical order of their names. (That superceded the even earlier scheme where they were associated by their order in the dae file, because the meshes are now sorted alphabetically instead).

Complete guess here, but I suspect your model may consist of several separate mesh objects. In that case, in the physics mesh file you need a separate mesh object for the physics shape for each of the visible objects. When the uploader thinks it has the physics mesh for a visible mesh object, it proceeds to squash it or stretch it to fit the bounding box of the visible mesh. So if your first visible object is the back wall, and you have one physics mesh for the whole thing, then that will get squashed into the bounding box of the back wall, while the remaining visible objects will get nothing.

Also, just in case, have you set the physics shape type to "Prim" inworld, which is necessary to get the specified physics shape.

Are you sure they aren't overlapping? The only way I can reproduce this effect is with two blocks just overlapping (because one is tilted.) Then the edges where they overlap look jaggy. In fact, looking at 4x in Gimp, the jaggies are only one pixel wide. The reason the appear there and not elsewhere is that the overlapped part pf the image is totally black, with no anti-aliasing. Other edges have the random noise from the sampling used for the AO, and that has a smoothing effect that makes them look anti-aliased. In that case, since the black part is not going to be visible, you can soften the edge using the smudge tool, inwards into the black. That might hide the effect if it shows on the final object. Here's the example, at 4x. You can see the jags are one pixel wide.  Here's the point where the overlap ends, and the jaggy edge turns into pseudo-antialiased edge.  (Done with Blender Render ao bake - don't know if the same happens with Cycles).

I still don't know how you have put the texture onto the mesh in Blender. If you haven't, then that is your answer. Blender doesn't automatically know that you made a texture in photoshop(or whatever). You have to tell it to use the texture. The easiest way is: Choose "Blender Render" rendering engine in the dropdown in the middle of the top toolbar. select the whole mesh in edit mode - you will see the UV map in the UV editor panel. Select all in the UV editor too. Now use the menu there to open the texture image file. It should appear under the UV map. Finally, make sure you have the "solid" display method selected and check the "Textured solid" option in the "Shading" section of the Properties sidebar of the 3D viewport (displayed from view menu, or by typing "N"). You should then see the texture on the mesh in the 2D view. Now export the mesh, using the "SL and Opensin static" option under the Operator presets - you need the "Include UV Textures" checked, which it should be with this preset*. Now you should see the textures in the uploader preview when you check "Inclde textures" on the "Upload Options" tab, and on the uploaded mesh when you rez it. You can also apply texture using materials instead of the UV editor, so that they appear in rendered views. I that case you need to check the alternate "Include material textures" instead of the UV texture option. I should add that I never upload textures with the mesh. I always upload them separately and appply them inworld, which is easier than uploading them with the mesh. There are other good reasons for this, including having to pay the upload fee for the texture every time you upload an altered mesh, and the mesh fee every time you upload it with an altered texture. More importantly, the same texture will be given a new UUID every time it's uploaded. Not only does that waste asset server space, but it means everyone looking at your stuff has to download the same texture again for each object you upload it with. Re-use of textures is a very effective way of minimising lad, but it doesn't work if you upload them with the meshes you use them on. Finally, you will end up with a proliferation of (possibly identical) texture files hidden in non-obvious places in your inventory. * It will also check the "Copy" option, which ma,es a copy of your texture file in the same directory as the exported dae file - the uploader needs it there to find the file. If it's alreadsy there, then it's not necessary to copy it.

Yes. Tried a few versions of these. Looking at the one that splits into 4, what happens is that the bottom quad of the small box facing the larger box gets split into a separate hull. No idea why that happens. It only happens if you leave the default "Surface" setting for "Method". If you set this to "Solid", then you get the expected three hulls. I generally use "Solid", although this sometimes works the other way round. You can also get three hulls if you use "Simplify" with "Method" as "Retain%" and "Reatain" set to 87% (and lower), while leaving "Surface". I think using "Solid" is the best advice, and then using "Retain%" if you still have problems. These willonly work reliably, though, if you do have non-overlapping convex hulls in you physics mesh. Otherwise, you can get all sorts of horrible effects. I guess that's where the advice is most important, more than for the default case, but for the desired result if you use a bit of "Simplify". The internal code for the decomposition into hulls is not accessible, as it's part of the Havok engine, not open source. It certainly has some strange behaviours, and it can change with new versions of the Havok library get used. So it's quite possible that there have been changes, and that it may change again.

You are quite right in saying that the "Analyze" doesn't work optimally for a lot of meshes. Most often, supplying a set of non-overlapping hulls avoids problems, but I don't suppose it isinfallible. On the other hand concave meshes and overlapping hulls very often lead to very poor shapes. It's also often worth experimenting with the differences between "surface" and "solid" decomposition. I thought of another couple of reasons I may have advised against un-analyzed (triangle-based) physics shapes, even for walls. First, with double-skinned walls, it is possible to penetrate one of the skins and then you get stuck beteween them, trapped in the wall, which is not very nice. This can't happen with convex hull-based (analyzed) wall, because the physics engine always knows whether you are inside or outside. If you do get inside, it will nudge you out again. So you can't get stuck. Secondly, there are some strange collision effects that can happen with triangle-based shapes. For one thing, they are easier to penetrate (or fall through if it's a floor), especially when moving fast, and usually easier fro one side than from the other (I have never understood that). In certain circumstances, it's possible for that asymmetry to be extreme, so that you can make one-way doors, or even an invisible one-way cube that you can walk into easily but never walk out of. So generally, Analyzed walls may be a bit safer, although they are more expensive in physics weight for large walls. Then of course, there's the bugs with triangle-based physics weights, as mentioned above.

"my simple arched wall was 8000 LI" If you take a mesh and roll it about on a flat table at every possible angle, some of its vertices can never touch the table because they are in depressions in the surface. If you eliminate all such vertices, so that every remaining vertex can touch the table at some angle, the remaining vertices constitute the convex hull of the mesh. In SL, the hull is represented as simply that, a list of vertices, although it is more commonly represented elsewhere as a surface containing those vertices. It is much easier for a physics engine to work out collisions with a convex hull than with a general mesh that can have concavities. The convex hull is often described as the shape of a shrink wrapping of the mesh, but that is not quite accurate, because shrink wrapping of 3D objects can have saddle points (opposite curves along perpendicular tangents), while convex hulls cannot. A convex hull is not always much simpler than the mesh it is generated from. For example, the convex hull of a sphere is the whole sphere, because it already has no concavities. So using "Analyze" does not necessarily give you low physics weights. You still need to use a simplified mesh to obtain a lower physics weight. You can now experiment with convex hulls in Blender (7.6b) - in edit mode, press space bar, then type convex hull and click the button that appears. That may be the best way to become familiar with them. Indeed, you can use this operation on selected subsets of vertices to make a set of convex hulls that could be the starting point for your physics mesh suitable for "Analyze". To return to the main subject - there are some bugs in the physics weight calculation for triangle-based shapes that can occasionally lead to very high (thousands) physics weights even when there are no small triangles. There was a series of threads where this was discussed a long time ago ( search for "physics weight episode").

"because Drongle TOLD me too long ago" I have to guess this was for small objects*, for which that is the method giving lower physics weights. As Aquila pointed out, This is not the case for object consisting only of large triangles, of which the most common are buildings and walkable landscapes. For those, it is much better to use triangle-based shapes - that is to say, avoiding analyze. Note: Aquila's statement that the physics weight is 0.36 per box is true for simple boxes with six quadrangular faces. It comes from the fromula 0.04 x (number of vertices + number of hulls), which is provided in the wiki documentation. The two numbers are shown in the uploader after you analyze. However, that formula is only accurate for certain shapes where there are exactly three faces meeting at each corner, such as simple boxes and cylinders. In other cases, the physics weight is different from the value obtained by applying that formula. * do you remember where I told you?

"I guess he will know what determines the root." Alas, no, I don't. I thought I did, but I just tested about a dozen uploads of the same file containing just three cubes (auto-LOD and default physics, no UV maps). It appeared random. Any of the three of the cubes appeared as the root in one or more of the uploads! The name of the linkset was always the first in alphabetical order (comparing different files with edited object names). When the linkset was unlinked, the cube that had been the root retained the name of the linkset, while the others were all called "Object". Since the choice of root was random, this means that the root cube received the name of a different cube in the source file, unless it happened to be first in alphabetical order. If you then relink to get the root you wanted, the whole thing is now called "Object". I think this behaviour could appropriately be described as chaos. The root appears to be unpredictable. I think this may be the result of recent changes that introduced the naming scheme. As far as I recall, the root used to be the first <polylist> in the file. Now that the objects are sorted into alphabetical order by the uploader, I expected it to be either the first in the file or the first alphabetically. Neither seems to be the case, at least with these test files. More source code reading may be indicated, but it will have to wait until I have finished moving house. Note that the loss of names of the non-root objects, which always happened, can be a disadvantage of uploading objects together, and that can be another reason for uploading separately and linking inworld.

You don't need an add-on (thanks to Gaia). Here is the simplest process: Select only your object; File->Export->Collada; After selecting folder and typing filename, Click the "Operator Presets" button half way down on the left side and choose "Sl + OpenSim static" - these options will work foe most unrigged objects; Then click the "Export Collada" button at the top right. If you have done all that and still have problems, then we probably need more information to identify the cause(s). At least we need to know exactly t what point your upload fails, what are the symptoms and any error messages? Do you have the same problem if you try to upload the default Blender cube?

"This bug is being fixed in the next MAINT viewer update." If this is the claimed fix for MAINT-5678 (aka BUG-10434), mentioned as fixed in release notes, then it isn't fixed (see WF comment). The supposed fix linked there only affects the function getElementLabel, which is not used to get material names. Material names are retrieved directly from the "material" attribute of the <polylist> (etc) by a call to the collada dom library. Maybe there's another fix?

Note that recently LindenLab has improved hacked their SL Importer to pretend it will "support more than 8 texture faces per object" FIFY :matte-motes-evil-invert: