LI count, something not right

[Aquila Kytori]

HI everyone

Today I was uploading an avatar size Skeleton ( not rigged ) and was expecting an LI of around 10 to 15 .

The Uploader decided it was 50 ! Even manually setting the Med, Low, Lowest LOD levels in column A to zero the Triangle counts in column B refused to go lower than 1123.

Note, to make things as simple as possible I deleted all materials and the UV maps  for these test uploads  :

 

From the image below you can see that the Approx calculation should have been around 10 or so :

 

So I started dividing up the skeleton into smaller parts hoping to find an area of the mesh that was causing the problem.

The worst offender seemed to be the rib cage, notice the triangle and Vertice counts are the same for each of the lower 3 LODS. What would cause this ? :

I Started deleting parts of the rib cage and doing test uploads . I found that if I removed the most of the front vertical bone I could get the LI down to 10 , still too high . After many more uploads of deleting face by face i though i had found a couple that were causing the high LI but when I went back to the full rib cage and just deleted those 2 polygons it didn't make any difference  :(

Next I thought I should make a similar mesh with same number of vertices , so rezzed a circle extruded it to give it thickness then made 9 copies of that and uploaded it :

Crazy ............. all the Tri count and vertice count for the LOD levels are the same ! That mesh was set to smooth Shading . What about Flat Shading .............?  :

LI  of 1 .  

It seems to be the Smooth shading that is causing the high LI

When I tried re-uploading my skeleton with flat shading the LI was around 20, (which in my opinion is still too high)

Anyways all the uploading I did many times and always got similar results .

A couple of uploadings to the main Grid was the same . And also with a new download of Blender 2.68 didn't help.

Does anyone have any idea why this is happening .

I have put my .blend file here :http://www.pasteall.org/blend/24534  perhaps someone would be kind enough do a test upload. The Skeleton is on layer 1 (Physics box on layer 6) and the test rings on layer 5 ( physics shape on layer 10 )

Im using Blender 2.68a r58537 and the SL viewer Second Life 3.6.7 (281793)     Mesh Sandbox 22

 

Just edited to add tested with a single ring and same problem when set to smooth shading :

 

 Hmmmmf !  Now i'm going to bed .

[Pamela Galli]

Wow that is bizarre. I can't believe that smooth shading would have such an extreme effect, but looks like it does.  

 

I will upload with Singularity and see what happens.

 

ETA:  Link does not work.

[Aquila Kytori]

hi

Normally the LI will be lower for a mesh set to smooth shading than the same mesh with all Flat shading . But not today and now i'm very tired so need to sleep .

And thankyou for Uploading,   I'm expecting it to be ok for you. I think it has to be  something wrong my end .

 

Edited to add: just rechecked and Link is ok for me 

 

      http://www.pasteall.org/blend/24534

[IvanBenjammin]

Well, just from looking at the tri/vertex counts it seems to me your low and lowest LODs are far too high. In your last upload where you got the land impact down, I can see the lowest LOD has 40 tris instead of over 1000.

Are you creating your own LODs or is the uploader generating them for you? If the latter, I'd say that's your problem. For some reason, it seems the uploader (in this case, anyway) has better luck reducing the tri/vertex count with flat shading. You can see that in your successful upload, your high LOD has a higher vertex count, but the lowest LOD is greatly reduced.

 

 

[Pamela Galli]

Yes that linked worked.  This is what I got with Singularity:

 

 

 

[Drongle McMahon]

Can you give use the dae files for the single ring for smooth and flat?

[Drongle McMahon]

No need for the daes,,,.

I get similar results with Blender 2.66a. I did some experiments with one of your rings. It seems to be about the missing UV map. This is very odd, and I think it's new behavior. With no UV map, or with a UV map collapsed to one point, it would not reduce the vertex/triangles in the autoLOD meshes. With even two points in the UV map (ie half collapsed to one point, the other half to another point) it did the normal reduction.

