Drongle McMahon

I can't see what you did in your picture, but never mind, as long as it worked.

Perhaps I should add that the ability to offset the object's geometry origin (center/pivot) has been a feature request since before mesh was released. The developers did make one attempt to provide this, but it ran into (unknown) problems, and it was dropped. I have no idea whether it will ever be added, but I wouldn't be too hopeful. Since there is an easy work-around, it is unlikely ever to get a high priority.

First, don'y rez the object on top of yourself. This now seems to make it phantom! You probably need to make a physics shape and upload it with the model using the "Load from File" option on the physics tab of the uploader. Otherwise, you get the default shape, which is the convex hull of the low-LOD visible mseh. The simplest approach to get this to work is to make a mseh consisting of non-overlapping (tiny gaps) boxes that are already convex, then using the "Analyse" option in the uploader. This will produce a shape consisting of those boxes. The bounding box of the visible mesh and the physics mesh need to be the same, because the uploader will stretch the physics shape until it fits into the bounding box of the visible (high LOD) mesh. If your mesh is convex, and you don't need to go inside it, it may be enougth just to tell it to use one of the LOD meshes, but this is generally not as good, and often higher LI, than making a purpose built mesh. ETA: See Aquila's posts here for much more detail.

This is a problem with all things with an odd number of sides. The center used in the 3D program, and in the collada, is ignored by SL. Instead, it always uses the center of the bounding box. However you may rotate the propeller, that is never at its center. This situation is shown on the left of the picture. The solution* is to add an extra triangle, as shown in blue on the right, to make the centers coincide. Here, this is a copy of the opposite blade tip rotated 180 degrees around the propeller center. To make the extra triangle invisible, assign the extra triangle to a different material, and after rezzing, change its texture to "Default transparent" from the library.

Ah. That one. Never mind, we got to make some nice pictures!

Excellent description from Aquila. One small point to add - if the triangle for the low LOD texture is hidden inside the high LOD mesh, you can't select it to put the texture on it. There are a couple of ways round this. Easiest is to first texture the whole thing with the low LOD texture, and then apply the other textures to selected faces. Better (works for multiple low LOD textures), you can use Advanced->Show degug settings to set renderVolumeLODFactor to 0. Then the lowest LOD will be visible and you can select it or drop the texture on it. Then reset the RenderVolumeLODFactor. Finally, you can use a script, if you know how to do that.

Did you make it from a piece with a hole? If so, try something like this instead... If that's too high weight, just use a square hole, made from four pieces (or leave out the whole wall).

From your description, it sounds as if you were encountering the defualt physics shape which is a convex hull made from the low LOD mesh. Or perhaps you were telling it to use a lower LOD mesh for the physics shape. These options don't usually work well, especially for hollow insides. Follow Aquila's instructions, especially reading the thread, and you should be successful. Also, don't rez it on top of yourself - that seems to make the whole thing phantom, for some strange reason.

