Drongle McMahon

Yes. I have seen that anomaly of the physics shape view showing the wrong shape a few times recently. I think it may be something new. Probably should be reported as a bug. The sort of unexpected differences you saw with the added triangles at the ends may well be the triangle/vertex ordering effect I mentioned. If it's important enough, you could try editing the collada file to try to get a lower weight. Maybe you already saw them, but in case you didn't, you can find my reports of these effects by searching th mesh forum for "physics episode". The data there show how large the effects can be. I wish I could give some rules for getting the right order, but I never found any. PS. Yes, apologies. I should have known you wouldn't use generated physics meshes. I think I was deceived by the use of the unpaired triangles in the kerbs, which is not a technique I have seen before.

Assuming you do need triangle-based shapes, here are some ideas that might help. I hope you can see the meshes clearly enough in the picture. As triangle-based shapes are size-dependent, I had to guess the size. These are all 8x8m. The thin ones are 0.5m thick (to avoid the secret conversion to convex hull shape type). The thick ones are 2.5m deep. I left them with three segments in the turn, although the phsyics would certainly be better with more. The idea is always to minimise triangle count, and especially to avoid narrow small/triangles where possible. At the top left is the simplest shape with no kerbs. It's physics weight is 1.1. That's mostly the narrow edge triangles. So the one below has the narrow edges extended to make bigger triangles, assuming these can be buried in the ground. It has physics weight 0.5. Of course the physics shape mesh is squeezed into the bounding box of the high LOD mesh. So with this trick, the visible high LOD mesh has to be extended too, with at least one triangle going the same distance undeground. Next are the versions with kerbs, but no top to the kerb. The one at the top adds more narrow triangles, and it's physics weight rises to 2.4, but the one extended underground is still 0.5. Then on the top right, we add the top of the kerb. That's more narrow triangles, and the weight goes up to 4.4. If we use the very narrow triangles on the inside of the kerb, instead of the thicker ones intersecting the road, shown at the bottom right, then the weight goes up to 9.0. Some of these weights could probably be reduced further by painstaking trial and error with different triangle and vertex orders, but I am too lazy to do that now.

"which will only contain cached mesh assets" Indeed. I suppose that would be because retrieval from the cache is as much dependent on the size of the data as is download, albeit on a different order of magnitude. So for many cases, the reading of the mesh data from disc will take more time than the prim's geometry calculation in the cpu. "well made mesh should be easier, not harder on the rendering engine than prims" I would suggest that if it isn't easier, then it isn't well made (for identical geometry, that is).

I don't think I understand why you can't use analysed physics or linked prim physics here. Do triangle-based physics shaped really work better for bumpiness and alignment? If you can explain some more details of the difficulties you see with these alternatives, it might be nore possible to suggest some ways around them. Linked invisble prim physics shapes can be very chea, but only if they are undistorted spheres, cylinders or boxes. As soon as you start adding things like hollow and pathcut, such as you might need here, then linking them to mesh makes their physics weight as bad as those of the equivalent mesh shapes. Do you really need the physics of the very slighly raised kerbs here? The high physics weight is most likely coming from the narrow triangles involved in these. It also looks, from the missing triangles, as if this is made from an auto-generated low-LOD mesh. If that is so, you can certainly do better with a purpose built physics mesh. I am pretty sure you don't need all those triangles, even if you do want the kerbs. It also has to be admitted that there are some wierd aspects of the triangle-based physics weight calculations that can make the result highly dependent on the order of triangles in the dae file, and even on the order of vertices within a triangle. I was never able to make a satisfactory alaysis of the relevant factors, and so was left with trial-and error, manually editing triangle orders, as the only means of circumventing those problems. ETA The high physics weights of narrow triangles is not really a bug. It is a deliberate feature of the calculations, because small/narrow triangles do apparently cause excessive loads on the physics engine collison detection system.

