Drongle McMahon

"Probably FBX" Ugh! Isn't that a format with no public specification? That's surely a recipe for problems. We would need a precise definition of the way data is read by SL if Gaia and Co. are going to try to ensure compatability, and if we are going to be able to diagnose problems. I'd hate to try to work that out without source code! I suppose it just depends what the chosen engine wants though.

"I want my existing Inventory to be obsolete" Yes. Assuming mesh upload will still be there (which I don't, necessarily) ... 1. Limts/costs need to apply to attachments. 2. Texture/material load needs to be costed. 3. The one-triangle-at all lower lods trick has to be excluded. 4. Compositing of lo-res ao/light maps with small tiled textures should be possible*. 5. Reuse (instancing) of textures/materials needs to be rewarded. * Unless realtime shadows and ao become so efficient and effective that everyone uses them.

"new ways to create that hasn't been done before" :matte-motes-shocked: Ah! Now there's something to tickle even the most jaded imagination!

I think it should really be flagged up as an error by the uploader, especially as it can cost people L$ if they aren't on Aditi. I just vput bin a jira feature request for that.

My guess: I don't know C4D, but if those things at the bottom are materials on this mesh, then you have more than eight. Uploaded mesh can only have eight materials, and any geometry which has the 9th or greater is simply excluded from the upload.

It's easier to see this sort of problem if you turn on "backface culling" in the Blender 3D view. That makes the rendering one-sided, as it is in SL. You can do that in the "Display" section of the properties panel on the right of the 3D view.

"the UV maps collapses into a dot in the bottom left corner" That's what you get when no UV mapping has been applied. All the vertices are mapped to coordinates 0,0. Even before the change to name matchng, if you combined two meshes with different numbers of UV maps, in one of them the mesh with fewer maps will never have been mapped, and all it's vertices will consequently be 0,0. With the name matching, I suppose the same thing still happens - wherever a mesh had no map with the name of one from the other mesh, all it's vertices will be 0,0 in the combined map. There is no need to have different UV maps for different materials. In fact, it is not a good idea for SL import because SL will only ever use one map, even if there are more in the collada file. So you need to have all the materials included in one UV map. Unless you are baking all materials into a single texture for SL, you can select by material to map each separately to the same UV map. That way, the whole UV space will get used for each material (by default) and the material maps will overlap, but that doesn't matter because they are going to be textured separately. To bake, just use a new image in the UV panel after selecting each material, then bake. You don't need a new UV map. The important thing here is to keep in mind a clear distinction between the UV map and the baked images. They are not the same thing. They are independent. On image can be used at the same time with different UV maps, and one UV map can be used at the same time with different images.

"It MAY be that you use the Linden viewer?" Of course. As far as I am concerned, the official viewer is the default viewer, and so the default settings are those that come with it. This is an LL forum, not a Firestorm forum. If information is specific for a particular third-party viewer, then perhaps that should be indicated. I've added a signature to avoid further confusion.

"...with the default LOD of 2..." Chic, the default LOD (RenderVolumeLODFactor) is 1.125, except for ultra graphics settings, where it is 2. (see the "xxx_graphics.xml files in app_settings subfolder of viewer install directory). I've no idea how many people leave it there though. The maximum you can set it to with the object detail slider is also 2. Maybe that's what you were referring to?

1. Your object is a curve, not a mesh. You need to use Object->Convert to->Mesh from curve... 2. It has far too many triangles. If you try to import it it will have enormous LI and will have holes in (see this jira). After conversion you will have to do a lot of loop removal or decimation to arrive at a mesh with a reasonable LI.

Meanwhile, try changing the "Stitching type" with the drop-down selector below the sculpt map in the edit dialog.

"...to allow you do add a seamless texture that can be changed..." I shouldn't pre-empt, but... True, but the main advantage is that it allows you to use a low resolution AO with a small tiled texture, because the blurring of the AO dioesn't matter. So for a wall with a repetitive wallpaper, you might have to use a 1024x1024 for a single combined baked texture, but a 256x256 AO with a tiled 256x256 underneath. That's 1/8th the total texture size. Drop them down to 128x128 and it's 1/32. You can also increase the repeats of the tiled texture to get higher detail than with the 1024x1024 without changing the AO. Furthermore, the tiled texture can be re-used for other walls with only the AO overlay changing. For simple walls, the overlay is only 2 triangles. So the extra geometry will often be a small proportion of the total.

Generally, the geometry of sketchup models is not suitable for use in SL. They tend to be fragmented into large numbers of small meshes, often with inefficient triangulation, excessive numbers of materials and poor UV mapping that has to be redone when the meshes are joined. A great deal of editing in Blender would be usually be required to make good models optimised for SL. If you know sketchup but not Blender, working on your sketchuip models in Blender could be a way to learn Blender. That way you will soon get to the point where you can more easily just use your sketchup models as a template, then build from scratch in Blender. Nevertheless, I would still recommend learning Blender from scratch, using the huge variety of video tutorials that are available. In principle, you should be able to import a collada (dae) file from sketchup directly into Blender, but it doesn't always work. (I have seen sketchup-generated dae files that crash Blender instantly as soon as you try to import them.)

As all the weights are now calculated by the server (although the old code is still in the viewer), we don't really know whether anything has changed. So my old size-dowload weight stuff may not be completely accurate. However, there is one scenario where this behavior is expected ... for a LI that is based on a triangle-based (not analyzed) physics shape. That weight will increase as you shrink the mesh, until you reach a minimum size where it secretly switches to convex hull. Then it will suddenly decrease, perhaps becoming the download weight instead. The threshold size for the switch seems either to have been changed a few times, or to be dependent on the details of the mesh/prim. I just tried with a tortured torus and it was 0.2m. Foe mesh, last time I tested, it was 0.5m. In the ealy days of mesh I think it was 0.1m.

If the movements changed the diagonal of the high LOD bounding box (the "radius" of the mesh), that would affect the download weight. Otherwise, if it's compressibility effects, I think they are generally unpredictable other than in a special case like lots of identical numbers. Since the viewer does the compression, the secrets should be there in the viewer source code, but I think they would be too hard for me to find.

That sounds odd. I always use triangles! Have you looked at the uploader triangle and vertex counts to see if there has been an unexpected invrease? Is it definately the download weight that's setting the LI? Is your triangle/quad detaced or attached to the rest of the mesh? Can you reproduce the effect on a very simple model? As far as I know, the download weight is still calculated from the mesh data size after compression. I suppose it's possible that the compression might sometimes work a bit less well, for some obscure reason, after removal of a triangle, and that could result in an anomalous change like that. I just checked with a completely flat subdivided plane (all normmals equal) and a curved one with otherwise the same goemetry and uv map. The download weights were 1.168 and 2.575, even though the curved one had slightly less triangles in the auto-generated LODs. I think this conforms that the loer download weight of the flat one is due to greater compressibility because of the identical normals (note that there is no indexing of normals in the upload format - each vertex has it's own normal whether they are identical or not). So unexplained differences in compressibility could cause unexpected differences in download weights.

Whoops! Here's another one. Probably a similar underlying cause .... ignoring small triangles when making te caps (top and bottom of the cube). The one on the left has pathcut 0.010; on the right 0.011. Arrgghhhh!

Jira BUG-6160 done.

Try "Bibliophiles" :matte-motes-smile:

You haven't said anything about the size of your object. The download weight, which is dertermining your LI, is very dependent on the size of the rezzed object. If it's very big, then the lowest LOD becomes irrelevant, and so on*. If it isn't scaled properly in Blender, you can scale it on the options tab, where it will tell you the final dimensions. *There is more detail, possibly too much, about this in this old thread.

Ah. Got the normals display to work by changing dimensions. Here you can see that the normals are completely flipped at the settings where the shading goes wrong, but just on the bottom face (which we are looking at here).

On more thing ... your physics shape is presently triangle-based. That means you didn't click "Analyse". Triangle based shapes are bad for small objects. Their physics weight increases the smaller they are. If you click "Analyze" (afyer you have joined the meshes!) that should give you a physics weight of 0.36. As it stands, each separate blender object is getting its own physics shape. For the stems, those will be expensive hulls, and they all add up. Each is then stretched/dqueezed to fit the bounding box of the corresponding visible object. That's why your provided shape is being squeezed to fit the vase object, and why joining them solves that problem.

OK. I got it now. It's on the bottom side. I'm sure it's the same bug now. Here is a picture with a local light to emphasise the effect. The lighting is correct up to B=0.495, then wrong (dark) at 0.496 to 0.499. Then it's right again at B=0.500. This is exactly the same range (veretex pos -0.04 to veretex pt -0.01) as with the effect described in the jira. The wireframes below show the small triangles at these B settings. I can't see the effect on the normals with the normals display, as that doesn't want to show the normals for the relevant face at all. So it looks like it's the same calculation error that happens when some limit is reached. This is simpler than the dimple case and should make it easier to find. I will make another jira after seeing if I can find it in the source code.

Reminds me of MATBUG-228, which says there's a fix, but which is still present in latest official viewer. However, I can't reproduce the effect on a cube from your description. In fact the original bug happens whenever the dimple (for sphere) or the profile cut (for torus) is just approaching the location of a vertex where it intersects the profile (within 0.003 before it hits the vertex). So it's something going wrong with the normal calculation when the gap gets very small. I don't think cuts of a box work the same way, in which case it can't be exactly the same thing.

As Arton said, you need the edges around the cylinder caps to be sharp, while the edges prallel with the cylinder length have to be smooth. You might be able to achieve this by playing with the "Generate normals" and the associated crease angle in the uploader, although that is a blunt instrument. Better would be to use the facility in your mesh program. In Blender, you can use the edge-split modifier, with edges explicitly marked as sharp (rather than using the angle setting), while the rest of the mesh stays smooth shaded. Even simpler, you can just select the edges and split them (Ctrl+E,D; or Mesh->Edges->Edge Split). Be careful though not to apply a subsurf modifier after splitting either way - that will open up gaps between the split edges. In other software, I think you have to use smoothing groups. I am not familiar with those, so someone else would have to tell you how.