UV Unwrapping increase land impact alot

[ChinRey]

---

Drongle McMahon wrote:

It would be really interesting to learn if others get the same numbers

After the cube projection unwrap, all my UV positions were already exact. So I could only upload that. Dwt was 11.344, which is higher than either of yours! What Blender version are you using? Mine is 2.71.

---

I use Blender v. 2.71 too - run on a Windows 8.1 computer.

---

Drongle McMahon wrote:

It might depend on how the grid was made, which can affect the order of vertices and triangles in the output, and thus possibly the compressibility. I just made the default 2x2m plane, then subdivided it four times, using the subdixide button.

---

I made a grid right from the start, setting the subdivision when I made it.

 

---

Drongle McMahon wrote:

ETA: I was assuming you meant 16x16 quads, which is 17x17 verts, not 16x16 verts .... true?

---

No, 16x16 verts, that is 15x15 quads.

 

---

Drongle McMahon wrote:

In fact, I have to doubt that exactness of UV coordinates is relevant. It will affect the size of the ascii numbers in the collada file, but those are not uploaded.

---

Hmmm, good point.

 

---

Drongle McMahon wrote:

I think there must be something else at play here

---

 I agree. Your and Noke's droplet tests are even more indicative there. The DW differences you got there seem far too big to be explained by compressibility alone. Right now it seems the only thing we know is that the UV map can have a significant impact on the DW. What causes it, is anybody's guess.

 

(Edit:

My best guess right now is that download weight depends on two previously unrecognised factors, the A value and the P value:

• The A (Avatar) value is assigned to your account as you sign up for SL and is based on your shoe size, the number of posts you are expected to post at this forum in the future and the amount of coffee consumed at LL the previous month.
• The P (Planetary) value is simply based on the alignments of the planets at the time the dae file was generated.)

[arton Rotaru]

---

ChinRey wrote:

---

 I agree. Your and Noke's droplet tests are even more indicative there. The DW differences you got there seem far too big to be explained by compressibility alone. Right now it seems the only thing we know is that the UV map can have a significant impact on the DW. What causes it, is anybody's guess.

---

Well, it's actually very simple, leaving the compression factors aside. The Download Weight is calculated from the number of vertices. And depending on how the UVs are split in conjunction with hard/soft edges and material borders, you have more or less duplicated vertices. It's simple as that.

12 years old article but still true and worth reading:

Beautiful, Yet Friendly Part 2: Maximizing Efficiency

[Drongle McMahon]

ChinRey - sent me the dae files for the boxes made from Mesh Studio. They both only have one material (one SL face). So materials don't explain anything. However, the UV mapping is rather strange. The faces are triangulated in the dae files, but the two triangles sharing a quad corner always have identical normals and UV coordinates. So there is no vertex splitting resulting from the triangulation, and we can regard the mesh as being made of quads. There are the expected 36 triangles and 72 vertices in the counts in the uploader for the flat shaded mesh (3x8 verts per box = 24, then each split into three by the three normals = 72).

That would be reduced to 24 vertices by smooth shading if there were no UV seams. However,  each quad is essentially independently mapped, so that nearly all the edges are seams. The result is that nearly all the vertex splits don't get removed when the shading is smooth, because the UV coordinates of the three geometrically identical vertices at each corner are different. There are four exceptions where the UV coordinates happen to be equal, which results in the vertex count dropping from 72 to 68. So we should expect a small reduction in downlload weight because of the small reduction in split vertices.

In the uploader, the download weights (using same model in all LODs) are 0.596 for the flat shaded mesh and 0.776 for the smooth shaded mesh. The weight is increased by the smooth shading instead of decreased, even though the split vertex count has gone down a bit. It is difficult to offer an explanation. The geometry and ~UV data in the two dae files are identical. Only the normals are different. In the smooth shaded mesh there are eight different normals, while there are only six different normals in the flat shaded mesh. It would appear that makes sufficient difference in compressibility that it overcomes and reverses the difference expected from the reduction in split vertex counts alone?

Of course if the UV mapping was more helpful, with fewer seams, as in the model I made for an earlier post, then the saving in reduced vertex count would be much greater, resulting in a lower weight as I had found. So I think this example mostly just provides a good example of why over-fragmented UV maps are bad for LI. I guess user of Mesh Studio would do well to redo their UV mapping in Blender before uploading.

ChinRey - Ah. Your grids were different and all is explained. I am sure the small difference must be compressibility, although I can't suggest why that should be better with the change you made.

