Jump to content

UV Unwrapping increase land impact alot


Megan Elcano
 Share

You are about to reply to a thread that has been inactive for 3365 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hi i've tried searching for an answer to this but not much help as most people are using blender and i use 3ds max.

my problem is when i upload my building model without adding a uvmap it uploads at land impact of 16 but when i ad a uvmap and import it it goes upto 46 land impact. I've being trying to look around on how best to uvmap my model to lower that impact?

Link to comment
Share on other sites

Different UVs can result in different vertices counts ingame, depending on the UV splits, hard edges, material borders.

So it's kind of expected behavior that the land impact varies with different mappings. If you don't have any UV mapping on your mesh, the uploader creates random data for the UVs. Most often this random UV map is more land impact heavy than a custom UV map, besides that the random mapping is useless anyway.

From 16 to 46 sounds a bit drastic though, unless you have a poly heavy mesh and each polygon has split UVs.

Are you sure it's the Download Weight which is driving your land impact, and not the Physics Weight, when set to physics type Prim?

As for efficient UV mapping in general; keep as many polygons as possible connected (stitched) on the UV map. Try splitting UVs where you have hard edges, or material borders already. Once a vertex is duplicated due to hard edges, it won't duplicate again when the UVs are split on that edge.

Link to comment
Share on other sites

an increase of the download costs by a factor of 3 points to flat shading for all faces. Sorry i do not know how it is called in Maya. But the point is: When every face has its vertex normals set parallel to its face normal, then the number of "vertices" as counted by the SL Importer tripples -> this could be the reason for the increase of LI... But i am just guessing :matte-motes-sunglasses-3: There may be other reasons for this...

Link to comment
Share on other sites

Flat (or sharp) normals doesn't necessarily result in higher download weight than smooth ones. In many cases smooth normals gives considerably higher weight than flat ones.

I've never tried uploading a mesh without any UV map at all so I don't know if that affects the download weight. However, what kind of mapping you use has little or no effect on the land impact.

There are several other ways to reduce download weight though. I posted a list of some techniques in another thread two weeks ago:

http://community.secondlife.com/t5/Mesh/The-importance-of-LOD/td-p/2873204/page/3

In your case, #2 on that list, weight balancing, seems to be the most relevant. Generally speaking, if the download weight is higher than the server weight, you can reduce LI by splitting the mesh into several smaller ones. If it's the other way round, you probably want to upload as fewer and bigger meshes. Of course, it's sometimes a question whether an object can be split up in a sensible way but if it's a building you're talking about, I'm sure there is a way.

Link to comment
Share on other sites

yes it is a building im importing and im going to try splitting it down some more see if it helps :) i just thought it was very strange as soon as i applyed a uv map to my building in 3ds max and imported it the download weight increased alot but before the uvmap was added the land impact was very low confusing :)

Link to comment
Share on other sites


ChinRey wrote:

Flat (or sharp) normals doesn't necessarily result in higher download weight than smooth ones. In many cases smooth normals gives considerably higher weight than flat ones.

Can you give an example for this ? All i learned about normals indicates that flat shaded faces need 3 times more coordinates (one verterx normal for each vertex of the flat face) which would reslt in a raise of LI.

Link to comment
Share on other sites


Megan Elcano wrote:

yeah its 100% download weight as physic weight is only 0.720.

I've not long started meshing so i need to work on my uv mapping abit. but can not find many useful uvmapping tutorials for better uv maps for SL only general uvmapping tutorials

 

There really is nothing special about UV mapping for Second Life and any other game engine. The goal is always to keep the vertex count of the asset as low as possible. Splitting UVs on hard edges where possible is good advice.

Pretty much any game asset related tutorial will do the trick.

Link to comment
Share on other sites


Megan Elcano wrote:

yes it is a building im importing and im going to try splitting it down some more see if it helps
:)
i just thought it was very strange as soon as i applyed a uv map to my building in 3ds max and imported it the download weight increased alot but before the uvmap was added the land impact was very low confusing
:)

