Drongle McMahon

Can you say how you make the file you are trying to upload, at which point the upload fails, and any error messages that you get when it fails? That would provide the context needed before it is possible to offer an explanation.

If you use Blender 2.64, you can remove vertices without affecting the UV mapping by using the Dissolve function. This alone makes it worth upgrading to 2.64. Did you check that the offending faces were assigned to the same material as the neighbouring faces?. What do you see in Blender if you switch display to textured, and/orturn on textured solid display in 2.64)?

"I need to shape the binding box the same as the wall and windows am I correct ?" Yes. All the low LOD visual meshes and the physics mesh are stretched to fit the bounding box of the high LOD mesh as part of the upload process.

I think that's all as expected. Since you are attaching it, the rotations are relative to the attachment point rather than the global axes. In the first picture, the un-applied object mode rotation becomes the of the local axes relative to the attachment pointroatation in SL, which you can reset in the edit dialopg as you point out. In the second picture, you have applied the object mode rotation to the geometry. So now the object mode rotation is zero (as you see in the edit dialog) and the geometry has been rotated relative to the local axes. You can revert that ritation by doing the opposite rotation of those local axes in SL, as you show in the last figure. Summary: Object mode rotation: not applied -> rotation of object's local axes in SL. Gemoetry relative to object's local axes unaffected. Object mode rotation, applied -> object's local axes not rotated in SL, Geometry rotated relative to object's local axes. Or (same thing): Object mode rotation -> rotation of object in SL; Edit mode rotation -> geometry rotation relative to it's axes; Apply rotation -> convert Object mode rotation to Edit mode rotation.

If it's in the orientation you want, go into object mode and do Object->Apply->Rotation(and scale). That will set the object-mode rotations to zero and apply the exactly compensating rotations to the edit-mode (local) geometry so that the object doesn't move at all.

Roataions in edit mode affect the relationship of the geometry to the local axes of the object inworld. Rotations in Object mode do not affect the geometry relative to the local axes; they just rotate those axes relative to the global world axes. So object mode rotation will not rotate the object relative to its stretch box, while rotation in edit mode will. As said by others, applying object mode rotations befor upload is nearly always the solution to this sort of problem.

Why do you want to make a higher LOD? If you want to delay the LOD switch, just use the same high LOD mesh at the first two LOD levels. If you really want to add more detail, You will get much more control by adding edge loops individually with "Loop Cut and Slide", than with subdivision. Adding edge loops should not alter UV mapping or cause problems with materials/faces. For making lower LODs, decimate is very bad for anythging other than high poly organic shapes. Your frend here is "Dissolve" which joins faces up and leaves the UV map intact. However, you must avoid dissolving UV seams and the boundaries between materials, as this will give you problems. It's best to think about how you are going to disso;ve when you decide where to put seams and allocate materials. The rounded part of you building appears to be solid shaded. This probably isn't what you want. It will save a lot of land impact if you make this smooth shaded. Just use the edge split modifier and Mark Sharp, if you have to, to make the top and bottom edges sharp. The round paret will also be a problem for the physics shape. It will have many vertices if you use a decomposed shape ("Analyze"), or lots of narrow triangles if you use a triangle-based shape (no "Analyze"). Either way that makes for a high physics weight. In the physics shape mesh, Make this as few segments as possible to still give acceptable collisions. Above all, if you use a triangle based shape, remove all the narrow triangles along the edges of solid walls. The LOD meshes are never good for making the physics shape. Here, for instance, the physics shape should not have the windows (unless you need to jump through them). Having them closed in the wall physics also means you can use "None" for the physics shape of the windows themselves (if these are separate meshes objects). Never use "Phantom" for making mesh uncollidable. Link with a normal prim as the root and set the mesh physics shape type to "None". This is much more efficient in the physics engine, which can then ignore it completely. When you don't see "Prim" in the edit dialog physics shape type chooser, this is because there was no physics shape uploaded. So you are left with only the default convex hull, which you can't go inside. I may be because you uploaded with no physics shape, or because of errors in the physics shape mesh (it should say so though!). I guess jumbled questions get jumbled answers! :matte-motes-grin:

