Drongle McMahon

I just tried a couple of meshes with no UV maps, but using the "Planar" mapping (in the Texture tab of the edit dialog). This does do some sort of texturing, although its mapping is very dtrangely distorted. So you could play with that, although I don't think you will get anything cery useful. Using "Default" mapping, which uses the UV map, is more or less random if you have no UV map. (The uploader makes up a nonsense map.)

I think you need to check that. A 0.5m cube gives... Approximate LOD switch distances of: 'Object' Medium LOD distance: 112m Low LOD distance: 28m Lowest LOD distance: 14m How about this... string fmtf1 ( float num) { return (string)((integer)(num*10)/10) + "." + llGetSubString((string)llRound(num*10), -1, -1); }default{ state_entry(){ integer i; list rvlf = [1.125, 2.0, 4.0]; float r = llVecMag(llGetScale())/2; llOwnerSay(llGetObjectName()+": radius "+fmtf1®+"\n"); for (i=0;i<3;++i){ float f = llList2Float(rvlf,i); llOwnerSay("\nRenderVolumeLODFactor: "+ llGetSubString((string)f,0,4)+"\n" + " Medium LOD distance: "+fmtf1(f*r/0.24)+ "m"+"\n" + " Low LOD distance: " +fmtf1(f*r/0.06)+ "m" +"\n" + " Lowest LOD distance: " +fmtf1(f*r/0.03) + "m"+"\n\n"); } llRemoveInventory(llGetScriptName()); }} ETA - cleaned mine a bit too.

Yes. However, your model will have to have a suitable UV map. If you want to use general-purpose textures, like woodgrain or bricks, or whateverm you need to make the UV map in such a way that that will work. The only way to learn that is by using a similar texture, or a grid pattern to see how your UV map works out in Blender. You can see that by selecting the faces it's going to be applied to and then loading the image in the V editor and switching to textured display mode. Then you can olay around with the mapping to learn how it works. Then you will want to learn about defining materials and assigning faces to them. Eacg material becomes an independently textured face in SL. It's difficult to say more withjout knowing what your model is.

What's your triangle count? That sort of thing is one of the possible symptoms of having materials with triangle counts above 21844. However, I have also seen it in other circumstances and was never able to work out what the cause was then.

Yes. Aquila is right. I'll try and explain. The locations of vertices you end up with is a combination of the edit-mode geometry and the object mode transformations (rotate, scale, translate). But the spin (and many other things) work just on the edit-mode geometry. So if you have a scaling along an axis in object mode, then it makes a circle in the edit-mode geometry, but that still gets squashed (or stretched) by the object mode transformation. This problem comes up a lot, and it is probably best to avoid object mode editing as far as you can. If you do use it, remember to keep applying the transformations, which removes them from object mode and applies them to the geometry in edit mode instead. You often need to do that before exporting as well.

"...1024 vertices which is what you're forced to use with a sculpt..." Just to be annoyingly pedantic, this isn't quite true. If you use sculpt maps with dimensions smaller than 64x64, you will get correspondingly less vertices. For example, a 8x8 map will give you just 4x4 quads. I guess not many people know this. It came in along with oblong sculpt maps. However, this doesn't affect you argument. Mesh will always be less strain on the graphics card than the equivalent sculpty with the same visible geometry. Furthermore, if it's well made, it can have better LOD behavior and much better texturing. There are a few cases where the sculpty will give lower LI. Mainly large organic shapes, such as rocks, but if you want to be able to walk on them, then mesh wins for those too.

The best thing would have been to start with a cylinder, then delete three quarters of it. If it was a straight corner edge, you could use bevel to round it, but that doesn't work with undercuts like those you have. So here is a simple example using Spin of which a variation should work for you. 1. Here is the starting point. 2. Make some loop cuts where you need the rounding, and remove the corner vertices. Snap the cursor to the centre of the circular curves (anywhere on Z axis). 3. Select the perimeter you need to rotate. If the vertices sren't lined up in a plane, use SY0 to align them with the central vertex, having lined up the other cut edge using SX0 first. (You need the pivot center set to cursor for these to work.) 4. Go into top view and click the spin button in the tool shelf. Here it was set to eight segments and 90 degrees, duplication off. 5. And that's it.

My guess is thjat you dissovled an edge that was UV seam, leaving the new face spanning across two separate UV islnds. I should have mentioned that. Ideally you need to plan the seams in advance so that you can leave them all there, undissolved in the lower LODs. It's not as difficult as it sound. Just keep the seams at the major edges that are going to be needed at all the LODs. When you can't, or you made a mistake with that, then you can pull the vertices around on the UV map after you add the nes faces, until they are right. That's tricky though. It's easier if you use a good test texture like this.

I strongly advise you to join the objects. Using multiple objects for a single table is likely to give you much too high LI. To join them, just select them all in Object mode, then do Object->Join. Some further basic advice before uploading... 1. In the Properties panel (right of 3D view), Display section, check Backface culling. In SL, only one side of the face is visible. This will let you see where the normals (the way the faces are pointing) are wrong. In Edit mode, you can click the face button under Normals in the Mesh Display section to see the actual normals. If they are wrong, try Mesh->Normals->Recalculate outside. If that doesn't work, select the offending faces and do Mesh->Normals->Flip. 2. Back in object mode, select each object and do Object->Apply->Rotation and scale. This must be done again after any editing in Object mode. 3. When you export, click the Operator Presets button and select Second Life Static. Alternatively, check the needed options explicitly. They are Apply modifiers, Selection only (make sure you selected all the objects first!) and Only active UV layer. With any luck, one of these will solve your problem

I'm not sure I follow exactly what you are doing. The way I do it is thus: (1) make high LOD (2) apply and bake texture - this is the one texture to be applied to all LODs. (3) duplicate for next LOD and remove lots of geometry using dissolve where possible - texture should remain correct - adjust UV map manually if needed. DO NOT BAKE AGAIN. (4) repeat step 3 for low and again for lowest LODs. There are variations, such as making the but this is the main process. The point is that you only make one baked texture, using the high LOD mesh. Then the UV maps of the lower LODs have to fit that. You shouldn't have to re-uv map the lower LODs at all, but you might have to if you use some destructive editing to reduce geometry. If you do have to, I believe you can "Pin" the vertices that are in the right places first, so that they don't move. Make sure the correct texture image is selected before you remap. The (equivalent parts of the) meshes at all LODs MUST be using the same material because they will use the same texture in SL. When done, select each LOD model in turn and export it with "Export selected" checked, as xxxx_hi, xxxx_med, etc. I keep all the LODs on the same layer, just moving them apart in object mode (object mode translation is ignored by the uploader). Others prefer to keep them on separate layers.

Most often you can use the same texture for the LOD meshes. You just have to use UV-map-conserving edits when you reduce geometry for lower LODs - Dissolve is your friend there, and some others. It's best to avoid using different textures for two reasons. First, performance will suffer from using extra textures. Second, you have to have all the textures on at least one triangle in every LOD. You can use hidden triangles at the LODs where a texture isn't used, but you are still using four of your eight available slots for each SL face, limiting you to two. The extra triangles may also significantly raise the LI in certain cases. It is the case that some textures, especially baked normal maps, aren't going to be exactly right when they are applied to the simpler geometry at lower LODs, but that's usually at least as acceptable as the geometry reduction itself. On the other hand, using an alpha texture on a simple plane or box at the lowest LOD is often the best way to get low LI, for things like windows, railings and slatted chair backs. In that case, you have to have use the hidden triangle trick, but you only have one extra texture. So it's less wasteful than using a different texture at every LOD.

I'm happy it solved your problem. Trhis case, where you use one map to texture and another to bake to, is probably the main one where this comes up. I think it should be regarded as a bug in the exporter, because it causes bad references in the collada when the active UV map option is checked and the selected one is not top of the list. It's useful to have your example showing it's a real problem. I hope we may see a fix before too long.

Yes. In fact there are separate caches for each account (C:\Users\Me\Appdata\Roaming\Secondlife\account\cach\.....), but that's not for textures (a lot of javascript - what on earth is that for?). The textures appear to be in a shared cache (C:\Users\Me\Appdata\Local\Secondlife\texturecache\....). However, if you use different computer accounts for each avatar, then I guess there would be separate texture caches, as the latter is still User specific (no SL stuff under default user's appdata). That's unlikely though. I can see a purpose - if the accounts live in different places, then they would each like to have a different set of textures ready in the cache to avoid grey stuff when they login because the other account overwrote them. Hardly worth it though, because it would also mean a lot of wasteful duplication.

I believe different accounts each have their own cache. Someone will confirm or refute.

Maybe you are getting the wrong UV map in the upload? If your blender object has multiple UV maps, you need to make sure the right ione gets uploaded. There is a blender export option "Only active UV layer, but it doesn't work properly. I quote my reply from an earlier thread..... What Blender are you using? I am still using 2.66, where the "Only Active UV Layer" doesn't work unless you have the first UV map in the (i.e. Blender's) list selected. This is because it tells the <polylist> tags (In the dae file) to use the selected map, but still only exports the first. That leaves the reference in the <polylist> pointing to a map that isn't there. That produces the know effect of a garbled random UV map.... If you have the multi-material map* first in the list and have it selected when you export, this will work ok even in 2.66. If you turn the "Only Active UV Layer" option off, the collada does contain both (or more) UV maps, so that the references do now point to something valid, but the <polylist> now refers to both. SL doesn't know which one to use, so it selects (I think, for two at least) the laast one. This will not work as you expect unless that's the one you wanted. (if it's the wrong one, it will give you the wrong mapping). *yours is not multimaterial, but the same applies.

What are the triangle and vertex counts in the uploader for the models with and without the "multi faced material"?

Or maybe just bury most of them inside the handset?

But I don't think you will see very clearly through a chunky lens like that! :matte-motes-wink-tongue:

Just a couple of notes on LeprKhaun's very complete post... "I'll have the uploader Analyze but not Simplify my physics model (some prefer to skip the analyze bit)." It may be useful to understand the distinction here. If you don't "Analyze", you will have a triangle-based physics shape. That is to say, the physics engine will see the object a the collection of triangles that make up the physics mesh. If you do Analyze, the uploader will generate a set of convex hulls (solids with no indetations) to represent the shape. It is usually more efficient for the physics engine that way. There are two big differences in the bahavior of these type of physics shape. First, the Analyzed shape has a constant physics weight independent of the size of the object, but the triangle-based shape's weight is very dependent on size. The physics engine hates small, narrow triangles. So the weight increases markedly as the object gets smaller. The result is that triangle based shapes are never a good idea for small and medium sized objects. However, for large objects, such as large buildings and walkable lanscapes, the triangle based shape may have a lower physics weight than the functionally equivalent Analyzed shape. However, and secondly, the physics engine knows that the convex hulls of the Analyzed shape are solid. So if you get inside one, it will gently nudge you back out. This is not true for the insides of parts of a triangle based shape, So if you get stuck inside one of these, for example, inside a wall, then you are stuck. (Actually it's usually easy to get out by sitting on something out there, but not always). ""I'll make note of the numbers across the bottom before I upload, checking to see ... The physics shape you have specified is only used when you set the physics shape type to "Prim" in the features tab of the edit dialog inworld. Until you do that, a default physics shape is used. This is a single convex hull made for the whole mesh (as opposed to the multiple hulls made by "Analyze"). This is what gets used with the default physics shape type of "Convex hull". If you specified a physics mesh, it will be the convex hull of that mesh. If you didn't, it will be the convex hull of the low LOD mesh*, and there will be no "Prim" type option. Unfortunately, the physics weight shown at the bottom of the uploader is the weight of the default convex hull, and can be very different from the weight you will see when you switch to type "Prim". So sometimes, although you checked that weight, it may jump to a vale higher than the download weight when you switch to type "Prim". That is just one of the reasons to always test you mesh on the beta grid, as LepreKhaun suggested. One other thing to remember when making your extra meshes, LOD and physics, is that they will get stretched so that their bounding box fits that of the high LOD mesh. So it is important to make sure they have the same bouding box if you want them to fit properly. Finally, if you want to upload multiple objects together, with physics mesh, you need to have a physics mesh for each of the high LOD objects. If you only supply one mesh, it will be squeezed to fit just the first object. If you stick to a naming scheme like LepreKhaun's, you should have no trouble with getting the right physics associated with the right LOD mesh (using Blender and the "Sort by object name" export option). All that applies to the lower LOD meshes too. *This has caused consternation to people who use a single triangle as low LOD to get a low LI and then wonder why their physics is just a triangle. PS - L's advice not to use "Simplify" is also very right. Simplify is a bag or worms, especially if you are making something hollow with openings. If the physics weight is too high because the number of hulls is to large, or they have too many vertices, simplify the physics mesh yourself instead.

That still looks like flipped normals. With so many intercrossing surfaces as at the hinges here, the recalculate doesn't always get it right. You need to select just those faces that are wrong and flip their normals. There's no real problem exporting separate objects. Just select them all and export as normal. You should end up with a linkset. If some objects are too small (0.01m) thery will get stretched by the uploader. So those should not be separate objects. The problems start with LODs. If you use auto-LODs, the uploader may decimate the objects unevenly, which can cause a mess. If you makr your own LOD meshes (recommended) then you have to use an alphabetical naming scheme for the objects in Blender, so that they are i the same order for eac LOD. Then make sure the "Sort by object name" option is checked when you export (the SL presets should do that). Without that, the lower LOD objects may get jumbled and used for the wrong high LOD parts.

Did you apply it, as opposed to just adding it? You apply permanently by clicking the "Apply" button in the modifier stack and the modifier panel disappears. Or you can apply just for export, without affecting the original, by checking "Apply modifiers" in the Export Collada panel.If you don't do either of these, it will ignore the modifier and just export the half frame.

"it DOES require basic SQL syntax skills" Has to be indirected too. Something made by A, who did accept the ToS using a texture and/or animation and/or sound and/or sculpt map and/or mesh (and/or script?) that was obtained inside SL from B, who didn't accept the ToS.

Arton: "There is also a strange issue with certain meshes, which will switch to lower LODs ealier than others." Drongle: Was that never fixed? I can't see the jira - it was removed from the public list (link->"forbidden"!). I'll ask at the cc/mesh group. Arton: I doubt it's fixed. I have to admit though, I haven't tested it by myself. I asked - it isn't fixed. Or, at least, the internal jira is still open with no fix mentioned.

"For the life of me, I'm not able to find a way that Linden Lab CAN break the terms of the ToS." What about content that was made by people who have not accepted the new ToS? As long as they can exclude that, you may be right, but can they? Whoops - out of context. Sorry.

"can I still get away with having nothing set for the lowest LOD." Well, taking the 1m cube, at 32m, beyond which the lowest LOD gets seen at rvlf=1.125, , it's 14 pixels square on my monitor. The way the calculation works, it will be at that pixel size whatever the size of the object. That's quite visible. So I would rather use a cube. At least that looks more or less the same from all directions, while a single triangle (you can't actually get zero) will look different depending on the angle, invisible from half of them. Of course it all sepends on what else is around, what the texture is etc. These affect how visible it will be. So there isn't a recipe that will work for all environments.