As the name implies "download weight" depends on how much data the client has to download from the server and an UV map adds quite a lot to that.

 


Gaia Clary wrote:

Can you give an example for this ? All i learned about normals indicates that flat shaded faces need 3 times more coordinates (one verterx normal for each vertex of the flat face) which would reslt in a raise of LI.

Not right away I'm afraid. I'm on christmas vacation and only have a laptop without Blender installed at the moment. I'll see what I can do when I get home.

But you may find this thread interesting:

http://community.secondlife.com/t5/Mesh/Extreme-mesh-optimisation/m-p/2733952

Especially Drongle's first post.

What is clear is that the mesh file is compressed before it is transferred and the donwload weight depends on file size after compression. Flat normals do indeed require more normals and thus more raw data but since all those extra normals have the same coordinates, the file becomes far easier to compress.

I often upload the same mesh with both flat and smooth normals to the beta grid to see which one looks the best and although I haven't kept the stats from these uploads, my experience is that smooth normals usually result in a slightly higher download weight than flat ones, sometimes slightly lower. Never seen any huge difference either way though - hardly ever more than 0.1, usually less.

Link to comment
Share on other sites


arton Rotaru wrote:

There really is nothing special about UV mapping for Second Life and any other game engine.

That's not strictly speaking true. The UV map system built into SL is slightly different from what other game engines use. But that may be hair splitting. The two systems are fully compatible and the general pirnciples are the same.

However, if I understood Megan correctly, she was talking about meshes with no UV mapping at all and that's a completely different matter.

Link to comment
Share on other sites


Gaia Clary wrote:


ChinRey wrote:

Flat (or sharp) normals doesn't necessarily result in higher download weight than smooth ones. In many cases smooth normals gives considerably higher weight than flat ones.

Can you give an example for this ? All i learned about normals indicates that flat shaded faces need 3 times more coordinates (one verterx normal for each vertex of the flat face) which would reslt in a raise of LI.

Which would fit quite nicely in the scenario as described. from 16 to 46 or what was it, is pretty much that factor 3.

In the UV editor in 3ds max, you want as little islands as possible, this results in the least amount of double vertices. By the looks of the land impact all triangles are their own seperate island, although I can't understand how one would get such a UV layout. Maybe a "flatten" with a very strict threshold?

@Chin...

I am also curious about an example where smoothing raises the landimpct instead of lowering it.

Link to comment
Share on other sites

Certainly. But that wasn't the point here. The OP complained about increased land impact with custom UV mappings.

Thing is, you will have to split UVs anyway, more or less depending on the shape, to flatten it with as less distortion as possible, as you know for sure.

My point was, UV splits will duplicate the vertex at the split, because there will be different vertex data for those (texture coordinate).

On hard edges the vertex data will be different as well (vertex normal), hence the vertex will be duplicated to hold the sets of vertex data.

But once you have a hard edge, you have a duplicated vertex already, which will hold the position, texture coordinate, and vertex normal ect. pp. So when you split UVs at that hard edge, you still have 2 vertices which can hold the data set of each.

So UV splits on hard edges come for free. Same the other way around, making edges hard where UV splits are, will make the hard edge for free.

Indeed these are just some guidelines which won't always be practical, either way. But when you have the choice, one should choose the UV split on hard edges, instead of leaving the hard edge and split UVs on the soft edge right next to the hard edge.

Link to comment
Share on other sites


Gaia Clary wrote:

Can you give an example for this ?


 

It'll have to be a quick demo only:

Normals LI test.png

The weird shape to the left here is made from three simple cube prims of different sizes, meshed with MeshStudio, imported to Blender and exported directly with no modifications. All LOD models are identical. The Download weight is 0.596.

The one to the left is identical except it has smooth normals. The download weight is 0.791.


Gaia Clary wrote:

All i learned about normals indicates that flat shaded faces need 3 times more coordinates (one verterx normal for each vertex of the flat face) which would reslt in a raise of LI.