What is the lowest LI a mesh object can have? Is it .5? As part of a linkset, yes, because 0.5 is the minimum server weight. As an object on its own, this will get rounded up to 1. Is the lowest upload fee L$11? I don't think the upload fee algorithm is public, but I have never seen a lower fee.

If you put a test grid, such as this, onto the sculpt with 1x1 repeats, that should show you how the texture is distributed ans thus how you need to set the repeats to get what you want.

A small correction to Gaia's explanation..... The importer doesn't ever upload face normals as such. Only vertex normals appear in the upload data. At a smooth shaded vertex, all the triangles that meet at that vertex have the same normal for it. So they can all point to the same entry in the vertex list, and it only counts once (uv seams apart). When the triangles are flat shaded and have different normals, then the vertex has to appear in a different entry for each different normal. All three corners of the triangle then appear in the table with the same vertex normal, which is the same as the face normal in the authoring program. I's the same with the UV mapping. Most vertices on a seam appear in at least two different locations on the UV map, with different locations for the triangles separated by the seam. Each vertex list entry has only one UV position, so those triangles have to point to different entries in the vertex list.It's not the seams per-se that cause the extra entries, it's the appearance at multiple UV coordinates. So the effect is still there whether you unwrap using seams or by other methods. Highly fragmented UV maps increase land impact, especially of smooth-shaded meshes. Of course, if the triangles are already pointing to different entries because of sharp shading, then they don't need to be duplicated again for the U?V seam effect...and vice-versa. Tha's why it's better to have sharp edges ans seams coincide. Materials have copletely separate triangle and vertex lists. So vertices at the edges of more than one material have to be repeated in as many materials as they touch.

It's fine for people living in towns, but for people like me in the countryside, where we will never get fast broadband (currently <2Mbps), more and more sites are assuming higher rates and becoming unusable. What we need is a LOD system for websites.

I did try some hair by converting the Blender particle hair to mesh and then baking the texture from that onto a simpler mesh. It completely failed for me. For some reason I just got shadows for most of the hairs. So if you can do it, please tell us how. I ended up just taking the rendered image of some hair growing out of a plane, using that as the texture, and trying to jiggle the UV o get it looking reasonable. I gave that up before reaching a wery satisfactory end pruduct. So I'm still wearing my terrible torus hair! :matte-motes-agape:

The download weight, which usually becomes the land impact, is calculated from the actual size of the download data after compression. It also includes adjustment for how often the higher LODs have to be downloaded and how often only the lower ones. So it is a pretty good indication of the relative amount of data the mesh needs to be downloaded, although in reality that depends heavily on the actual graphics settings - higher object detail (renderVolumeLODFactor) and greater draw distance mean more data to be downloaded. You can see the download weight by selecting, choosing edit, and clicking on the 'more info' link on the Object tab of the edit dialog. Unfortunately, many mesh items are not well optimised and have excessive download weights. This is especially true of attachments where there is no land impact cost as incentive to optimise. Many mesh also use several large baked textures, and the texture download can take more data than the geometry download. That is not included in the land impact.

"I did upload the same model already and it didnt have problems(but wasn`t unwrapped)." If you upload a collada file with no UV map coordinates (that's what happens if you don't unwrap in Blender), the results are unpredictable. It appears that the uploader uses uninitialised data for the UV map. Depending on what that data is, it can have variable effects on the land impact. For example, if it's all zeroes, there will be no UV seams. If it's completely random, every edge may be a seam. It's often different each time you do the upload of the same file. There are also strange and variable effects on what happens when you apply a texture.

"The download size is definately smaller." You may be confusing the size of the collada file with the upload data size. The collada (dae) file is not uploaded to the server. It is converted by the viewer into a much more space-efficient internal format, and then compressed, before it is sent to the server. As far as I know, the download format is exactly the same as the upload format, and if all the data is fetched, it would be the same size. However, the viewer will not request the higher LOD data unless it needs it. So, as long as your camera is not close enough to see the highest LOD, then the download data size will indeed be smaller than the upload data that contains all the LODs.

