Drongle McMahon

Here's another simple way... Note that the added circle is a mesh circle, not a curve.

Hope I've understood the aim here. It's a pity the Profile paramter of Bevel won't go down to zero, as that would have made it very easy. As it is, the easiest way (as Dora said) may be to use the Boolean modifier: Snap the cursor to a corner; go into object mode and add a cylinder; scale it to the required size; then reselect the other mesh and add the Boolean modifier using Difference and the cylinder; apply the modifier; repeat for each corner. Another way is to use the Spin tool. Use Loop Cut & Slide to make a cut that will be where the circle meets the edge of the box; snap the cursor to the corner; look straight down on it; select the two vertices of the cut edge and use the Spin tool to extrude it 90 degrees (+/- as appropriate) with however many segments you want. When you have done all the corners, you can delete the original corner vertices and fill in the faces using edge loop bridging and/or F (exactly how depends on whether you like ngons or not). I had to recalculate normals too. Maybe this will give you some ideas... In either case, you can use your picture as a background image, that will be visible whe looking directly along an axis in orthographic view mode, to guide you in getting the circlular edges in the right places.

Looks good. Thanks for reporting back.

I agree that the way you describe for reversible temporary rotation is very useful, especially for the majority who don't like numbers*. It remains the case that not applying rotation and scale is one of the most common sources of problems raised here, and avoiding object-mode editing is the easiest way to pre-empt them. So I will stand by that advice for beginners. As they learn more, they can take advantage of nice tips like yours. Lattices are a different matter, and thanks for pointing that out. The advice is really intended only for editing mesh, not other kinds of objects, but I guess that was not explicit. I'll change it. I haven't used lattices enough to claim familiarity, but the Blender manual is now quite clear about this, which might avoid confusion in the future. I'm still not sure I fully understand the effects of object-mode lattice transformations after linking the lattice modifier though. Can you offer a simple description? *Personally, I do prefer to work with the numbers, but I know I'm peculiar in that way.

All the best rules have exceptions :matte-motes-smile: (although I think your first example can just as easily be done in edit mode if you take the trouble to read the angle while you rotate)

Can't say for certain that it's causing the error, but you mesh has far too many triangles. The absolute limit is 21844 triangles per material, for a maximum total of 174752 (look in sl wiki, for 'limits'). If some materials have less than 21844, the maximum total drops by the difference. Usually beyond that the uploader just omits further triangles, leaving holes, but I never tried a mesh with as may as yours. So it could just be the excessive geometry alone. Also, with so many triangles, same of them are probably below the minimum dimensions. That would lead to 'degenerate' triangles, effectively those with (almost) zero area. There is code that's supposed to eliminate these, but it can probably sometimes fail, leaving invallid geometry. I don't know what construction techniques you used that made such a high triangle count, but I'm afraid, whatever it was, that you will have to find a way of using much much less geometry before you will succeed with uploading mesh.

Pamela has given the answer that will help in the future. The unwrap functions work on the geometry before Object-mode transformations are applied. So it's seeing the original cube. Applying rotatoin and scale resets the Object mode transformation and changes the geometry instead. There are other problems that arise with Object mode transformations So the best thing is to do as little editing of mesh as possible in Object mode, preferably none. When you do, always apply rotation and scale before going into edit mode. After applying, the default unwrap will give you islands with correct proportions. Then yoiu can just move, rotate ans scale them to get what you want, without changing the correct shape of the fromt face. If you keep the long thin unwrapped edges spanning right across the UV space (as I expect they do by default), then there will be no visible join if you use (a whole number of repeats of) a tileable texture. Here's a default unwrap, with the seams you have, to which just move scale and rotates used to get the one on the right.. No scaling in just x or y, so that the shapes stay the same as they are in the geometry. The active face (dotted) is the front. ETA: inserted "of mesh" in response to Drew's correction below.

I don't think it's significantly different. The video is just about the same as in my second message, with nothing connected to the output texture image node. In the earlier one I had the combined UV map attached to it, but that doesn't have any effect. Instead, that UV map has to be selected during the bake. The other difference is that she uses a separate input UV map for each of the materials. That is fine, but you can do equally well with just one. In fact at one point you see one of her input UV maps, and you can see that it has the three maps superimposed. So it could have been used for all of them. Probably I shouldn't have complicated mine with the extra nodes for different purposes!

Another good reason for people to to make their own LODs. :matte-motes-smile:

That's interesting. I knew geometric things could make the LOD generator fail, but not that duplicated vertices could do it!

And the vertex&triangle counts for the generated LODS? You don't need to actually upload them; just see what the uploader says and quit before clickin the calculatr button.

