Masami Kuramoto

Probably the most straightforward way to get an overview of Blender's datablock hierarchy is by looking at the outliner window. By default it shows a simplified view with the scene datablock as the root element. If you expand a scene node, you'll see objects at the first level, then assets (meshes, lamps, cameras etc.), then materials, then textures, and finally images. To get a complete overview of the currently loaded .blend file, switch to display mode "Datablocks". At the top level you will see several tables, one per asset type. These tables contain, in a flat layout and sorted by name, all the major datablocks that occur in the current project: all the scenes, all the meshes, all the cameras, all the lamps, all the materials etc. To explore the relationship between those datablocks, expand their corresponding nodes in the outliner window. For example, each "Scene" has a collection of "Objects". Each "Object" has a "Data" link to a mesh or a lamp or a camera etc. Each "Mesh" has collections of "Vertices", "Polygons", "Materials" etc. Each "Material" has a table of "Textures" etc. Any of those top-level datablocks can be shared by multiple others in a parent-child relationship. Materials can be shared between meshes, which can be shared between objects, which can be shared between scenes. Whenever a datablock is shared and appears at multiple places in the datablock hierarchy, it is called a "linked duplicate" in Blender terms. The parents of a linked duplicate are not necessarily the same type of datablock. For example, materials can be shared by any type of renderable asset: meshes, curves, metaballs etc. If you expand a "Mesh" node, you'll find an entry called "UV Maps". As the name suggests, this is where UV maps appear if the mesh has been unwrapped. Inside a UV map datablock there is a "Data" entry containing a list of UV map faces. Be careful when expanding the "Data" node because a complex mesh will produce thousands of UV map face nodes in the outliner window, which may freeze the UI for quite some time. Choose something simple here, e.g. an unwrapped cube. If you inspect any of those UV map faces, you'll see an entry called "Image". This explains how images can become linked duplicates at both ends of a bake operation.

Pamela Galli wrote: I have no idea why it was baking to the brick texture, which it occurs to me might mean that the brick is a source texture? Or something. It was both the source and the target at the same time. You loaded herringbone_red_brick_tiled_small.bmp into the image datablock "hardwood", possibly overwriting some wood texture that was loaded there previously. You linked that image datablock "hardwood" to the texture datablock "Brick.003" to use it as a source for baking. And you linked "hardwood" to the UV map that you used as a bake target. By default, the first step in a bake operation is to clear the target image. This is what caused the "hardwood" image to turn black. Then the bake proceeded, transferring black pixels from Brick.003-->hardwood to UVMap-->hardwood.

Spinell wrote: I found out that if I re-locate the origin of the cirve to another point on the curve itself, the array on the mesh works much better, but it doesn't work all the time. This certainly has to do with locations and ritations, but I haven't found a sure, full-proff solution to this problem. This one is guaranteed to work: Make sure you are in object mode. Select the mesh object. Choose Object --> Transform --> Origin to Geometry. Choose Object --> Apply --> Rotation. Select the curve object. Choose Object --> Transform --> Origin to Geometry. Choose Object --> Apply --> Rotation. Make sure that the properties panel is visible. (Shortcut: N) Select the mesh object. Shift-select the curve object. Right-click the transform location field in the properties panel and choose Copy to Selected. This will move the mesh to the center of the curve. Select the mesh object. Make sure that the array grows along the curve deformation axis. For example, if the deformation axis of the curve modifier is X, then the Y and Z offsets in the array modifier should be zero. (This is the default configuration when you add the modifiers.) If you want to modify the array elements on the curve, perform those modifications in edit mode. If you move or rotate the mesh in object mode relative to the curve, the array will no longer be aligned to the curve. To get a proper preview in edit mode, enable "Use modifier while in edit mode" on the curve modifier.

Things that could be wrong: Mesh and curve don't share the same location. Mesh and curve don't share the same rotation. The offset vector in the array modifier is not parallel to the deformation axis of the curve modifier.

By the way, there is something else that may be useful if you work with colour-coded textures: Blender maintains two separate material lists, one per mesh ("Data") and one per mesh instance ("Object"). You can, for example, populate the "Data" slots with colour-coded materials, and the "Object" slots with the materials that you actually want to bake. If you create linked copies of the mesh object later (via Alt-D), you can re-assign the "Object" slots without without affecting the other instances, or change the colour coding for all instances at once by re-assigning the "Data" slots.

Drongle McMahon wrote: I never understand when Blender decides to display what images in the uv edit window, and consequently can never control it The image displayed is the one linked to the active face (i.e. the face with the pixel dot pattern).

When you bake textures from one UV map to another, you have to select one as the source and another as the target.