"But with no clear system the computer has to do a lot more work on each vertice to get it right." I don't think that's strictly true for really like-for-like replcements. For both prims and sculpties the computer has to generate all the vertex, normal and UV map data from parameters or sculpt map, producing the mesh data, before it can start rendering. For mesh, that data is already there in the downloaded data, so that the calculation step is eliminated. So, for the same vertices etc., mesh is less work for the cpu and the same work for the rendering engine. Given that mesh can generally specify the same shape with fewer vertices, well made mesh replacements should usually be less burdensome for the rendering engine. However, the simple prim parameters, and the small sculpt map, mean that the amount of data downloaded is generally much less than for prims and sculpties than the equivalent mesh (not always true for sculpties if they waste a lot of geometry to get sharp corners etc.). So it is the download system, connection and asset server loads, that suffers with mesh replacements. Of course, that is assuming everythng is identical in the final geometry. Unfortunately, it is very easy to succumb to the temptation for mesh to be over-detailed, poorly optimised and over-textured. Because of that, mesh replacements do very often end up putting more load on all systems, including the rendering engine, than the simpler assets they were supposed to replace. So your overall conclusion is, sadly, usually correct.

No doubt you can save a lot of LI. You will have to do more than just replacing boxes one-for-one though, even if you eliminate hidden faces, because each mesh will be at least 0.5LI because of "server weight". So you will need to do some joining of pieces together into single meshes. If you stick to walls, you will be ok with physics (doors apart), but with more complex shapes you will have to learn about physics shapes. The other essential will be some effort in UV mapping, to make the texturing simple and effective. Then there's LODs. I would say it depends on whether you like learning stuff. If so, you will get lots of enjoyment from progressively optimising your palace, even if the learning is a bit hard. PS - a cube is 108 triangles.

Ah. That's interesting. I'll have to think about why that is. Meanwhile, it's good to know a solution.

"Face" has different meanings in Blender and in SL. In SL, a face is the parts of an object surface that can be independently textured and colourd. In Blender, faces are the polygons that make up tsurface of the object. Many Blender faces can be part of each SL face, but each Blender face can only belong to one SL face. You tell SL which Blender facesbto assign to a particular SL face by assigning the same material to them, which is different from all the other materials. Each material defines the Blender faces that will be parts of the SL face corresponding to that material. Make multiple materials (max 8) and use the color control underneath the sphere to set each to be a different colour. For each material, select just those Blender faces you want to belong to one SL face, and then click the Assign button underneath the material sphere. Repeat for each material. If you are in Solid view mode, without Matcap, you should see the SL faces each in a different color (that's why you use different colors - it isn't a requirement of the system). Now when you upload and rez the object, the SL faces should still be colored withb the colors of your materials in Blender. You can use the "Select Faces" radiobutton to edit one SL face at a time, changing colours, and, if you have UV mapped them, applying textures. You can't select of edit individual Blender faces (except one that is ubiquely assigned to a material).

Drongle McMahon wrote: The hull used by the default convex hull of a box is smaller than the bonding box, by a constant proportion. So as the dimension increases, you sink further into the mesh, exactly as your pictures show. Hmmm, that means It's not safe to resize convex hull meshes made with analyzed physics. Yet another thing they completely forgot to tell us! Oh deare. I should be clearer ... by "default convex hull", I mean the one that gets used when you set the physics shape type to Convex Hull. That always gets made, whether you specify a physics shape or not, and whether you analyze it or not. If you don't specify one, it gets made from the convex hull of vthe low LOD mesh (which can often be inappropriate). If you do specify a mesh, a LOD mesh or one from a file, then it is the convex hull of that mesh, not broken up into components like the analyzed shape itself. So it's only when using the Convex Hull physics shape type that you need to worry about this. Analysed shapes set to physics shape type Prim should be ok, with constant offset.

Yes, thanks. I had fprgotten that one already! Could have saved myself some time!

"Contrary to Drongle's observations, increasing the z dimension of the mesh did not increase the gap..." Not contrary at all - you must have missed the minus sign in my equation (or did I miss it?*). Whoops. I put "+" where I meant to put "-". The hull used by the default convex hull of a box is smaller than the bonding box, by a constant proportion. So as the dimension increases, you sink further into the mesh, exactly as your pictures show. The gap gets smaller and then goes negative as you sink in. When physics shape type is Prim, whether the shape is analyzed or not, the gap should stay constant. I think the effect you see when you see with the un-alalyzed shape, where you are left standing as it it were not there, is something to do with the major difference between un-analyzed (triangle-based) and analyzed (hull-based). collision is detected anywhere inside a hull-based shape (including default convex hull). So if you find yourself inside or spanning such a shape, you will be gradually pushed out. Collisions don't seem to be detected if you span across a triangle based shape. I guess you are sort of colliding in both directions and that cancels out. So you are left standing there. If you find yourself inside a triangle-based box. you can't get out except by sitting on something outside, because you collide with the triangles from the inside just as you would from the outside. A similar hull-based box will push you out. There's another rather interesting property of triangle based shapes with certain contructions, that makes them easily penetrable from one side but not from the other. You can make one-way doors and other interesting objects using this principle. I don't recommend using it though, as it is surely a bug that might get fixed. ETA: *Yes I did - sorry!! Corrected now :smileyembarrassed: I did say "retracted though, which is correct. ETA: I reported the default hull contraction as a bug in the jira years ago, but nothing ever happened.