For completeness, here is another possibility... Vertex counts in Blender (sounds like you are using that) and in the uploader are not the same. In the uploader, every geometric vertex has to be duplicated if it appears with different combinations of normals (sharp edges) or UV coordinates (UV seams ). So in general, the vertex count in the uploader is greater than in Blender. However, that sounds like it's the same for your parts. You didn't mention UV at all. Was the original cube UV unwrapped before applying the array? After? If there is no UV map data for an object (if it wasn't unwrapped in Blender), the uploader appears to use uninitialised memory instead, which causes effectively random UV maps. This can lead to large variations in download weight because sometimes vertices, at the same place but for different triangles, end up with the same UV coordinates (eg if the memory was full of zeroes) and sometimes they are all diffrerent. So if there's no UV mapping, that can be another source of unexpected differences in download weights (and thus in LI).

You say the second one (2.2 download weight) has fewer triangles. Are you sure? Does it say so in the uploader? What about the vertex counts in the uploader? That's more important ( vertex=16 bytes; triangle=6 bytes). There are various possible causes for higher vertex counts, including sharp vs smooth edges and UV seams. Do they both have UV maps? Most important of all, how are the lower LOD meshes made, and how many triangles/vertices do they have? For something this size, the lower LOD meshes will have more influence over download weight than the high LOD.

Things like that cable are the devil. Looks like you vave a six-vertex cross section. That could be reduced to five, and maybe the plugs could use fewer too. I can't see what the structure of the pins are, but they look like they are too detailed too. You really have to make the lower LODs by hand to avoid those artefacts, probably just removing alternate (or more) loops around the cables at each step. However, at this size, the lowest LOD will be by far the most important for LI. I'm assuming this is nearly flat. In that case, the lowest LOD (or maybe even the lowest two) could be just a flat plane with a picture of the cable on a transparent background. That will give very low LI (since you already have good physics). You do have to have the same number of materials in the meshes at all LODs. So you have to add a small triangle, maybe inside a plug, to carry the low LOD cable picture in the high LOD mesh. That's the hidden triangle. Similarly, you have to have triangles in the low LODs to carry the textures used in the high LOD. In this case, they can be facing downwards so that the textures won't be seen. It was those textures hiding on these extra triangles that I was calling the low LOD tecture etc. ([low-LOD] texture, not low [LOD texture[).

I went and had a look... Bench on veranda: Server weight 5.7(Uh? Did they change the rules here? I thought it had to be an integer*0.5 !). So it can't go less than 6 LI unless you join the meshes. For now, downloas weight is 6.9, which is hihger, but there's plenty of opportunity for reducing this. First, the legs and the curved part of the back have some faces subdivided into three when they don't need to be. Second, there are lots of faces on buried ends of various pieces, which can all be removed. Lod behavior is a bit odd, with the arms disappearing. This may be solved by joining. The LI in the end will depend on the low LOD mesh. The other bench, with the cushions is so high because the cusions and blanket have many more triangles than they really need. House: Generally very nice, but the window frames have very poor LOD behavior-almost as bad a sculpties. For the round windows, this happens even while you are inside the house (because they are small). This was with renderVolumeLODFactor = 2.0, which is the default for High graphics settings. Same problem with the front door frame, where some of the small bars are separate meshes, so that they switch LOD at very small distances. Do these really ness to be that much rounded? Windows are very easy to make perfect LODs at low LI because you can use simple planes with alpha texture for the low LODs (you hide it on a hidden triangle at the high LOD and put extra hidden triangles for the high LOD textures on the low LOD). I would strongly recommend using this technique for all your windows. It will improve LOD behavior and reduce LI. You can make the switch further away, if you want, by joining some windowns to make them bigger, although that would likely also increase LI. The round windows also look like they have many more triangles than they need. There are also lots of beams in the house with sides subdivided into three, as in the bench (are these made from prims?), and lots of hidden ends with unecessary caps (eg, bannister rods). Finally, there are some rounded things that seem to be using more triangles tyhan they are worth; for example, the fireplace and the chandelier chain. Are these already making use of smooth shading, rather thyan subdivision, to save triangles and LI? Eta: By the way, I have used the window low-LOD-alpha technique on a LI=1 bench too. First the slatted back and base are replaced by an alpha. If has the legs and uprights too, but they stay hidden under the solid ones. Then at the next LOD, the legs disappear so it's only the simple boxes with alpha. If I can find the meshes, I'll upload some pictures. Here's a picture. Four LODs in orange, physics in yellow. One of the low LOD textures on the right. Probably should have been smaller, 128x128. Lost the one for the seat part. You can reduce LI further by skipping the second LOD.

You are probaly right. but there are problems with the inbuilt ao. To get the best effects, you need to use different ao distance dependence and falloff for different sized objects, but the inworld ao doesn't seem to allow this (I might be wrong there). Then, of course, there is probably a majority of users who can't turn it on anyway.

This works because the shadow (or ao) map can be much lower resolution than the diffuse map and the diffuse map can be tiled. I believe there vis at least one jira feature request to have this formally added to the materials system. Right now, you can use different sizes and repeats in the normal and specular maps, which can get some savings that way. The idea would be to allow a second diffuse texture, with independent size and repeats, that would be overlayed (multiplied is all that's needed for shadows) on the tiled diffuse texture. This would allow a 1024x1024 texture. for a tiled floor with ao, to be replaced by two 128x128 textures, a 128x128 tile with 8x repeats and a single 128x128 shadow map. That's an eight-fold reduction in download data size. It would also remove potential problems with alpha overlaying with other transparent textures. Only one channel is needed for the shadows, so the others would be available for something else. Of course, the viewer would have to combine the diffuse textures before they were put into the gpu (or can gpus do it?). So there would be no saving of gpu memory, but none extra would be used. I guess the objection would be not wanting yet another potentiall huge map, but size could be capped and repeats limited to 1x1. The texture download savings are potentially huge.

"I can't use a 16 x 16 as it is 2 eyes" But I thought you said you wanted to be able to use separate textures on each eye? If not, just use 16x32 (or 64x128 with my original guesses about size). Another difference is that you woyld be able to use lossless compression at that size (up to 128x128, I think, certainly to 64x64). PS. If we are taking about 1024x1024 decompressed into gpu memory, that's 3 Megabytes for each eye (without alpha channel). I just read something about compression in gpu memory - up to 4x for the latest version, which would make it 750Kb, but that was all in the context of DirectX and compression is slow, so I would doubt that SL uses it.

"...only uses 2 768 textures..." Do you mean 768x768 textures? If you do, then those will be resampled to 512x512 before compression and upload. 800x800 also becomes 512x512m while 900x900 becomes 1024x1024. SL only uploads exact powers of two in both dimensions. It's probably better to make your textures exactly 512x512 or 1024x1024 to start with, so that you don't get resampling errors piled on top of the inevitable compression errors. You can do things like 1024x512 if that works better for you UV map.

If you use a separate texture for the eyes, it doesn't need to have the black space. It can just be a smaller texture. So if your eye fits in, say, a 64x64 section of your 1024x1024 map, then you can use a 64x64 texture instead of the 1024x1024 with all that black space. All you have to do is scale the eye up by 16x in the UV map (it's a different texture, so it can overlap the rest of the UV map). The pixel density on the textured eye will not be changed. However well the black space compresses, the file with the extra black space will always be bigger than that of the 64x64 texture. Furthermore, I believe most graphics cards will decompress the whole texture before they can use it, in which case the black space will be a huge waste gpu memory. Maybe someone who knows about gpu internals can confirm or refute that.

I made the mesh wall from scratch in Blender, with a few measurements from the original.

"Prim spheres, cylinders and boxes act like convex hulls." Hmm. A pity. I was hoping they might be even more resistant to penetration in the first place.

Unfortunately, the uploader deosn't recognise parts of the physics shapes that could be Havok primitives. So each simple box, converted to a hull with "Analyze" has a physics weight of 0.36, while each legacy prim box has a physics weight of only 0.1 because it is recognised. Cylinders are more.

For anyone following, Zantyago let me look at the house. It is mostly legacy prims, with just the mesh parts he mentioned. The mesh were all good, with low weights. The weight was all physics weight from hollowed legacy prims that were pushed into new accounting by being linked to mesh. There were 22 of those contributing 114.2 physics weight. The rest of the legacy prims had physics weights less than their server weights. By setting all the hollow prims to physics type "None" and using simple invisible linked prims to fill in the resulting bphysics holes, the LI came down to 49. It's still using a lot of prims. Judging by what could be done with one end wall, I think making it entirely of mesh would easily get the LI down to less than 30.

"You could do the same with prim boxes" That raises a question. How does the collision behavior of prim boxes compare with either kind of mesh shape? At first.I might expect it to be like triangle-based mesh shapes, because that's the type of shape used by most lagacy prims. Has anyone tested penetration of these? But then I remember that, provided they are only stretched and rotated, with no other distortion, prim boxes use the havok primitive box physics shape (hence the very low physics weights). Can you penetrate those? And what happens if you do? Do you get stuck inside?

I think I know what you mean by making it stronger. This has been the problem for many people. The specular reflection in normal lighting is ogten not very evident. This is because it comes only from the sun, and sunlight is parallel. So there is only a tiny range of surface angles that give reflections. Then, of course, there are none at all from the surfaces that are not in direct sunlight. It's also a problem if there are only a few parts of the specular map which are really bright. The specular reflection has to show up above the diffuse light, and that will not happen where the specular map is dark. It's important to remember that the specular map is not a map of actual highlights. It's a map of which parts of the surface can have highlights when they are at the right angle with respect to light source and camera. There has to be a lot og bright areas to get a small amount of actual highlighting. You can get more obvious specular light by using a low specular exponent. Zero gives none at all, but 1 gives a widespread sheen at all angles. Values between 1 and 30 (for white areas on the specular map) are easier to see. The trouble is, these reflections are not the sharp highlights we expect for really shiny things. The effect is much more obvious with local lights. I think this is because the light from these is not parallel, but strikes the surface at a range of angles, it seems more points on the surface can be at the right angle to get proper sharp highlights. You can also place the lights to maximise the highlights. The environmental reflection is completely different. It comes from all round. So it tends to affect all of the surface other than those parts facing the ground. Unlike the specular reflection, it isn't additive with the diffuse reflection, but it replaces it. So the diffuse underlying texture becomes less and less evident as the environmental reflection increases, until at the maximum, it disappears completely. This is the basis of the mirror / chrome effect. Consequently, this kind of effect is much easier to see. It means you can seee the flock pattern from (nearly) all angles, while the purely specular effect is only visible as highlihjys (unless the expoment is very low). Old fashioned local lights don't contribute to the environmental reflection at all, but there are (at least for now) some very peculiar effects with the environmental reflection from projected light sources. This behaves in some respects more like specular reflection, and its intensity doesn't obey the same rules as the sky reflection. This can result in incongruous effects with projected lights when you have both specular and environmental reflection.

Are you sure the Cycles isn't in Blender? Anyway - I don't use photoshop for this, so I can't tell you exactly. To make the alpha channel, you need to find how to add a transparency mask. That will become the alpha channel when you export to png or tga. The transparent parts are the black parts of the mask, which will be unshiny. The white parts are opaque and will be shiny. In Gimp, you have to be careful to stop it setting completely transparent pixels to zero colour. I don't know it that's a problem in PS. To see the parts of the edit dialog controlling thec specular map, you have to be using a materials-enabled viewer (such as the latest release fro LL). You need to have Advanced lighting turned on in Preferences to see the effects (but, strangely, not to do the editing). On the Texture tab of the edit floater, you should see a dropdown button labelled "Texture (diffuse)". That is the old simple texture. From the button, you can select "Bumpiness (normal)" and "Shininess (specular)". Selecting those gives you access to the relevant maps. That changes the texture preview box so that it now applies to the appropriate map. To set the texture there, either drop it onto the preview box, or click the preview box and select from inventory. When you have chosen Shininess, two spinner controls appear that control the specular exponent (sharpness of specular reflection) and the environmental reflection (from the sky, like old shiny). The spinner value muliplies the value from the relevant map*. Underneat those is a colour selector that filters the specular reflection colour, Using greys here effectively controls the intensity of the specular reflection without altering its sharpness. So you have two new kinds of reflection, in addition to the diffuse, non-directional, reflection from the old texture (=diffuse map). First, the specular reflection, highlights that depend on the angle of the surface and camera and light sources. For this, the intensity and colour are controlled by the RGB channels of the specular (shininess) map. The tightness of the angles where it is seen are controlled by the specular exponent, that is the alpha channel of the normal map multiplied by the glossiness spinner. Second is indirect, environmental light, from sun and sky. This is a mirror or chrome like effect. You can't change the colour, but the intensity is controlled by the alpha channel of the specular map, multiplied by the environment spinner. By far the best way to understand these settings is to play with them inworld, using whatever textures you have available. Black and white checkebords are good for this, and you should try with completely black and completely white blank diffuse textures before getting into the effects of colours. (Note that when I say multiplied here, that is actually spinnersetting / 255, so that the range is 0-1).

Can't really say without knowing how much detail there is in inside etc., and what you expect it to be used for. Also, I'm not sure what youi mean by "mesh attachements". Isn't it entirely mesh? The LI capacity of a standard 512 sqm parcel is 117 prims. So if you want to sell it to people with 512 sqm plots, then it is certainly too high. A small house like this should probably be much less. We might be able to suggest ways to reduce it if you let us see a wireframe*, and say what the download an physics weights are, by looking with "More Info" on the edit dialog. *To get a good wireframe snapshot, Do Develop->Rendering->Wireframe, then turn off sky, surface patches and water using the Advanced->Rendering types menu.