Yes but remember the data is compressed and that means three vertices with exactly the same coordinates don't requrie three times as much data than a single vertice. Also, since each vertice only is attached to a single triangle, it requires less data than one that is attached to three. (Edit: Woops, made a slight mistake there. Each vertice in the flat normals model is attached to two triangles of course, not just one, but it's still fewer tris on each vertice than the smooth normals model has.)

This explains why splitting the vertices up like the uploader does with flat normals, doesn't increase file size/download weight very much but it doesn't explain why the flat normal version has a lower weight than the smooth one. I can think of two explanations:

  1. A flat normals is usually aligned along the local x, y or z axis which means it requires less data than one that is at an angle. This is confirmed. I tried to rotate the flat normal model a bit and the download weight went straight up to about 1.14.
  2. Flat normals means the vertice normals are identical to the poly normals which makes the file even more compressable. I can't think of a way to test that but it makes sense.

And that of course means I've revealed two more of the secrets behing my low LI houses: try to make the dae files as compressable as possible and align the surfaces along the axises whenever possible. Oh well, I suppose I better hurry up and get those houses out on the market before everybody catches up... :matte-motes-wink:

Link to comment
Share on other sites

  • 2 weeks later...

Aloha to all ;)

I have run some tests with an organic mesh, a tear I’ve made, with the following questions in mind:

  1. Smooth shaded models give less, more or equal land impact (LI) than flat ones?
  2. The UV maps with more islands increase LI? (UV methods used: UV unwrap with Mirror Mod -generates 2 overlayed islands-, UV unwrap -1 island-, Smart UV Projection -multiple islands-)
  3. How affects subdivision level? (Subsuf 1 and 3)

All tests run with default LODs. Blender version is 2.72 and Second Life’s Viewer used was Firestorm.

01 SL Uploader Test 01 Subsurf 3.png

02 SL Uploader Test 01 Subsurf 1.png

03 SL Uploader Test 01 regular UV unwrap with Mirror.png

04 SL Uploader Test 01 Smarth UV projection.png

05 SL Uploader Test 01 regular UV unwrap.png

SMOOTH VS. FLAT SHADING

Observation: In the major models uploaded, smooth wins versus flat. Just in very LP meshes, and depending of the unwrapping, smooth and flat can give same LI as result.

Conclusion: Smooth shading is more effective to reduce LI than flat shading.

UNWRAPPING METHOD AFFECTS LAND IMPACT

Observation: There’s a difference between the 3 methods used.

  • When tear model uses flat shading, UV unwrap using Mirror Mod is the most effective, followed by Smart UV Projection and UV unwrap
  • When tear model uses smooth shading, the better method is Smart UV Projection, followed by UV unwrap using Mirror Mod and UV unwrap

Conclusion: The UV method used to unwrap a model affects LI.

But why? Also it has relation with the normals?

HOW AFFECTS LEVEL OF SUBSUF TO SHADING AND UNWRAPPING

Observation:

At Subsurf of 1:

  • In LI, The only difference is in tear with smooth shading and Smart UV Projection, giving a lower impact. For the rest, there’s no difference using smooth or flat shading with any of the 3 unwrapping methods used
  • In Dowload, different shading and unwrapping methods seem to affect
  • Physics have same value than LI in tears with smooth and flat shading

At Subsurf of 3:

  • We see a clear difference in the models LI related to shading and unwrap
  • In Dowload, flat shading and unwrapping methods used don’t seem to affect while yes with smooth shading
  • Physics have same value than LI in tears with smooth shading, while in flat shading there’s a difference

Conclusion: When level of Subsuf increases, the difference between shading and unwrapping methods is more obvious.

As one can see, the method used to unwrap and choosing between applying smooth or flat shading is important related to Subsuf level.

Photos, photos , photos...

Tear_Sharp_UVs_Mirror_LP.png

Tear_Sharp_UVs_Mirror.png

Tear_Sharp_UVs_SmartProjection_LP.png

Tear_Sharp_UVs_SmartProjection.png