Face textures are an unusual workflow feature that is specific to Blender. It's a quick way to assign one or more diffuse maps to all or parts of a mesh. Face textures serve as bake targets, and since they are independent of materials, they can be used to bake complex material assignments into a global texture atlas or several of those. However, it is also possible to use face textures as a source for baking (instead of materials). For example, you can have one UV map linking to multiple small images serving as texture tiles, and another UV map linked to a large image serving as a bake target. As long as you are only dealing with diffuse maps, this is sufficient and allows you to get results without setting up any materials at all. However, it's easy to make mistakes there, such as flipping source and target UV maps, and then the bake will go in the opposite direction and overwrite the texture tiles with content taken from the target image. Good luck figuring out what happened if the target already contained a half-successful previous bake. That's why I would recommend using face textures only as targets, and only materials as sources. And as soon as a bake is successful, the result image should be unlinked, saved, and inserted into a material, where it is read-only and cannot be overwritten by accident.

Drongle McMahon wrote: If you could write a clear guide to handling and manipulating image-mesh association, I would be for ever grateful. :matte-motes-big-grin: I would simply recommend to link face textures only temporarily, unlink them as soon as baking is done, and use proper materials for everything else.

What Kwakkelde said. The thin lines in your UV map are faces projected from the side. Their UV area size is zero, so they will neither bake nor render properly. Also remember that linking and unlinking apply only to faces selected in the 3D view. The linkage of unselected faces will not change. This way it is possible to link parts of the mesh to different images. However, since the UV/image editor can display only one image at a time, there is poor visual feedback in case of multiple selected faces with mixed linkage, and it's easy to get confused or change links by accident. Use "Select --> Similar --> Image" (Shift-G) to find all faces that link to the same image. This makes unlinking and re-linking a lot easier.

Fluffy Sharkfin wrote: So basically what you're suggesting is that, because you can use sculpted prims and the legacy prim accounting system to cheat on land impact, LL should make it possible for us to do the same with mesh? No. It's obvious that LL aren't going to break existing content (considering the animosity that the introduction of mesh already caused with some residents doing so would have been suicide). There are ways to phase out the legacy prim accounting system without breaking existing content. The implementation details depend on how we define "existing". For example, the new accounting system could be applied to every sculpted prim created after day X. Or copied after day X. Or transferred after day X. Or rezzed after day X. Existing sculpties (let's call them "legacy prims") would continue using the old accounting system until they get switched over to the new one. There should be a function to activate the new accounting for every sculpted prim in a linkset that you own (regardless of modification permissions). Linden Lab could introduce a land impact bonus for private regions without legacy prims. To unlock the bonus, all legacy prims have to be removed from the region or switched over to the new accounting. After unlocking the bonus, legacy prims get switched over automatically when rezzed in that region. And finally, psychological warfare: Linden Lab could introduce a viewer setting to toggle legacy prim rendering, turn it off by default, and hide the switch in the debug settings menu. Remember how people avoided mesh while there was a significant chance that it wouldn't be rendered properly? Let's use the same trick to make them avoid legacy prims. The general idea is to provide an incentive to use mesh instead of sculpted prims, so that people stop producing even more unoptimized legacy content.

You can use such a tiling UV layout as a source for baking, but not as a target. The target UV map needs to be a separate one, with all the faces inside the image area and not overlapping. And of course there must be a separate image assigned to it. Otherwise the bake will overwrite parts of itself and produce all kinds of weird results. I didn't know you were about to bake the tiles rather than use them in SL directly. In cases like this, the aforementioned material textures and their standard mapping options (cube, cylinder, sphere) would probably save you a lot of time unwrapping and aligning.

Drongle McMahon wrote: The OPs question was whether meshes are "just a hoax with no use". No. Can we please stop treating the OP like an idiot and reducing his criticism to a one-liner that he used in his thread title to attract our attention? Thank you very much. As we can see in his initial, still unedited post, he did notice the land impact savings on small objects already. His criticism was just as limited in scope as your and my agreement. He even expected a moderate increase in land impact with the larger size but was flabbergasted by the final result. And frankly, who wouldn't be? So what in the OP's findings is there not to agree with? Why do some people treat him like a newbie who needs to be taught the secrets of low-poly modeling? It's not that he doesn't know how to optimize. He's just wondering why it is necessary while sculpties get away with no optimization at all.

Kwakkelde Kwak wrote: Let me be a smartass and say your answer is the answer to this question: "Is mesh always preferred over sculpties in every possible way?" That however was certainly not the question asked by the OP and therefor not the question I was answering. The OP provided evidence: a particular build that is 32 times more expensive as a mesh, despite identical triangle counts. You did not debunk the OP's observation. Instead, you started talking about something else. The OP basically figured out that mesh sucks when used for "X". And you said he is wrong, because mesh works fine for "Y". Bottom line? Mesh sucks for "X". The OP is right. Drongle agreed. Why are you still arguing? The numbers are right there in your face.

