How much does poly count affect Land Impact?

[Shrouded Blackheart]

Well I'm just curious because i make high poly stuff and then bring the poly count down, use retopology, etc. and i always have my low poly ar around 500 polies.  I know it really depends on the object but the stuff I'm making is more organic stuff like boulders and rocks, etc.

 

So could somebody tell me if poly count effects Land Impact a lot?  I'd rather know sooner than later you see.. I mean would i be safe keeping my poly count around 1,000 per object, say 5 objects per project?

 

Thanks!

[Min Barzane]

Manny things affect land impact of mesh,from its polycount,physics shape to its size inworld so counting only on polycount to see land impact you wont get any distinctive formula to know how will it end up!you can have simple 200 poly shape for ground with skin tight pysics to walk on on 64 meters size and have it 30 LI or you can have 10000 poly model with only 1 tris as physics on 2 meters size to be 1 LI,its not exact science,all depens on how you make it! I can tell you this way and nother mesher will say something different,in end you have to see what works best for your designs...experiment!

[Shrouded Blackheart]

Yeh that's what i feared.. I guess I'll just have to try trial and error.. Like don't waste time texturing my work until i can see how it's going to effect Li.

[Drongle McMahon]

First, there are three "weights" for each mesh, and the highest of the three becomes the LI. You can find all the details in the SL wiki by searching for mesh and following the links there. Briefly, the "download weight" depends mostly on the "amount of geometry" and the size of the object.

The" amount of geometry" for any LOD is dominated by the vertex count you see in the uploader. Note that this may be much higher than the vertex count in your 3D program because vertices get duplicated (or more) when they lie on sharp edges, UV seams or the boundaries of materials. Keeping as many edges smooth shaded as possible will keep the weight down.

However, it's not that simple because there are increasingly simplified LOD meshes/ The effect of the goemetry at each LOD on the download weight depends on the size of the object. For small objects (<<10m) the lowest LOD geometry is by far the most important. As the object gets bigger, the iinfluence shifts towards the higher LODs. For very large objects, only the high LOD matters. Details of this are described here.

For most mesh, the download weight should be bigger than the others and bcomes the LI. This is because the physics shape mesh can nearly always be simplified until its weight is lower, without adversely affecting performance. It's best to reduce it as far as possible anyway, to minimize the workload for the physics engine on the server.

The server weight (of a linkset) is only 0.5 per object (1 if it's scripted). So that will only become dominant if you have a model consisting of several meshes with simple geometry, which become a linkset after uploading. In that case, you can usually reduce the overall LI by joining the parts into fewer, more complex, meshes. The main exception would be where you need the separate parts to move relative to each other, either manually or in a scripted animation.

ETA. Note that textures (and material maps) don't affect LI. This is a pity, because texture lag can be a real problem, but it means your strategy of testing LI before texturing is the sensible one. I never upload textures with the model anyway, for other reasons. However, you do need to do the UV mapping if you want an accurate LI, because the seams affect the download weight. You also need to check at the correct size (or sizes if it's going to be variable).

[Medhue Simoni]

---

Drongle McMahon wrote:

ETA. Note that textures (and material maps) don't affect LI. This is a pity, because texture lag can be a real problem, but it means your strategy of testing LI before texturing is the sensible one. I never upload textures with the model anyway, for other reasons. However, you do need to do the UV mapping if you want an accurate LI, because the seams affect the download weight. You also need to check at the correct size (or sizes if it's going to be variable).

---

I just want to add that every object in SL has a Display Cost. That Display Cost is a combination of a number of things, including your texture, shine, bump, glow, and the mesh.

[RipleyVonD]

---

Drongle McMahon wrote:

Note that this may be much higher than the vertex count in your 3D program because vertices get duplicated (or more) when they lie on sharp edges, UV seams or the boundaries of materials. Keeping as many edges smooth shaded as possible will keep the weight down.

---

Drongle, I was wondering if you could elaborate on how the SL uploader works concerning duplicating or altering a mesh when its uploaded. I find this a bit frustrating because when I bake Normal Maps for my geometry those normal maps are meant for the exact geometry it was baked for, otherwise applying that same Normal Map to a slightly altered mesh will produce artifacts. 

Can you point me to the source of this information on the wiki somewhere? I'll try and find it my self meanwhile. 

Are there image examples of how the SL uploader modifies mesh uploads with sharp edges? I would also like to see this, I"m sure I can do this myself to bake out a more accurate Normal Map.

[arton Rotaru]

The uploader doesn't alter your mesh. At least not in a visual way. As long as you leave the "generate normals" thingy alone.