None of those guesses right then. A good thing you have the old file. That should make the problem discoverable. Did you notice what the actually obtained LOD triangle and vertex counts were? We have seen before some effects of the precise geometry that can prevent the automatic LOD (GLOD library) generator working, and that can depend on as little as whether one edge is split or not. That would show up with the problem mesh having higher counts in the LOD meshes even though they had the same target count. One more thing, are you using SLM files ... these are used by the uploader to restore settings when you upload a file with the same name. That can cause problems when the file has changed. You can avoid them by clicking the clear and restore button, by deleting the .slm files, or permanently by setting debug MeshImportUseSLM to false. I always have it set to false.

"If i remember correctly you experimented with order of vertices in the exported collada file? And you found significant difference depending on that order?" That effect was only for triangle-based physics weights. Here the download weight has changed. I suppose there could be a comparable effect there, but it's not something I have seen.

1) What are the triangle and vertex counts displayed in the viewer? 2) Do they agree with the counts in your authoring software? 3) If you make a copy and collapse the UV map to a point, does that have any effect? 4) Are yoy uploading it with the same final size? (look at the dimensions in the las upload tab). 5) Have you done anything that involves subdivision or "smoothing"? 6) Which of the physics weight or the download weight reported by the uploader is higher?

You can upload the textures separately and put them on the mesh inworld. It's the same as putting textures on prims. Either select a face, click on the texture preview and select the texture, or even easier, drag and drop the texture onto the face. If you have inaccessible faces, the texture can also be applied by script.

You have more that 160,000 triangles in this model. This is FAR too many. As you didn't say what you did about LOD meshes, I have to guess you used the auto LOD generation in the uploader. That would still leave you with 2500 triangles in the lowest LOD. For an object of this size, it's the complexity of the lowest LOD that dominates the download weight part of the LI. It needs to be much lower. Almost certainly the chains account for a lot of the geometry, and replacing them with simple rope would help. It is possible to have chains with quite simple geoemetry and very simplified lowest LODs*, but that's quite a lot of work. You are perilously close to the absolute limit of 174752 triangles, above which the uploader will simply start omitting extra triangles. Even before that, you are likely to run into texturing problems if you have more than 21844 triangles assigned to any one material, because the uploader secretly starts new materials when it reaches that count. It is sensible to limit your model to less than 21844 triangles per material to avoid these problems. I would guess you should be able to do this model pretty well for well less than 21000 triangles. If you click the More Info link in the edit dialog, you can see the download and physics weights. If the physics weight is higher, then that will determine the LI. Again, you haven't said how you soecified the physics, or whether you used the default. In a modellike this, you might have to make a special physics model, depending on how you want to use it. Also, if there's any chance you might want to make it actually swing, then you will need to make chains+swing and stand as separate objects (you can still upload them together). *As Kwak showed you while I was typing!

Ah. I was using my old 2.71. A "Correct UVs" parameter has been added to Vertex Slide since then. On my 2.74 though, it's off by default so that GG doesn't use it. Once you have checked it with the tool, it then works with GG too. Is there a way of accessing the option via GG? Or maybe there's a setting. Thanks for the correction. I'll note it on the post.

Good workflow from Aquila. It's very easy to forget the UV mapping and texturing before making lower LODs, but it is essential. If you forget, delete the low LODs and go back. That will save you time in the long run. The trick is to use only UV-map conserving tools in the decimation. Some of these, like Dissolve, always preserve the UV map. For others, like edge slide and vertex merge, it's an option you can check in the panel at the bottom of the toolshelf (left of 3D view). For yet others, such as vertex slide, it's not even an option*. So avoid those unless you want to end up editing the UV map by hand. The UV map preservation doesn't (usually) work if you do anything with UV seams. In fact, dissolving or edge sliding a seam edge can cause catastrophic destruction of the UV map. So It's worth a little thinking ahead to make sure the seams are on edges that will stay where they are in the LOD meshes. Aquila's example shows an exception to that rule, the wheels, where a whole island gets removed. That's OK because the horrible effects happen when UV faces start connecting between islands. One other note about the layout - if you are going to use re-usable tileable textures, you need to be careful about the orientation of the islands. For example, pieces of wood have to be oriented so that the woodgrain runs the right way. They also have to be the same scale. This applies whether you are making a second UV map for applying the texture before baking, or whether you are going to use the tiling texture inworld. The latter can save a lot of texture lag when the texture is used on multiple objects. *ETA: It's been added in 2.74. So vertex slide is ok now,

All the other meshes, lower LODs and physics, are stretched or squashed by the uploader to fit the bounding box of the high LOD mesh. So if you take the knob away, you need to to have something level with the top of the knob to stop it being stretched. There are tricks to get around this, but I think you might want to get a bit further with the basics before getting into more complicated stuff.