Kwakkelde Kwak wrote: The question was: "Are meshes just a hoax with no use?" The answer is a loud and clear "No" The answer is an ambiguous: "It depends on the size." For large builds, meshes are just a hoax with no use.* *) except in OpenSim.

Kwakkelde Kwak wrote: I am not questioning the fact the rules aren't fair, but that discussion is ancient history for me to be honest and certainly not something to discuss on these forums, since no Linden will take notice. If it's not worth discussing, why are you doing it anyway? Why not just face the facts: SL looks like ancient history, and the OP just figured out why.

Kwakkelde Kwak wrote: Big boulders, blobs and other rounded objects aren't exactly the building stones of our Second Life. I think you are confusing cause and effect here. It should be possible, at least for region owners, to use a large 65536m² mesh instead of the default height-mapped land plane. This way we could have regions with fairly realistic terrain, nicely textured cliffs, and proper caves and tunnels. It should be possible to use a shared 2048x2048 texture atlas instead multiple small textures, because this would considerably reduce the number of expensive draw calls. But then of course, it should be possible to use normal, specular and lightmaps to reduce geometry and (baked) texture sizes. Is anyone working on that yet?

OK, here's the simple version: If you look at the UV/image editor, by default you'll see a grey square in the center. If you load an image, it will fill that square. Depending on the image aspect ratio, the square may turn rectangular at that point, but the image will never extend beyond that grey area, no matter how large it is in pixels. However, your UV layout can extend beyond that. And whenever that is the case, the texture will repeat when it is mapped to the mesh in the 3D view of Blender or in the Second Life viewer. So if you want more and smaller tiles on a textured surface, just scale up the corresponding faces in the UV editor. You can immediately see the effect in Blender if you open the 3D view and the UV editor side by side. Never repeat tiles in the image itself (by appending them in GIMP or Photoshop), because that is a waste of space. Texture tiling done by the graphics card comes at no cost.

Drongle McMahon wrote: The problem is not that mesh are costed too high and according to size, but that sculpties (and spheres and toruses etc.) are costed too low. Exactly my point.

Kwakkelde Kwak wrote: I have no clue how you come up with a factor 32 the other way. I can see that factor right there in the OP's screenshot. Please explain why that mesh build with 8900 triangles deserves to be 32 times more expensive than a multi-prim build of identical size and triangle count. This is so obviously wrong, I don't even know what there is to argue about. The land impact formula is fine, but it needs to be applied equally to prims, even at the risk of breaking some content, otherwise people will not do what is necessary to bring lag down and increase framerates. People shouldn't be making sculpties in 2012, but they still do, because the trouble of building low-poly meshes with multiple LODs does not get rewarded the way it should.

Pamela Galli wrote: Thanks -- the only global / local setting I see is for modeling. If you use Blender's own materials to map textures, you have several mapping options besides UV. If you are doing a full render bake including lighting and AO, you can save some time by using those as bake input, because they make cube mapping with global alignment very easy. However, if you want real tiling and sharp textures in SL, stick to your current method. I am not trying to align these -- I gave up on that because of the difference in blurrines. The pool will be on a little lower level so I need it to have a similar repeat but not be aligned. But the blur level is a result of the texture repeat. More repeats = smaller tiles = less blur. If you want identical tile sizes for both surfaces (and you should, since they are using the same type of bricks, so people will expect the same relative size across the entire scene), you need to unwrap them together anyway, whether you want alignment or not.

Kwakkelde Kwak wrote: These are numbers of someone who doesn't know how to build in mesh Sure, but why should he bother? Where is the incentive, as long as the metrics favour the large prim build by a factor of 32 and he doesn't even need to worry about LOD? Try to explain that to him.

Forget what I said in my previous reply. I just saw the other thread. You are not using materials; this thing here is called "face textures", and it behaves just like Drongle said. To align those two textures properly, you have to join the meshes, select the faces of both planes, and then unwrap them from top-down view. And every time you resize either plane, you have to do the same thing again, to re-align the UV layouts. Oh, and you don't need a 4x4 repeat texture. 1x1 is enough. If you need bigger or smaller tiles, just resize the faces in your UV layout. Note that it is perfectly normal for a UV map to be bigger than the texture area; that's how tiling works.

Imnotgoing Sideways wrote: You're doing it wrong. () Linden Lab is doing it wrong. And the OP has the numbers to prove it. As long as the land impact formula exists side by side with traditional prim accounting, people will look at those numbers and say: "Screw mesh, I'm doing it with sculpties!" Mesh creators have to bend over backwards optimizing their geometry and still find their land impact in the same ballpark with a prim build. This is bad policy because it fails to reward the efficiency that is needed to reduce lag in SL.

Make sure the mapping of the material textures is relative to a shared coordinate system, e.g. "Global" or "Object" (using the same reference object).