Arton - That is a useful link, but it is the smaller differences that persist when the split vertex count is constant, such as that here and in the flat-shaded examples with my drop, that are puzzling me. I still think these must be all compressibility, but I am surprised by how large some of the differences are. However, I can't think of any general principles that would allow exploitation of these differences, and they probaly not large enough that they  would be worth the effort anyway.

 

[arton Rotaru]

---

Drongle McMahon wrote:

 

Arton

- That is a useful link, but it is the smaller differences that persist when the split vertex count is constant, such as that here and in the flat-shaded examples with my drop, that are puzzling me. I still think these must be all compressibility, but I am surprised by how large some of the differences are. However, I can't think of any general principles that would allow exploitation of these differences, and they probaly not large enough that they  would be worth the effort anyway.

 

---

Yeah, it's rather academic to nail it down to the tiniest bit of the equation.  While it's preferable to keep the file size as little as possible, It's still better to have a couple of additional UV splits if you can make better use of the UV space that way, and being able to use smaller textures while keeping the texel density the same.

Same with vertex normals. I can't think of any artist who would make an edge hard, or soft just for land impact reasons, when it should be one or the other to look good.

[Noke Yuitza]

Aloha

I've run the tear test with default LODs and no physic model because I wanted to see how the uploader was going to calculate them. And I wanted to see what happens with that when a mesh becomes more complex and detailed. That's why I've choose an organic form with a Subsurf of 1 and 3. But more tests are needed about, as Drongle one (with more photos please! Remember not all people reading these post have a good english... as me, per example... so any graphical material are welcome to understand you all better). 

Arton, thanks for the article. Is the way I use to work, but I still without fully understanding SL Uploader and why i guet some ramdom of toppic results with it.

Yeah, it's for driving nuts Drongle. But how little enough are those difference when we are dealing more complex meshes?

Drongle, I think I didn't understand you when you talk about looping... when one do a manual subsuf model by looping, one use to have more control about final number of verts/faces than when one use the Subsurf or Multires Mods in Blender. Using the Subsurf, in theory, what can give you is a more uniform mesh in your model, which uses to mean a more uniform UV faces. Do you mean with same final number of verts between manual looping and Subsurf Mod? 

About the UVs... my personal opinion is that I'm going to still working as always: customizing my UVs for texturing better (specially because I work with ZBrush too and have a different unwrapping method than Blender). For me, by now, it's better, but's that's my personal choise.

About Tris vs. Quads... my partners and I did some time ago a simple test about with a LP organic leaf. We were thinking that maybe converting to Tris the leaf could help to minimize LI, because in theory will help the uploader to don't have to convert Quads to Tris, or will not have any difference. But our result was that Quad model was giving quite less LI than Tris model. For triangulate our Quad Model, I used Blender's Tris Modifier. UVs unwrapping method used was Projection. I don't remember if shading method was flat or smooth, sorry.

 

We have to remember that saving 1 or 2 prims can be important for mesh creators (sellers and artists too) that have prim limit restriction. Per example that's my case: when I do big art installations in a full sim (my last one was with my team: The Sea of Cubic Dreams at LEA25. All mesh*. We spend over 10.000 prims), I use to not be quite worried about if my assets are some prims down or up LI conversion, but when I have to design with prim limit restriction (we reproduct a part of it for a charity event, but with a limitation of 300 prims)... the story change. Any mesh creator should need to plan better the "how to do for SL" uploader (efficiency), users (quality) and land LI restrictions their stuff before starting modeling. And that means that any tricks that can help to optimize a model, without loosing really much quality at least in Med LOD at mínimun LI possible, can be really helpful. Understanding how much can or not be important shading and UV unwrap can be important depending of what you want and need to create.

 

 *Mostly beveled clon cubes of different sizes and editor's physic tab settings to make them interactive without scripts. The base-cube was optimized to be able to be saw at distance, also with poor graphics. The cost in prims of this cube was of 7 prims (it was big). Unwrap method used for the cube was UV unwrap with Mirror Mod. Smooth shading. Modeled in Blender 2.6.

 

[Drongle McMahon]

Drongle, I think I didn't understand you when you talk about looping...Do you mean with same final number of verts between manual looping and Subsurf Mod?

I just used different ways of subdividing a plane to make a grid: subdivide button 4x, loop-cut-and-slide 2x, and the (simple) subdivision modifier, to see if the results were different. These all do simple subdibision without smoothing to pruduce the same result.