Jump to content

LI count, something not right

Aquila Kytori

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

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

Recommended Posts

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  :

Skel UploadLI = 51.png


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

Skel Expected LI .png


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 ? :

Skel ribs LI= 23.png

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 :Test  ribs Smooth shading .png

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

Test ribs Flat shading expected LI.png

Test  ribs Flat shading .png

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 :

Single ring smooth Shading .png


 Hmmmmf !  Now i'm going to bed .

Link to comment
Share on other sites

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 



Link to comment
Share on other sites

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.



Link to comment
Share on other sites

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.


Link to comment
Share on other sites

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 :

bad LOD generations for smooth shading .png

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 :

Ring Square.png


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

Torus 6 verts x-section.png

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

Torus 4 verts x-section edge loops deletred.png

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

Torus 4 verts x-section.png


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 .



Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 7 months later...
You are about to reply to a thread that has been inactive for 3220 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

  • Create New...