In case anyone is prepared to put up with the tapering/pinching effect, it is also possible to use the selected-to-active bake to transform the prebaked map. In this case, both meshes are identical except for their UV maps. Just duplicate the low poly from before and move one copy up a bit so you can select them in the right order ("from", "to"). Then edit the UV map of the "from" mesh so that it fits the parallel planks. There is one very important step. If you leave the meshes as they are, the remapping will produce nasty effects because of the unequal triangulation. To avoid that add three levels of subdivision modifier - simple, not Catmull-Clark, and don't apply it. BUT Don't apply the modifier on export - otherwise you will have huge LI. Either delete it before exporting the mesh or uncheck the Apply modifiers option of the exporter. Here are the pictures. I hope it's clear what they all are. Inworld at the bottom.

As I see it, there is a problem with all these solutions because they all cause the pinching together of the woodgrain as well as the tapering of the joining grooves. That affects both diffuse and normal. So I started with a plain woodgrain texture (home made) without grooves (actually, I took one with grooves and copy-pasted strips to cover the grooves), made a normal map from it in GIMP, and applied both diffuse and normal maps to a grooved high poly mesh UV mapped so that the grain was aligned properly. Then I baked texture, ao (normalized) and normal maps from that to a low poly mesh. Made a diffuse texture by multiplying the ao bake with the texture bake in GIMP. Inworld, applied the combined diffuse map, the baked normal map and the ao bake alone as specular map (to suppress reflections from grooves), to the low-poly mesh*. Here is the result, and just the normal map applied to a black prim cube. Here are the textures used (all reduced sizes). Top two are diffuse and normal maps applied to the high poly mesh. Below that, the results of baking selected (high-poly) to active (low poly) textures, normals and ao. Lastly, the combination of texture bake and ao (multiply). Next, some details of the meshes. Low poly orange, high poly black (they were joined just to make this picture, separate objects for baking). The edges of the high poly were extended to overlap the low poly to suppress some edge artefacts. Both were completely smooth shaded. Top of grooves were bevelled, and extra loops were put next to the bottom edge to keep the angled parts flat. Here are the UV maps, simple one for low poly on left. The high poly one shows only half of the segments. The other ones were similar but mirrored vertically. All that is to avoid any two planks getting identical textures. The important point here is the alignment of each plank to the wood grain, which requires them to be separate islands. So, at least something approaching what you need can be done in Blender, although these are not perfect. *Interestingly, I found horrible shading problems with the normal maps if this flat low poly mesh wasn't completely flat (SZ0). It looks like thin meshes don't work properly. There were also a few nasties in the grooves if you look too closely. I guess because adding the normals from the woodgrain to that of the groove surfaces sometimes produced some normals pointing into the low poly mesh, which is not allowed. Should probably omit the grain normal from the grooves.

If you upload a PERFECTLY flat plane with a hole in it, the uploader detects that the z dimension is zero and sets it to 1.0, to avoid a divide-by-zero error later on. In that case, when it is used as the triangle-based physics shape as well, it will not be affected by the "doorway" bug*, as that only happens if a dimension is less than 0.5m. The triangle based shape is in the plane at the centre of the z dimension. It does have some odd behaviour though. It seems to have no resistance if you walk into it horizontally although you can stand on it. You can close the hole in the physics by reducing the z dimension to <0.5m, when it becomes convex hull. When you do that, it doesn't move. There is another way of avoiding the hole-closing, by adding a perpendicular triangle (as large as practical, to minimise weight increse) that will be buried inside a wall or in the ground. That keeps the bounding box > 0.5m thick. *I'm not sure this behaviour should really be called a bug, as I believe it was put there deliberately to avoid the large loads on the physics engine from collision detection with the narrow triangles around the edges of thin walls etc.