Also, have a look at Arton's normal editing in this thread. When that gets into the release, 2.75, the profile=1 method will be redundant. You will be able to use a real bevel and modify the outer normals instead. There's going to be a lot to learn about the best ways of doing that.

Oh yes - that's easier than I expected. And here they are inworld with a bit of shiny; same geometry with single segment bevel, with transferred normals on the left, without on the right. This is going to be very nice and should enable big LI savings.

OK, I think I have made some progress with understanding this ... 1) The camera icon that is supposed to specify the UV map used in rendering does not appear to have any effect in Cycles, rendering or baking. Instead, it is always the selected UV map (blue bar) that gets used. Whether this is a bug, or whether the camera icon is only for the Blender renderer, I don't know. I haven't tested that. 2) Specifying a UV map by connecting a UV Mp node to the Vector input of the Image Texture node for the baked image doesn't work. So the only way to specify the UV map for baking is to select it in the object data properties. 3) Specifying a UV map by connecting a UV Map node to the Vector input of the Image Texture node for input textures does work. Then the selected UV map in the object data properties does not change which map is used. So that is the way to use different maps simultaneously for input mapping and baked output mapping. All that provides a way of combining input and painted texture, using different (or the same) UV maps for input and baking. The example illustrating this is the same model used above. Just the "wood" node setup is altered. For simplicity, the repeat and rotation mapping has been omitted, and a different input wood texture is used. That is combined with a new image called "paintme", which starts off blank black, using a Color:MixRGB node (here called "Lighten" because that mode was selected). Now you can paint on the model directly and still bake out the result, if you follow the conditions below. I'm not going to try to explain why or detail the consequences of doing otherwise, because it's just too complicated (and I'm not sure I understand it). You just have to do what you are told! To paint: View->Texture Paint; In Object Data properties, select the source UV map; In the node editor, select the Image Texture node with the "paintme" image; In the 3D view, set the view type to "Material". Now you can paint. To bake: In Object Data properties, select the target UV map; In the node editor, select the Image Texture node for the baked image; In the 3D view, set the view type to either Rendered or Texture. (Remember the output Image Texture node must be selected in the other materials too). Now you can bake. This can be simplified if the same UV map is used for input and baking and/or the paintme texture is used alone instead of being combined with another image. This is the setup and view during painting ... And this is the setup and view for baking (after the bake finishes) ... ETA: Note - the bake here is Diffuse color only, for speed. It all works the same with combined bake too.

Ah yes ... we have that in Blender too now ... It was working on the overnight builds. Don't know if it's in release yet. Nor do I know if there's a convenient workflow for this application. I hope so - It's going to save a lot of uneccesary extra geometry.

With smooth shading, the normal is gradually changed as you go across the surface, from the values at each corner. For this model, the effect is that the the surface of the large rectangle in the middle of the arm has a slight bulge, When light strikes this at a nearly glancing angle, the bulge has a large effect on the incident light intensity per unit of the surface. One side of the bulge is almost in shadow. So the diffuse reflection there is correspondingly lower. Where the border between more and less brightly lit parts happens depends on the angle of the incident light. In SL, that is where the sun is, So it will vary with time of day. Here is an illustration of this effect. The model is on the left. The first two blocks have opposite triangulation to show that triangulation is not the cause. In the third block, extra edge loops have been added near the top and bottom, outside the bevel. The effect of that is that there is no longer any variation of the normal in the vertical direction. The virtual bulge is now cylindrical instead of ellipsoidal. Then there are three panels in rendered view, with a single "sun" lamp pointing at the model at a glancing angle, first from the left (6am or 8pm in SL), then from above (12pm in SL), and finally from above-left (9am or 3pm in SL). You can see (a) that triangulation direction makes no difference, (b) that the diagonally glancing illumination has the expected effect from the virtual ellipsoidal bulge and © that you can eliminate the diagonal effect by having only a cylindrical bulge. In other words, this is an intended and expected effect. If you test the effects of angle to the sun ant time of day, you should see that it is dependent on these. If it doesn't fit with the expected appearance, then changes to the geometry should be able to get you nearer the expected effects. ETA: You say the part with the shading is flat with perpendicular normals, but it doesn't look like that's quite true in the picture on the right. You could look at the vertex normals to check that. Those are the ones that need to be perpendicular to the middle face it you want it to be shaded completely flat. For that, the face normals need to be perpendicular both sides of the edge, but the ones above and below your middle face are clearly sloping outwards.

Hmm. Although that works, it isn't that simple. The UV map used by the baking doesn't come from either a map input to the Image Texyure node vector input, nor from the seexted UV maop, nor from the one marked as render (small camera icon). I'm still trying to find out where it does come from. Anyone know?