Tear_Sharp_UVs_unwrap_cube_LP.png

Tear_Sharp_UVs_unwrap_cube.png

Tear_Smooth_UVs_Mirror_LP.png

Tear_Smooth_UVs_Mirror.png

Tear_Smooth_UVs_SmartProjection_LP.png

Tear_Smooth_UVs_SmartProjection.png

Tear_Smooth_UVs_unwrap_cube_LP.png

Tear_Smooth_UVs_unwrap_cube.png

In case you cannot see well the pictures, here's my post about it in my Blender blog:

--||-
Link to comment
Share on other sites

Nice test, but you should have made it by loading the same mesh in all LOD slots. To avoid getting different numbers in vertices count on the lower LODs. You can see differences in the lower LOD slots which make the test inaccurate to begin with. Also you should have made a simple box physics shape and use it for all variations, or again, the uploader will just create a phys mesh with various numbers.

Anyhow, the vertex count is all about the Download Weight only actually, and as you can clearly see, in your pictures, the one with smooth shading, and stacked UVs has the lowest download weight, because it has the least amount of vertices in High LOD (98). Followed by the single island cube unwrap (125) and the smart projection is the worst (141) with the highest download weight of the smooth shaded lowpoly meshes.

The models with flat shading have always the same number of vertices in High LOD, because each vertex is duplicated anyway, due to the unique vertex normals. So the Unwrapping method won't increase, or decrease the vertex count at all anyway.

It's really just compression which is why ChinReys flat shaded example has lower download weights. Each and every normal can be represented with just <1,0,0>, <0,1,0>, <0,0,1>, compared to vectors like, <0.847454, 0.214658,

0.512473>.

As soon as you start modeling something more appealing than just plain boxes, this won't work out anymore anyway.

What we can see here though, is that the smooth shaded meshes, with the least amount of UV verts are the most effective (mirrored UVs). And the Smart Projection UVs is the worst. So, just use common sense, split UVs where you have hard edges if possible, and don't get mad about compressibility to safe a prim, and constrain yourself to just rectangular box shapes. :matte-motes-nerdy:

Link to comment
Share on other sites

The Download weight is 0.596. The one to the left is identical except it has smooth normals. The download weight is 0.791.

I don't knoe how Mesh Studio deals with materials and UVs in the default case. Three simple prim cubes have 18 SL faces, which obviously can't all be there in the combined mesh. How many are there? Vertexes have to get duplicated each time they are used with a triangle with a different material, because each material has its own trianle and vertex lists. S this will account for some excess download over that for the simplest smooth shaded case.

More importantly, the faces of the prim cubes have detached UV maps. If that remains the case in the mesh produced, with all quad edges then being seams, then there will be no difference in vertex count between flat and smooth shading. All trhe vertices will be duplicated for each face because of different UV coordinates.

So this example appears not to provide a real test of the effect of smooth vs flat shading on download weight. I made roughly equivalent (guessing) mesh in Blender , from three cubes without hidden face removal, with just one material and each cube unwrapped with usual flattened cube map. same in all LOD slots. Smooth one was 36 tris, 42 verts, dw = 0.72. Flat was 36 tris, 72 verts, dw = 1.035. Can't compare those directly with yours because size will be different*. Different triangulation is apparent too..

chins.jpg

*ETA: Actually, that's wrong. If all LODs are the same, the download weight doesn't change with size. I, of all people, should remember that!

Link to comment
Share on other sites

Good experiments, given the complications mentioned by Arton. I made av similar drop, your one-subdiv only, and tried a few uploads with different UV maps, but with all the LODs the samr as the high LOD. That makes the download weight independent of size. Here are the UV maps I used, and the results...

noke.jpg

The results are pretty much what we expect. If the UV map is completely fragmented into triangles, then smooth shaded and flat shaded versions already have completely duplicated vertices. For the flat shading, the number of vertices stays the same, because of the different normals. This shows that the quads are not exactly flat. Otherwise, the two vertices where the diagonals get removed would be combined.