I measured the gap between bottom of feet and visible surface to be 0.075 - 0.0275*d, where d is the thickness of the prim I am standing on, when it is set to Convex Hull. The 0.075 is the avatar hover height, The 0.0275*d is the distance the hull surface is retracted from the visible surface. ETA. If you use a cube mesh to make a physics shape that fits the bounding box, and Analyze it, it will make a "Prim" type shape with physics weight 0.36 which does not retract from the bounding box of the mesh. Whether that's useful depends on whether the floor is supposed to be there. ETA corrected "+"to "-"

If you did make this by joining objects, ChinRey is surely right. Blender now combines UV maps by name, ending up with a map for every unique name in the objects before they were joined, and SL only imports one map. If any joined object doesn't have a UV map with one of the names, then in that map of the joined object, that object's vertices are all mapped to 0,0, so that it is entirely textured with only one pixel. If that is the map that gets uploaded, and that pixel is black, the the whole face will be black. So what you have to do is make sure the UV maps you want to be used for each individual object are all given the same name before you join the objects. Then make sure the map with that name is selected, and check the "Only Active UV layer" option in the exporter (it should say "Selected" instead of "Active" - that will be corrected soon). There have been a couple of recent threads about this, either here or in the texture forum.

Yes. I remember that now. In fact having one vertex out of the plane by an amount much smaller than the smallest number that can ve represented in the 16-bit upload format could produce the ridiculous physics weight thing in some cases. That was beyond mmy understanding because the rounding to 16-bit values bshould have made them identical to the perfectly flat case, in the uploaded data. Perfect flattening is certainly a better solution if it works, because it doesn't add triangles. Did you try changing the wall thickness? That had a big effect on my high weights too. I'm afraid I just decided triangle physcics weights were irredemably mind-boggling. Playing with this arch, I also noticed the physics shape display showing CH instead of triangle-based shapes, although I could still walk throght the arch - so it's the display and not the physics that's wrong for some reason. I think this is new, as I never noticed it before.

