Normals not flipped but still showing in the wrong form on Secondlife

[adamBRJ]

Hello  i have been trying to upload this simple mesh  frame i made on blender ... i have checked the normals and backcullin ... its all good ! but when i try to upload inworld it shows me this !

 notice how some of the faces arrent showing ? thats exactly the issue ! cause on blender its showing fine but inworld it doesnt ! any help would be greatly appreciated 

 

[Drongle McMahon]

I think you should uncheck "Generate Normals". If you find it checked when you try again, click the Reset & Clear button.

[adamBRJ]

i just did,  and its not that ... the frame from the back looks okay but the front always the same ... :matte-motes-crying:

[Drongle McMahon]

Can't think of anything else. Would probably need the dae file to diagnose further.

[adamBRJ]

thank you for your reply ... yea i just dropped  it ...  i'll keep practicing ... since it makes perfect ! 

[arton Rotaru]

Could be more than 8 materials on a single mesh.

[adamBRJ]

i think that was it thank you for pointing that out but i guess i didnt know what to do cause whenever i used one material for 2 spots .. when i went inworld and tried to drag and drop  a texture in a single frame ... the spots i used the same material on both take that texture if it makes any sense ... 

[Drongle McMahon]

Yes. Materials correspond exactly to "faces" in SL. They don't have to be contiguous faces of the mesh. So a single texture can appear in separate patches if the material does so. It is annoying that the uploader simply ignores anything beyond eight materials instead of flagging it as an error and preventing the upload. You would imagine that would be trivial to implement.

[arton Rotaru]

A solution for this is in the Project Importer Viewer. Meshes with more than 8 materials will be splitted into multiple meshes on upload, instead of discarding the faces.

http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Project_Importer/3.7.25.298441

@adam,

for now you would have to split the mesh into pieces yourself, with no more than 8 materals on each.

 

[Drongle McMahon]

"Meshes with more than 8 materials will be splitted into multiple meshes on upload, instead of discarding the faces."

Oh dear. I think that's an absolutely terrible solution. Any automatic splitting is bound to be as useless as the automatic LODs and automatic physics shapes. That will only benefit those uploading other people's inappropriate stuff stuff they don't know how to fix. Far better to make it an error, so that the user can make sensible decisions about how to split or how to reduce the material count. Then there's the >174752 triangle mesh problem. Instead of the obvious problem with holes in the mesh, now people will be able to upload unlimited triangles and end up with huge numbers of objects. The last protection against multi-megatriangle meshes is gone (unless they have finally got round to fixing that bug). I have resisted using the project viewer so far. I guess I'll have to try it so I can complain offer informed comment.

PS. Oh dear again - what's the point of putting the jira links in the wiki when we are not allowed to see them? :smileymad:

[Drongle McMahon]

Hmm. Couldn't resist testing with some high triangle count meshes. Something has changed, but it's the same in Importer project viewer and release viewer. I now can't upload a mesh with >=167184 triangles (DAE parse error, no extra info in log), although I can upload one with 167012 triangles. This means I can't test whether the the >174752 tris now leads to splitting into multiple objects when the 8 material limit runs out (there are other ways to test - I will try them later). However, the secret creation of new materials seems to be the same as it always was - the 167012 tri mesh had 8 materials (count in new logged data) although the dae only had one.

[Drongle McMahon]

Oh dear, oh dear, oh dear. It's even worse than I suspected. I made a plane with 65536 triangles, then assigned eight materials, seven (indices0..6) in quite narrow stripes and the last for the remaining 55040 triangles on the right. I expected the first seven materials to make a face each, then the mesh to be split when the eighth material's triangle count reached 21844. That would leave 55040-21844 = 33196 triangles in the second object, all from the part with the eighth material. That object should then have been split into two materials, as it would reach the 21844 limit just once. So the eighth material is expected to be split into three faces - 21844 triangles in the eighth face of the first object, and the crest in two faces of the new object.

Well, it was indeed split into two objects, but the second one had all the triangles with the seventh material as well as some from the eighth. So the eighth material was split into three, as expected, but only one of these was in the new object and two were left in the old object.

In addition to the fragmentation that I reported years ago (this depends on triangle order, and therefore on the authoring too and its exporter), which you can see in the picture, some problems where recolouring selected faces spill onto others were also still there.

The picture shows (parts of) the two objects after they have been unlinked and dragged apart, fullbright against a black background. The dashed blue lines are the edges of the objects. Each face has been coloured differently, although there is no rational correspondence between the shared colours in the two objects. The numbers show the zero-based index of the materials in the Blender materials list (0-6), the seventh being all the rest to the right, which is fragmented into triangles. Black areas inside the boundaries are holes through the mesh.

There is one good thing about this - the persistence fragmentation effect may successfully discourage people from the excessive triangle counts that this change otherwise encourages. However, this may not affect meshes made with other software if their triagle ordering is positionally based.

ETA. It's possible to infer from the numbers of triangles in each "face" that the last materials triangles are added in the order of all upper right triangles followed by all lower left*. That means these triangle lists became first the second material of the second onbject, then the grey-green of the first object, and finally the pink of the first object. Why the uploader then decided to split them into objects in the order it did, instead of splitting off the last ones, is a mystery to me. I think inspection of the source code might be the only way to work that out. Not sure I can be nothered to do that!

[arton Rotaru]

I knew you would beat the viewer to death. :matte-motes-sunglasses-3:

 

[Drongle McMahon]

I put in a feature request asking for the >21844 tris per material to be an error that blocks upload. Otherwise we can look forward to lots of "what shattered my mesh to pieces?" instead of "why is my mesh full of holes?" from the subdivision fans. :matte-motes-impatient:

[arton Rotaru]

Good idea putting in a Feature Request. :matte-motes-smile: Since apparently fixing long standing mesh bugs is beyond the scope of this project viewer. :matte-motes-dead:

[adamBRJ]

thank you all  it was a bad  build i think so i just deleted it and started working on  it again we'll c what happened