It will import your hard edges, smooth edges like you defined them in your modeling program.

Although this is a rather dated article, the principles still hold true. It explains why/when a vertex will be duplicated in a game engine.

http://www.ericchadwick.com/examples/provost/byf2.html

This is although worth reading, it explains why you want hard edges, split UVs with normal maps.

http://www.polycount.com/forum/showthread.php?t=107196

The shading of your baked normal map won't work very well in SL anyway, because the tangent space basis of your baking program is most likely not the same as the tangent space basis in Second Life's shader. Here come hard edges/split UVs, manually edited vertex normal angles to the rescue.

 

[RipleyVonD]

---

arton Rotaru wrote:

The uploader doesn't alter your mesh. At least not in a visual way. As long as you leave the "generate normals" thingy alone.

It will import your hard edges, smooth edges like you defined them in your modeling program.

---

This is good to know. I really wouldn't want my mesh altered in a significant way, that is very bad for Normal Maps baked to a specific mesh.

 

 

---

arton Rotaru wrote:

The shading of your baked normal map won't work very well in SL anyway, because the tangent space basis of your baking program is most likely not the same as the tangent space basis in Second Life's shader. Here come hard edges/split UVs, manually edited vertex normal angles to the rescue.

 

---

I'm sure I'll find a way to make it work, I'm not unfamiliar with Normal Map baking. Thanks for the quick help. 

[Drongle McMahon]

You can follow the links from "Mesh" on the wiki front page. The most useful is probably
https://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format

Note that there is a distinction between the upload format, described in the text, where there are separate lists of position, normal and texcoords, and the internal (i.e. inside the viewer code) format described in the figure. (This is a figure I made from looking at the viewer source code - so it does not have any official LL stamp of approval! ... and as it was long ago, there may have been changes in the code). However, the net result is the same whether these vertex parameters are in a single list or in separate lists. As the upload format description says, there must be the same number of entries in each list (as long as the list is there) so that the total amount of data is always the same.

Basically, both describe a list of triangles, each of which has three indices that point into the vertex data list(s), one for each vertex of the triangle. If the vertex is part of a smooth-shaded surface, with no UV seams running through it, then its position, normal and texcoord (UV) is the same for all the triangles that share that vertex (ofetn 6, as in a surface made only of quads). So it can appear only once in the list, and all the triangles can use the same index.

The position is, of course, always the same, but if the vertex lies on a sharp-shaded edge, then the triangles on either side of that edge will use different normals. So that requires a new index, which will have the same position data but different normals data. This is what I mean by vertex duplication. In an extreme case the duplication can be dramatic. For example the point of a 32-sided cone will be duplicated 32 times. It is reflected in the increased upload vertex count when you change the shading.

UV seams have a similar effect. A single geometric point may be represented at multiple positions on the UV map, so that some triangles use the same geometric vertex, but with different UV coordinates. Again, that requires a new index and duplication of the rest of the vertex data. However, if the seams coincide with sharp edges, there is no need for further duplication. Keeping the seams and sharp edges coincident can therefore save download weight, and usually makes good sense anyway.

The other factor that increases the vertex count is the borders between multiple materials. In this case, the whole triangle list and the referenced vertex data list(s) are separate for each material. So vertices at the junction of materials (sub-meshes) always have to be duplicated in the separate lists, even if they share normals and UV coordinates. Usually these borders coincide with UV seams, in which case there is no additional increase.

As long as you don't use the "Generate normals" in the uploader, the normals will be what they are in the uploaded dae. So you have full control over which edges are smooth and which are sharp. Here are the numbers from an example, a 32-sided cone, with a triangle fan base. It has 34 vertices in Blender. Setting all faces to smooth and before UV mapping, the uploader saya 34 vertices, as expected. Adding a UV map with with a seam around the base and along one conical edge, the uploader says 67 vertices. All the vertices around the base appear at two different places on the UV map, one in each island (+32), and the one where the conical surface is split by the edge seam appears twice in that island (+1). Finally, I set the whole thing to flat shading (all edges sharp). Now it says 129 vertices. The vertex at the point now appears with 32 different normals (+31) and the ones around the base with three different normals (six triangles, but pairs have the same face normal). Those were already duplicated for the UV map, and one was already triplicated. So that another extra 31 vertices. Total is now 67+31+31=129.

No need to add anything about baking, as you can read much better advice in the links Arton gave, and other threads on polycount.

[RipleyVonD]

That's the information I was hoping to find when I came back here, I really appreciate that Drongle. It was very clear to understand, well for my techie head atleast. I'm hoping to test a mesh soon and see how it works on Aditi.