uploader quadruples vertice count

[hibit Spad]

I have been struggling with this model for many many months.  The uploader keeps quadrupling the vertice count.  

I have converted all quads to tris and removed the orphaned vertices.  Originally this model was over 250k vertices but I have reduced it down to 57k and I think still kept the detailing I wanted.

 

But SL won't cooperate.  I tried making this a JIRA but the file is too big to upload.

 

http://dl.dropbox.com/u/45308328/shiprigging88b.dae

 

Any suggestions that solve the problem would be much apprectiated.

[Drongle McMahon]

What is it? I don't think I am even going to try to look at this 11Mbyte file in Blender.

The internal/upload format has a vertex table in which each vertex has a normal and a UV coordinate as well as the geometric coordinates. This means that where a gepmetric vertex occurs with different normal and/or UV coordinates, it has to be repeated for each distinct set of normal and UV coordinates. So meshes with sharp-edged shading ("solid" in Blender) repeat vertices as many times as they have meeting triangles with different normals. They also get repeated where they lie on a UV seam so that they appear with different UV coordinates. The uploader vertex count is after these repetitions. This can easily lead to a quadrupling of the simple geometric vertex count, for quad models with curved solid-shaded surfaces, in which six triangles with four different normals meet at each geometric vertex. For smooth-shaded surfaces there is only one normal at each geometric vertex. So using smooth shading can save all the vertex duplication resulting from sharp edges.

This means you should always use the minimum number of sharp edges - in Blender, use Set smooth for all faces, mark the edges youi need sharp and apply the edge-split modifier. Atr you by any chance using high levels of subdivision to get smooth-looking surfaces despite sharp edhed shading? If so, you can achieve a whole lot of triangle/vertex reduction by using smooth shading instead, and then get the saving from less vertex duplication on top of that.

[Drongle McMahon]

OK. I did manage to look at it in Blender. It's some very nice rigging (in the original sense of the word!), but way too many triangles for what is only part of something much bigger. As imported, it's all sharp edged*. So, if that's the same in your model, the first thing is to set it all to smooth and then mark the sharp edges you need.That should reduce the uploader vertex count to at most 1/3rd  what it is now.

Then, I would reduce the vertices around the rope cross sections to six (or 8, some would say 5). You never see a cross section** and six faces with smooth shading will look better than what you have with sharp shading.  Leave the discs major circumference as it is, but halve the number of vertices around their smooth edges. There is also some hidden geometry of the rope inside the discs, which can be removed along with simplifying the turns. All that could get you another 50% saving.

What are you doing for low LODs here? It's a perfect candidate for using large triangles with an alpha texture for the lowest relevant LOD. However, since the model radius is about 27m, the lowest LOD won't enter into the calculation. It will have to be done for the low LOD. You might get better control of LI if you break it into six separate meshes.

Whatever you do, make a very simple physics mesh. The triangle based physics weight of this as it is would likely be enough to fill a whole continent, and you obviously won't want to use the default convex hull. The decomposer in the uploader is unlikely to make a good job of this model.

* This might be the importer's fault - it doesn't seem to preserver smooth shading on export->Import. So I can't tell which you had in the original.

**I'm wrong there - you do see it where the rope goes throght the discs. But you could make just that bit of the turn have the more detailed circumference.

[Cathy Foil]

I opened up your DAE file in Autodesk FBX Converter 2012.2 and took a look.  Very nice ship rigging!  I can't wait to see the whole ship finished.  I am sure it will be wonderful!

My advice would be to that anything that doesn't absolutely need to have a sharp edge be set to a smooth edge.  I noticed that the lower vertical ropes were all basically vertical cylinders that were made up of 16 vertices at each end and that the vertical ropes up higher were just 6 vertices at each end.

I would make all the lower ropes be 6 vertices just like the higher ones and delete the faces on each end of all the ropes and make sure that the ends edges where set to smooth not sharp.  All those ends will be hidden in the ships structure anyway.

If memory serves me correct during the upload process the DAE file is converted to another file format and that any vertices edges that are set for sharp edge are doubled.