However, there is a significant reduction in the download weight as the UV maps get joined up. I think this is the compressibility effect. The vertices are still split because of the flat shading, but where they share the same UV coordinates, the same numbers appear six times (on average). Repeated identical numbers compress better.

When we switch to smooth shading, the vertex count goes down for the less fragmented UV maps, because all triangles meeting at a point share the same vertex, unless they are split apart in the UV maps. The reductions in the download weight are much greater than from compressability alone. Even just going from triangles to quads makes a big difference.

Link to comment
Share on other sites


Drongle McMahon wrote:

I don't knoe how Mesh Studio deals with materials and UVs in the default case.

We have to ask TBB about MS' UV mapping but in this case both dae files were generated by Blender. To make the comparasion as exact as possible, I imported the file for the flat normals example into Blender too and exported it unmodified. A Mesh Studio dae file will often give a slightly lower (only a few hundreths of a point) download weight that a seemingly identical dae file from Blender. (Not in this case though, the Mesh Studio file also gave a downlaod weight of 0.596.)

 


Drongle McMahon wrote:

I don't knoe how Mesh Studio deals with materials and UVs in the default case. Three simple prim cubes have 18 SL faces, which obviously can't all be there in the combined mesh.

All 18 faces are present. This wasn't intended as a test, remember, just a quick and dirty demonstration to show that smooth normals don't always reduce download weight.

Arton's and Drongle's drop tests are interesting but it's a completely different model than the one I used. I haven't done any formal tests of it but in my experience curved shapes like the drop have lower download weights with smooth normals while flat surfaces aligned along the axises, like my cubes, are better off with flat normals.

Drongles reproduction of my demonstration is really puzzling though. I actually thought 0.596 DW was surprisingly high for such a simple model with just 18 flat surfaces and 36 triangles!

 

This thread were supposed to be about UV maps and LI, not normals, and the drop tests are extremely interesting there. It's the first time I've seen clear documentation that the UV map affects download weight. We better be more careful how we map those vertices from now on.

Just one reminder though: don't get too hung up on which unwrapping option to choose. They are not inherently different funcions, just a selection different algorithms we can choose from to get those vertices down on the UV map quickly and efficiently. What matters is where the vertices end up, not how they got there. You wouldn't usually use an unmodified auto-generated UV map anyway. A little bit of manual tweaking is nearly always necessary to get the perfect result.

 

One additional factor the drop tests didn't seem to cover, is the impact of integer vs. float vertice coordinates. Here's a simple test I just did:

Make a 16x16 vertice 2x2 m grid in Blender. UV map with cube projection, correct aspect, scale to bounds. This should space all the vertices evenly across the UV map, at 16 pixel distance from each other. Upload to SL with all LOD models identical. The downlaod weight I got was 9.146.

However, Blender's UV mapping is always a little bit inexact. For example, the second row of vertices in this test got Y coordinates of 238.93 rather than 240.00 and so on. Move the vertices so they all match the 256x256 grid exactly, with all coordinates whole numbers, and suddenly the download weight drops to 8.865.

That's the results I got at least. It would be really interesting to learn if others get the same numbers

Link to comment
Share on other sites

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. 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.

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. All the UV coordinates are converted into 16-bit integers, after normalisation so that the range in the input covers  0..65535, before upload*. These 16 binary bit integers are what gets uploaded as binary data. Consequently, the ascii 0 becomes 0000h, and 256 becomes FFFFh. Because the max is 65535, not 65536, the converted numbers are no longer exact. (from LLModel::WriteModel() in llModel.cpp). I think there must be something else at play here.

*as are the positions and normals, by the way.

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

Link to comment
Share on other sites

Did some more experiments. Method of construction does have an effect. I got slightly different download weights using loop cuts instead of subdivide, and different when I did the horizontal or vertical cuts first. Also, I got a small increase if I moved one row of vertices a bit on the UV map, and a bit more if I moved four rows. All very odd. I still suspect it's most likely compressibility changes.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3365 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...