Thanks for those examples. Now I can see this effect very strongly in certain conditions: Set the time to 3pm. Put a normal map on a cube and give it a darkish colour with a blank diffuse map and a blank white specular map. Now set "Environment" to zero (the phenomenon doesn't affect env reflection), and Glossiness to a low setting, say 10. With shadow off, look at the cube from the shaded side. You can see strong highlights. Turn shadows on, and those highlights disappear. The cube face is left dark and flat, as in ChinRey's pictures. What's going on? I think the effect with shadows on is correct. When the face is in shadow there should not be any specular highlights. If you look at the well-lit front face, there is little or no difference with shadows on or off, and the other faces are intermediate. So I think the apparent collapse of the normal map in shadow is because without shadows it has highlights that should not be there. That is to say the normal maps dont work properly when shadows are off, not when they are on. If you try the same thing with Glossiness=0 and Environment=100, shadows make no difference. One of the problems people have with using normal maps in SL is that they see far less specular effects than they would like, unless they use local lights. This is because of the very restricted, unidirectional, lighting from the sun (or moon). By using very low Glossiness, you can get much more highlighting, and that seems to compensate nicely. However, a drawback is that you get impossible highlights from parts of objects that the sun doesn't shine on, unless you have shadows enabled. If you use much higher Glossiness, say the default 51, the effect is still there, but less pronounced, because the highlights from unlit surfaces are much reduced. It seems that in this case, the combination of the inworld ambient occlusion with shadows (you can control them separately in the Advanced graphics settings) has the strongest effect. I have no ideas why that should be the case. So my view of this is that the normal maps work as they should with shadows, but show artefacts when shadows are off. Of course, that is a pedantic analytical view, and it at odds with the more important pragmatic view. From the artistic point of view, it seems to be necessary to use low Glossiness to get useful effects from normal maps (because of the limitations of the lighting model). Normal maps are supposed to produce useful effects. The fact that these effects are then inhibited by shadows means to the artisat that the normal maps don't work with shadows. Take your pick. Here is one of the things I played with, glossiness=10, environment=0, 3pm default lighting. It's a plain prim cube, blank texture, blue colour, same normal map on all faces.

I don't think I understand the second part that. Not sure what a virtual shadow is. I would welcome further explanation, but only if you feel like giving it. Possibly you mean incident light will give no reflection from parts of a surface whose normal is at >90 degrees*. In that case, yes I understand that. For the first part ... yes exactly. That's why I was wondering if that was what was meant by saying they don't work. Never mind. I am quite happy with normal maps so far, so I'm not desperately concerned with these questions. :matte-motes-big-grin:

Sometimes the normal map effects can be sharper without shadows, so there may be some slightly deleterious interaction, but I wouldn't say that amounts to not working with them. Also, the illusory geometry that normal maps create doesn't cast shadows itself. In that sense, you could say they aren't working, I suppose, but I wouldn't put it that way.

"...but normal maps often don't and even when they do, the effect is very different from what they produce in high res graphics" I am intrigued by this statement. I haven't noticed much difference, but then I haven't particularly looked for any. Can you give some examples? Maybe pictures? Is it maybe on attachements, which I never look at?

That's the way it looks so far. That is, you can uplaod a dae file that has meshes with more than eight materials, but they will be split into multiple objects each of which has eight or less. With the ones I tried, the split objects were in a linkset, That's ok provided you don't unlink them and there's none of the "prim drift" we hear about, and provided they don't get unlinked (no-mod if you transfer them!). I haven't experimented yet with what happens with LODs. There could be problems with switching LODs of parts at different distances. Also, it looks as if the automatic default physics is made after splitting; if that's true for the automatic LODs too, there could be unexpected effects. ETA. In fact it's impossible to upload LOD with this files at the moment, because of another bug. I think it's being dealt with. However, at the moment the LOD switching is at the same distance for all the parts, because they share the same pivot point and the same dimensions, all inheroted from the unsplit mesh. So that's another reason why I think they won't be able to change the present scheme - it would mess up the coordinateded LOD switching.

"LL is working on having more then 8 materials on a single mesh object so this trick wouldn't work for long." On the contrary, the trick is the result of that development. As I said in the original post, it works only with the Project Import viewer*. That is the development viewer with the code that enables the import of mesh with more than 8 materials. The way they have chosen to do that is to split mesh with more than eight materials into multiple (linked) objects during the upload process. At the moment, that leaves the split objects each with the pivot of the original object before it was split. That is how the trick works. It depends on the ability to upload mesh with more than eight materials. However, since this is a development viewer, they might change it by adding code to to move the pivots to the centers of the split objects after they are split. They are likely to do that if the offset pivots are considered to present problems. So there is no guarantee that it will continue to work when the code is moved into the release viewer, as I also said in the original post. *the link to the download page for development viewer is in the blog post you linked to.

Yes. In a hull-based (that is Analyzed) shape, a simple stretched cube has a physics weight of 0.36. So this simple arch will be 1.08, which appears in "More info" as 1.1, but is rounded down to 1 for LI. So any arch using this would have LI of 1 unkess the download weight made it higher. Make sure the boxes don't overlap and use "Solid" before "Analyze" on the physics tab. It should say 24 vertices and 3 hulls. Hull based shapes don't change weight with size. So the size doesn't matter, while for triangle-based shapes it does. Also, it can be as thin as you like and the hole will stay open, while a triangle-based shape has to be 0.5m or thicker or the hole will be blocked (by the server - it doesn't show on the physics shape view). So the hull-based shape is probably the better general-purpose solution.

The wall was an example of a phenomenon that can happen with triangle-based physics shapes made from one or two completely flat shapes. For some unknown reason, the physics weight can become enormous, and it often depends on the order of triangles in the dae file. It also gets a bit smaller as the two planes are stretched further apart. Adding another face at right angles, connecting the tw sides of the wall in this case, can bring the weight down to the expected range. However, in this case there is a round arch with 16 segments. Consequently there are manu small triangles, and the physics weight stays quite high, whether triangle based or hull based (Analyzed). Trying to simplify the Analyzed shape doesn't seem to work without closing the archway. So I think this is one of those cases where you have to make a special physics mesh with simpler geometry. Here are the meshes I tried out with an arch with similar geometry. Top row is LOD meshes (third one used in lowest 2 slots). Bottom is two meshes for triangle-based shapes, without and then with the extra connecting face, then a mesh for a hull-based shape. With these three physics shapes, the physics weights/LI were 14.6/15, 0.5/1, 1.8/2. So this arch had the high physics weight problem, but much less than Pamella's, and it was solved by the extra face. With that solution, it was better than the hull-based shape, but that all depends on the size (here 8x8x0.52) and will not always be the case.