I hope that helps.

[hibit Spad]

Thank you for looking at this.

 

Firstly I have no edges set to sharp.  I thought I had done smooth for the whole model but I will double check this part of it.

 

Drongle I will visit your suggestions on vertice removal.  Also, as on the med and lower LODs I plan to completely remove all the rope above the deadeyes.  If you look at pictures of a tall ship you will realize that you don't have to get too far away before all the rigging just becomes a bit of a haze anyways so I am just going to remove it.  I would like to completely remove everything abut as I understand some of the messages posted here the uploader won't allow that. The physical layer I plan to just make about 6 squares so it will be like walking up a ramp (all right a rather steep ramp).  So that will be 6x4x2=48 vertices for the physical.

 

Cathy ,  hmm  did I not get all the ropes when I went through started deleting vertices?  I guess I didn't.  Chalk one up to my ADD.  Thanks for noticing that.  Some of the ends of the rope I can delete cause they are hidden thank you.

 

 

 

 

I just wanted to add this link http://dl.dropbox.com/u/45308328/ship%20rotation0001-0351.mpg  of a video I did several months ago inside blender of this ship. 

[hibit Spad]

I filed a JIRA on this and LL has classified it as a major bug. 

 

https://jira.secondlife.com/browse/VWR-28728?

[Drongle McMahon]

Hibit

I had another look at part of you rigging. In particular, I looked at the UV mapping. Different UV coordinates for the same geometric vertex are like different normals - in the internal format they cause the whole vertex data (position, noprmal, uvcoords) to be duplicated for each different UV coordinate. I couldn't look at all of it, and some bits are OK, but the vertical rope I looked at has separate UV islands (stacked on top of each other) for each of the faces around the circumference, instead of having them laid out next to each other. If this UV map fragmentation is repeated throughout, it could account for quadrupling the vertex count in the uploader, which counts all the duplicated vertex data entries. It is the same problem with the faces of the pulleys (or whatever they are called), although the edges of these and the ropes connecting them seem to have better UV maps. There was also an extra very narrow triangle that I don't think should be there, in the vertical rope.

The point is illustrated thus - I took one segment of the rope, smooth shaded, and exported it. Then I made a new UV map and exported it again. Before remapping, the uploader saw 66 vertices. After, it saw 35. In Blender it is 16 segments round giving 32 vertices, plus the one for the extra at one end of the narrow triangle. The two vertices on the seam get duplicatyed as expected. Because this is a detached segment, each vertex is only on two faces, so the maximum increase in vertex count is 2x. If the same sort of UV mapping were applied to a plane of quads, it would be quadrupled.

So... at least part of the high vertex count you see appears to be the result of non-optimal UV mapping. You can't avoid some increase from this source because you do have to have some UV seams, but it should be much less. You might have to be quite sparing with seams to keep the increase small enough to stay within the 64k vertex count limit.

I hope that helps a bit.

ETA: by the way, with reference to the jira, the 64k limit applies separately to each LOD mesh. It's a consequence of the use of 16-bit indices in the triangle list, that point to the triangle's vertices in the vertex list. In fact, I think it can be 64k vertices per material/submesh. The internal data format is described in the wiki.

 

 

[hibit Spad]

I had played wiht the UV mapping earlier and maybe I had screwed it up at that point.

 

For awhile I had dropped the idea of importing this rigging as I thought the vertice count was too high.  I had since then done a bit of work dropping it down. but I guess the inneficient UV mapping is still there..

 

64k  per material/submesh?  wow that is a big change from what I thought it could be.  I will definatly have to play wiht that.  Not that I want sky high vertice counts as the LI (or what ever it is called now)  will be too severe a penalty.  but it would be nice to see how much leeway ther actually is.

[Drongle McMahon]

It would be interesting to know if the 64k per material works, but I very much doubt whether the use of so many vertices can be justified or practical. Land impact would be prohibitive. One of the better ways of reducing it is to break models into smaller parts, reducing LOD switch distance and thus reducing download weight. That would help with your rigging too.