Now maybe a clue about where this came from... There used to be a bug (can't find the jira) where a missing UV map caused the uploader to used uninitialised data, giving random UV maps, so a model could be textured differently each time it was uploaded. Now I find that each time I upload my test model for this, it all gets textured with the same pixel. So maybe they fixed that to use all zeroes instead of random data. That would explain why it behaves the same as with the UV deliberately collapsed to a point. That doesn't explain why the single-point UV map should cause the GLOD LOD generator to fail to do anything, but it looks like this must be the case.

Sure enough, If I make a UV map for your skeleton the autoLOD works as expected. So that's what you need to do. If I then collapse the UV map to a point, it goes back to the same numbers as before adding the UV map. I think they should make a missing UV map an error that aborts the upload, but if not then they should fix this effect on the LOD generator.

I will do a jira for this, using my oddly mapped versions of your ring.

ETA - uh-oh, not quite that simple. My model for the random UV bug (a subdivided cube transfomed to a sphere) doesn't show the LOD count effect. When it.s collapsed to a point, it still generates the expected LODs. That's like some of the skeleton, I guess, where some of the geometry gets reduced but then it hits the stop. So it;s not just the missing UV. It's a combination of that with some aspect of the geometry (and the smooth shading!). Will need more experiments before a jira, to try and identfy what aspect.

 

[Drongle McMahon]

Here's a picture of the auto-generated lowest LOD of the skeleton inworld for (left-to-right): Smooth shaded, point-collapsed UV map; Smooth shaded, normal UV map; Flat shaded, point-collapsed UV map. Something has gone badly wrong with the LOD generator.

[Aquila Kytori]

Thanks for taking the time to look into this .

Today in Blender in a new file I created another ring ( 16 verts 1meter dia, extruded it inwards, selected All and extruded up to make a solid ring ) and then exported 4 different versions:

   Ring Flat shading and Not unwrapped

   Ring Smooth shading  Not unwrapped

   Ring Flat shading , UV Unwrapped

   Ring Smooth shading , UV unwrapped

and noted the upload results :

As you suggested UV unwrapping corrects the problem .

I tried the same experiment with an Ico sphere and there was no  problem with the Uploaders generating the Lower LODs .

I tried creating a similar size ring but starting with a Plane (4 vertices) and using the Spin function from the tool shelf : this ring had the exactly the same problem as above  and again was ok when unwrapped.

And then again with a " square ring" set to smooth shading and not unwrapped , same problem :

 

Next with a Torus , cross section of 6 vertices, small problem with lowest 2 LODs :

 and same Torus with 2 edge loops (inner most and outer most) deleted to give it a square cros section :

And finally I Tried a torus with a cross section of only 4 verts ( minor segments 4 ) :

 

So the uploader doesn't like smooth shading on 90° angles ! ? 

In the past I have uploaded many, most meshes without Unwrapping and never noticed this before ?

Seems bizarre to me , a combination of  faces meeting at 90° angles, ( should really do some tests with lower , acute angles , for example star shaped cross sections and set smooth, but  i'm not in the mood to do more at the moment ) smooth shading and a mesh that isn't Unwrapped should be causing this .

 

 

[Drongle McMahon]

That's the same sort of thing I am finding. I did a series of toruses with major and/or minor segment ncounts varying from 3 to 24. Too many results to list here, and it's very unclear what the effect is, as some combinations are more resistant to the LOD gemeration than others, and it's not simply regular. It is certainly only happening when there's no UV map or the map is collapsed to a single point, and only when it's smooth shading. It is also very dependent on the closed toroidal geometry. If you split even one vertex (on some of them at least), the effect goes away. That spoils the smooth shading, but where that's tolerable, that gives a work-around. Best of course is (a) always unwrap (b) make your own LODs.

I am completely puzzles as to how having the UV map stops the effect. I suppose the GLOD functions are trying to make the UV map fit as well as the geometry, but then you would think it was easy if all vertices mapped to the same UV point - they still will in the LOD mesh. Can't see how the flat shading escapes it either. Oh well....

On reflection, I think we have to regard this as an unavoidable quirk of the GLOD library with un-uv-mapped toroidal geometry, and therefore expected behavior and not a bug. The work arounds are easy and really required for best practice anyway. It was an interesting find, all the same.

[Aquila Kytori]

ok, thanks again 

At least now I know how to avoid those unexpected high LI counts and can get back to what i was doing .

OOOOPs ...I just  noticed the LI count, highlighted in  in the last image i posted was due to not having a Physics shape !

[Cay Trudeau]

I had this same problem, mine was solved by clicking 'remove doubles'