The internal mesh data format in SL consists, for each material, of a triangle list and a vertex list. Each triangle entry has three indexes that point to its three vertices. Each vertex entry has its position, its normal, and its uv coordinates. Generally, multiple triangles share a vertex in your authoring software. If the shading is smooth at that vertex, the meeting triangles see it as having the same normal. If there are no UV seams through the vertex, then the meeting triangles see it with the same UV coordinates. If both these conditions are satisfied, then the triangles can all point to the same entry in the vertex list, and it will only appear once. However, if these conditions are not satisfied, then a new veretex list entry has to be made for each different normal/UV-coordinate combination that appears. This always causes multiple entries for vertices, that your program sees as one, along sharp edges and along UV seams (a good reason to have them coincide). The number of vertices reported by the uploader includes all these duplicates. It can be much larger than the count of unique vertex positions usually seen in your software. The four-fold increase you describe is not exceptional. It is highly advisable to use smooth shading wherever that is approriate to avoid the consequent increase in land impact. If you were relying on subdivision for smoothing, smooth shading can also save a lot more by further reducing the triangle (and vertex) count. I usually make all faces smooth shaded and then only sharpen those that need to be sharp. Minimising the number of UV seams is ually important, although it can be more difficult when it involves compromises with texture distortion.

Is the problem specifically with this new dae file, or does it happen also with files you have uploaded successfully before?

"I am confident that the developers will realize this..." I'm glad to see your optimism on that point. It makes me a bit more hopeful too. :matte-motes-smile:

The collada file has the expected numbers of vertices (24) and normals (108, many identical). Then it has two <traingles> sections, each of which specifies the entire set of three cubes with one and then with the other material. So there are two faces for each triangle, both using the same vertices. This is odd. Importing it into Blender leaves it like that, with the two sets of faces with different materials overlying each other, but I don't think it's possible to crerate that in Blender. If you exactly superimpose two cubes with different materials and then remove double vertices, it deletes one of the overlayed faces. No idea how it decides which. I have to suspect this is what you did ... exactly overlayed the whole set of cubes, one set with each of the two materials, after which the duplicated vertices were removed, either automatically or explicitly. However, unlike in Blender, the superimposed faces were both left intact. If that's not what happened, then something else must have caused the superimposition, either during the editing or during the collada export.. What happens in SL? If you select the visible face, then make it transparent, do you see the second face in it's place? Anyway, since the uploader has to duplicate the vertices and triangles for each material, it is telling you the correct numbers for what is defined in the collada file. The problem is with the mesh and/or the exporter, not the uploader. If you can access both faces, as when inporting into Blender, then I suppose you are getting your LI's worth in the uploaded mesh. ETA - actually, looking at your Maya picture, it says 36 triangles. So perhaps it is the collada exporter that's cuasing the problem. I don't know what material;s you have on each triangle in the Maya. Can you have two at the same time? If that's the case, that could be the problem. Then the exporter may have to duplicate them because collada can't have faces with more than one material (but I wouldn't expect Maya to allow that either).

Yes. I see what you mean with the numbers now. What happens if you assign a material to each cube after combining them? I would like to see the collada, as that would tell us what is going on, although not necessarily why. The link gives me an error message. "The page /cube_test/ could not be located on this website." Maybe a private directory? Maybe you didn't finish uploading it? PS: did the same in Blender ... 3 cubes objects, different materials, join into one mesh ... and it was 36 triangles, as expected.

Didn't find your files, but if you are combining the three models, why do you expect them not to have three sets of vertices?

Can you make a simple tetrahedron with no materials, then one, then two, ans see whether you see the same effect on triangle count. Then if you do, show us the collada files somewhere. (Strip out any personal identifying information first). It sounds as if you have applied both textures to all the faces. The SL format stores a complete vertex/triangle set for each material. So that would duplicate the whole thing. But I would have expected it to be recognised as an error in the uploader.

"The other option would be to map out the walls on the UV on a grid" If I am understanding correctly ... It's relatively easy to get the alignments right by hand-editing the UV map while watching the textured display (at least in Blender). Of course it then only works for the same texture, unless the maps are aligned to repeat boundaries, in which case it works for anything with same repeat density.

I agree. By exceptional, I meant not included in the category just decribed, not rare. In fact, I go on to say they are common. I will clarify that.

"Soon, the entire Internet will be nothing but Apps. All computers will be interface only, no programming allowed, no serviceable parts inside." :matte-motes-crying: :matte-motes-crying: :matte-motes-crying: :matte-motes-crying: :matte-motes-crying: :matte-motes-crying: