Drongle McMahon

http://wiki.secondlife.com/wiki/LlSetTextureAnim

Yes, as hibit says. These trees are mesh, and the texture on them is animated, but the surface you are looking at does not move. The texture moves over it. That is also doable with animated textures on legacy prims. You can see another application animated normal maps for water that appears to ripple. (That might make a nice addition to those trees, making the leaves look as if they were individually rotating too). The second method I mentioned can use texture animation in a different way, using transparency to make different parts of the mesh visible. Strictly speaking, this is not really animated mesh either. The mesh is static, but the changing of the parts you can see produces the illusion of real movement of the mesh itself.

Don't know. That would happen if you were using local textures and forgot to go back to normal ones. It might also have something to do with permissions, I suppose.

The idea is that you develop on Aditi, then pay the upload fee just once on the main grid when you are satisfied. Now you seem to be saying you could get an object onto the marketplace from Aditi. Is that right? Did you get charged the upload fee on the main grid when you did that? Or does that provide a way of getting stuff onto the main grid without the upload feee? I can't believe that could be possible.

Unfortunately, you can't do either. Flexibility, which allows response to the wind, is only applicable to legacy prims. The only bone animation possible is by rigging mesh attachments to the predefined avatar bones (ordinary and collision). There is no provision for uploading arbitrary bones. Morph tasrgets are also unavailable. The only practical ways to animate unattached mesh objects (as far as I know) are by scripted movement of whole mesh objects or by manipulating the visibility of alternative sets of faces (that is mesh faces, not SL faces) in a single mesh by animating or changing textures. You could concievably use an avatar bot wearing the tree as a rigged attachment, with some appropriate animation via the avatar skeleton, but that would not be very practical, especially if you want lots of trees.

http://wiki.secondlife.com/wiki/User:Rolig_Loon/Local_Textures

I guess that's like the solidify modifier in Blender. Using that, the default is to fill in along the gap at the boundaries of the layers with new faces. That will waste geometry even if the opposing faces are very close. There is an option to turn it off in Blender. So I expect you can in 3Ds too.

All mesh surfaces are one-sided in SL. You cannot turn on texturing on the back face. To achieve what you want, your leaves must have two planes, one facing each way. You can make this by duplicating and flipping the normals, or just by extruding them and folding them over. If you need to make the texture lined up on both sides, you may have to play with mirroring the UVmaps too.

Please re-read my explanation in point 3.... Your dae file has five UV maps and SL is using the wrong one. You have to have only one UV map in the file. Do not confuse UV maps with images/textures. The UV map is just a list of which points in the texture(s) are applied to each mesh vertex. You can have up to eight different textures apllied, each as a different material, using the single permitted UV map. You cannot use multiple UV maps. As it is, SL is using the fifth UV map, which only has the top right frame in it. So all the texture is appearing there and the rest remains untextured. You need to delete the extra UV maps. Someone familiar with Maya should be able to tell you how to do that. Also, your one UV map that does include the whole mesh uses too small an area for each picture to give satisfactory rendering. Now I am guessing, but I imagine the other four UV maps, with much larger areas for the pictures and 2048x2048 are those used to apply the images in Maya, whereas the other map is being used to bake them out to the final texture. Then the baking is where the low resolution effects happen. So I assume the 3Ds import is using that baked texture. Since 3Ds can use 2048x2048, it will be even worse in SL where the resolution will be halved again. To get good image resolution, you will need to use a material for each image, which becomes a separate face in SL, and UV map each to the full extents of the the UV map. Then you can simply upload the images and apply them in SL. I would recommend avoiding uploading any textures/images with the mesh. That means you pay the combined fees every time you change either geometry or texture, and it leads to proliferation of copies of your textures hidden away in inventory. The only problem with using separately uploaded textures is in applying them to hidden surfaces (used for special LOD techniques), and there are workarounds for that.

Where to start??? 1. The dae file won't import into Blender as it is. Inspection revealed a large <library_animations> section which should not be there, and a whole lot of empty (ie they have no geometry and show up as empty objects in Blender) nodes in the <visual_scene> that were referenced in the animations section. So first thing - get rid of animations (oir whatever in Maya/3DsMax is being exported in that way). 2. Removing those was not enough. There's something in <library_effects> or <library_materials> that also causes an import error. So I removed those sections too. (I guess the SL importer skips over any problems with these). 3. Now we have a geometry that will import into Blender without all those empties. However, it has five UV maps. These appear to be (in order in the Blender list) the one you want, then one you must have made for each separate frame. Unfortunately, the SL importer can only use a single UV map, and if there are multiple maps in the file, it uses the last (strangely). So that is why it is using the wrong UV map, with the results you describe. You need to remove all but the correct UV map. 4. Your texture is 2048x2048, but the maximum for SL import is 1024x1024. It will get reduced to this by the uploader. It is essential to use the available image area as completely as possible in order to maximise pixel reolution where it is important. You can see the effects when you transfer from Maya to 3DsMax. Maya is not using the generated image to texture its display. It is using the original images. In 3DsMax, it is using the generated image. Because only a small part of the UV map (and image) is allocated to the pictures, they have very low resolutions. The blurring is the attemp of 3DsMax to smooth out the resulting pixellation which, nevertheless, remains visible. 5. The geometry of the frames is very far from optimal, and they use very many more triangles that they should. On top of that, it looks as if you have used a planar UV projection. This will work for the images, but will not provide texturing on some parts of the frames. What you need to do... 1. If you want the highest resolution of the images, make each into a separate material (someone who knows Maya can explain how). That allows you to use up to the full 1024x1024 pixels for each image (although you should be aware that multiple large textures will contribute to lag). The frames account for much less area and do not need as high resolution. So they can be combined in a fifth material using a small texture. You could use a sixth material for the backs if they are going to show (otherwise they can be omitted). 2. This does NOT mean the images/frame have different UV maps. They still share the same map, but the areas they occupy can overlap because they are using different textures. Each image can occupy the whole 1024x1024. If the frames are identically textured, those parts that are going to share the same texture can also be overlapped, greatly reducing the texture area required for a given texture resolution. 3. If you want full texturing of the frames, you will have to do some kind of unwrapping so that all surfaces receive finite texture area. If they are just flat colours, this may not matter. Here's a picture to explain my comment about geometry. At the back is one of your frames, 196 triangles. At the front is the same effective geometry in 44 triangles. This will not only save gpu cycles, it will also make the UV mapping cleaner and easier to understand.

What is the triangle count in the uploader dialog? I am guessing it may be high if you are using ZBrush. You can get strange effects if it is higher than 21844. If the dae file has more than 174752, the count will stay at that and the extra triangles will be lost. (Some more detail here).

Diffiicult to think of an explanation without more information. Can you put the dae file somewhere we can look at it?

I'm confused too. Why join high-low LODS. They have to be separate objects both for baking high LOD detail to low LOD and for uploading to SL. Anyway, it sounds to me as if you are confusing materials and UV maps. They are not the same things and lead separate existences. A material may use a UV map to apply itself to the mesh, but that is the end of the relationship.

Properties window, Obeject data tab (triangle icon), UV Maps section: Select the map in the list and rename it in the name edit box. Remember - a UV map is not an image. Its data can be represented as an image, and it can by used to fit an image onto the mapped surface, but it is not itself an image. It is just a list of 2D coordinates associated with each of the 3D vertices of an object (in SL - elsewhere it can be a bit more).

Hmm. More like post-hoc justification than reasoning? It's quite an imposition to expect people to name maps in such a way that they will join as expected with as yet unknown other items. However, joining by index is probably even more unpredictable, and since you can't change the idexes, can be much worse because there's no way out. I think the robust solution would be to no join them at all; use the numeric postfix convention as elsewhere to deal with duplicate names, then allow explicit joining. Then an optional join-by-name setting could be added for those whose workflow would benefit. Still, at least the solution is clear. Check the names before you join to get what you need at the end. If both mesh have just the default map name (as mine nearly always do) then the behavior is unchanged.

Does anyone know why this was changed? It seems to me that to destroy a UV map without reason, when you could always keep it somehow, should never be a good idea. Maybe there's a sensible reason, or maybe it's a bug. What do you think?

Yes. From your answers, I would have suggested all the faces of the bad material were squashed to a point in the UV map. This can happen, for example, when you add geomatry after mapping, or when you use some projections.

Can you select the relevant "face" inworld and change its colour from the edit dialog? Does it stll not change if you apply a completely black texture? Have you tried applying the texture with a script, trying face numbers 1-8?

A couple of things that might help you down the road... 1. Maximum texture size in SL is 1024x1024. If you present the uploader with a larger texture, it will be scaked down. So you will end up with less resolution than you expected. Also, images are always scaled to dimensions that are exact powers of two. So you should use baked images of those sizes to avoid possible loss of detail on scaling. 2. You can use up to 8 materials for a single mesh in SL. Now each of those can have its UV map fill up the whole UV space, instead of having them all non-overlapping. That way you can get more pixels/m on the final textured object, and thus better texture detail. The cost is that you have to upload a texture for each material, with the extra cost that incurs. Also, the more textures you use, the more download and rendering resource you use (=lag). You need to bake each material separately for this, to a new image created while just that material is selected. 3. You have rounded walls etc, here, but they are segmented with sharp edges. Assuming you would rather have them smooth, you should set the shading to smooth (Mesh->Faces->Shade smooth). Then you can add an edge-split modifier to make some of the edhes sharp, according to face angles and/or by explicitly marking them as sharp. The smooth shading of most of the mesh will also reduce the download weight (and thus probably the LI). (That is because the vertices along sharp edges have to be duplicated in the uploaded data so that they appear wil two different normals.)

Good, especially imcluding the samples setting. Default is grainy. I usually use higher falloffs than that, up to 20 for small objects, but then I like rather subtle AO.

Are you using Blender? If so, click the globe (world) symbol on the properties panel. Turn on AO (I guess you already did). Then find the "Gather" section. This has two settings that determine how far away surfaces do(not) cause AO shadowing. They are the Attenuation: Distance - surfaces further away have no effect - and Attenuation:Falloff - how fast the effects lessen as surfaces get further away. If you play with those, you should be able to find settings that prevent the darkenning of the inside withouit losing the needed AO.Also, always turn on the "Normalize" option in the "Bake" section of the Render (camera icon) tab. Otherwise you will likely get AO that is too dark overall. If you like excessive AO, as most people seem to with buildings, you might need to do a separate bake for inside and outside, using the appropriate parts of the two images combined in a final AO texture. You can also use a function like "Color->Curves" in Gimp to adjust the AO selectively in different parts of the image. Don't forget that SL advanced lighting model includes some (quite faint) AO. Although probably only a minority have it turned on, the AO you use gets superimposed on that for those that do.

http://blenderartists.org/forum/showthread.php?251710-SLOVAK-CZECH-Blender-community-new-Facebook-Page http://grafika.sk/clanky/kat-22/

"Aha a ten blender kde sa dá asi stiahnuť" http://www.blender.org/download/

Materials are now sorted by name during upload, and Gaia had the option to export objects in alphabetical order added to the Blender exporter. So I think the ordering problems can now be avoided without requiring manual editing of the dae file.

I can see that causing some problems - have to make sure maps you want combined have the same names before joining (if I understand correctly). It would be nice to have the abilities (a) to move items up and down in the list and (b) to combine selected map with the one below. Maybe we should ask the developers for that?