Is there such a thing as child faces?

[Carl Kondor]

As the topic asks "Is there such a thing as child faces?", lemme explain in greater detail...

Yesterday I uploaded a mesh to the Beta grid to test if the faces were assigned to the correct materials which they were making the mesh in question looking like it's suppose to with the textures selected. However when I went to test the behaviour of the scripts that I was planning to add to it I found a odd behaviour in one of the faces.

If I changed face A to glow, face B would also glow (with a slight delay), however if I disabled glow on face B, face A would remain on glow, showing a kind of parent-child relation in which the child emulates the parent but not the other way around.

This got me by surprise not only because the original blender materials were different but because I never was aware that such behaviour could be possible within SL. Could this be a beta feature within beta grid or my blender project had some kind of topology that I wasn't aware of that I might have done by accident?

[Drongle McMahon]

This sounds interesting. The only circumstances where I have consistently seen this kind of behaviour before is where the mesh uploader has generated "secret" new faces when the triangle count for a material exceeds 21844. In that case, the "secret" faces can be selected separately, and colour changes applied to one of them affect all while colour changes to the others affect only themselves. From looking at the source code, I think the "secret" faces get the same name as the one in the collada file that had the excess triangles. So I speculate that it's the shared name that somehow leads to the observed behaviour. I have no evidence for that though. From you description, this is not the same effect, because you indicate that you made the affected materials deliberately, but I suppose it could be related.

Perhaps it would be easier to think about this if we had more information about your model - number of objects, number of materials, number of triangles in each material, names of materials. Also, it might depend on what software the mesh was made with. Other questions are whether the behaviour you described in consistent, because viewer-server communication delays can sometimes produce intermittent effects like this, and whether it also affects face properties other than glow. Does it happen only when changes are scripted, in which case it could be an LSL problem, or does it also happen when you change properties using the edit dialog? Finally, can you reproduce it on a simplified mesh?

 

[Carl Kondor]

The mesh was exported from blender. in total has 51k verts and 48k faces. The materials in question have a minimum ammount of assigned faces (each material has less than 100 faces assigned). This behaviour I've tested using basic SL edit, not actual scripting as you can see in the video. The viewer I'm using is latest Firestorm x64 but it also happens in Singularity Viewer. I wish I could reproduce this behaviour as this has a lot of potential. I'm no blender guru so I wasn't able to spot anything that could indice what causes this behaviour thus I thought about asking here.

[Drongle McMahon]

No obvious clues there then. Does any of your materials have more than 21844 triangles? (maybe the main bodywork?)  Note that's triangles, not polys - the uploader triangulates everything before it uploads it. If it does, then maybe the "secret" material effect modifies the behaviour of the whole Material system and not just the affected materials. You could check this by uploading a version after deleting geometry until all meterials are less than 21844 triangles. If you see the behaviour with 21845 and not with 21843, that would be pretty conclusive. By the way, this jira has the initial observations on this effect of triangle counts, if you are interested.

ETA: The simple workaround is to split the sets of faces with more than 21844 tris and give the parts different meterials but the same textures. I think you have used all eight though (number 7 in edit dialog), in which case that solution isn't available.

[Carl Kondor]

I do have a spare material I could use, but I'll just delete some faces from the interiors and test the behaviour since it exceeds that 21k limit. I'll reply once I get test results from it. Although this is a unwanted behaviour, it could be exploited to some nice uses if done right.

[Drongle McMahon]

The trouble with using bug/undocumented behaviour is it just might get fixed. Still, this one has been there for quite a while.

[Carl Kondor]

Yeah that's what happen, another thing I found in the process is that when you exceed that limit you can only use 7 materials instead of 8 and the 7th material always copycats 6th. Well if you say it has been aknowledge for quite sometime then I could perhaps give it some use if I see that I have a spare material. The fact that face imitates the other one could be use to save some scripting time and instead replacing with that "natural" topologic behaviour. Atlhough being it a techinal limit as in 64k faces limit per mesh it could never be fixed if it is a COLLADA~SL limitation and not a bug that could be fixed.

[Gaia Clary]

Blender does neither support child faces nor child materials.

I remember that i have seen some weird behavior when the mesh contained many duplicate verts AND more than 21844 faces (triangles) on one material . Then the material assignment sometimes becomes completely weird and it may look like material inheritance does happen.

[Drongle McMahon]

"...as in 64k faces limit per mesh it could never be fixed if it is a COLLADA~SL limitation and not a bug..."

It's not a limitation of Collada, nor really of SL. It's certainly an unintended effect of the code in the uploader functions. In fact, the intended limit is 64k vertices (not faces), as stated in both the wiki and the source code, which is supposed to raise an error if it is exceeded. However, that limit is never reached because the limit on the number of triangles is necessarily always triggered first. That creates the new "secret" material, resetting the vertex counter in the process. While the 64k limit on vertices is a necessary consequence of the internal data format (vertices are referenced by 16-bit indexes), I could not see why the triangle count is so limited. The list of triangles (three vertices each) is kept smaller than 64k by the triangle limit, but there doesn't seem to be any need for 16-bit indices for that list. So it does look like a bug that could very easily be fixed, by modifying only the viewer code. However, experience tells us that this doesn't mean it will be fixed even if I am right there.

The "secret" material(s) does indeed count as one of the allowed eight, so that it can affect the number of other materials you can make. There is a development viewer [Project-Importer] that is supposed to allow more than eight materials. It does that by splitting the mesh into separate mesh objects, each still limited to eight, which become a linkset on upload. However, the interaction between this mechanism and the "secret" material generation is, as you might guess, horrendous. For example, a mesh with eight materials can get split into two meshes with half of the mesh faces in one of the materials haphazardly allocated to different objects. So I don't know if this will ever appear in a release viewer.

 

[Drongle McMahon]

I have to update what I said because the Project-Importer stuff has now been added to the latest release viewer. This changes things considerably. You can now upload mesh objects with more than eight materials. They will get split by the uploader into separate objects, each with no more than eight materials, which will appear as a linkset inworld. The worst bug, where you could get a single material split between object if it had more than 21844 triangles, appears to have been fixed, so that the split will always put the whole of a material into one object*. Of course the LOD switching of the linked objects is independent. So you will get uncoordinated LOD witching. Obviously you can control this better by doing both material and object splits yourself, rather than leaving them to the whim of the uploader.

Unfortunately, you still get problems (failed upload) if you use LOD files where materials with >21844 get split int the high LOD but not the lower LODs. That leads to mismatched "secret" materials which are detected as an error. So the advice to always avoid materials with >21844 triangles still stands.

While testing this, I looked a bit more closely at the secret materials. You can select them separately with Select Face in the edit dialog and they behave exactly with the parent-child relationship. If you change anything on the parent, it gets changed on the child too, but if you change the child, the parent is unaffected. If you set the child (secret) face to a different colour, a script that uses face numbers to report the eight face colours does not report the colour you can see. It appears that the script can only see the parent face, not the secret face. My guess would be that that's the same for setting properties as well as reading them. So the secret face seems to exist for the edit dialog, but not for LSL.

I have no further ideas about when or why other faces would be affected too.

*Don't know what happens if there are >43688 tris - presumably that still gets split within material?

[Drongle McMahon]

"...what happens if there are >43688 tris.."

I made a seven times subdivided cube, which has 196608 triangles all with the same material. Sure enough it gets subdivided into two objects when it has used up all eight slots with secret materials. Because of the way the subdivisions are implemented in Blender, this makes two "Serpinski" objects. Here they are unlinked. We used to get just the one on the left. Now we get the holes too. More fun for the subdivision fans. Child faces on the left one are coloured in the closeup. Red is the "parent" face.



The one on the left gas one "parent" and seven "child" faces. I played a bit more with these. It seems changes to the object other than to the textures can also override the child face properties, including stretching with handles or the edit box spinners, any other "torture", shift drag copying, etc. I am guessing the temporary visibility of textures and colours on the child faces are client-side effects, and that anything that regreshes the server objects causes the parent properties to overwrite them. If that's the case, then the child face changes should be invisible to other observers. There wasn't anyone around to confirm that*. Trying to adjust material properties of the child faces was interesting (normal map, shininess etc.), The changes were visible as long as the child face was selected, but disappeared as soon as it was deselected. So they are less stable than colour etc.

*But it was reverted to all "parent" properties after logging out and back in.

 

[Drongle McMahon]

Arton and Whirly have described another cause for the same parent-child-like behaviour, when spaces in the material names lead to duplicate material names because the Collada dom drops the part after the space. Apparently this was accepted as being a bug, as a fix has been developed (not yet in release viewer). I'm not sure the fix will work, but its existence emphasizes that it is unwise to do anything depending on this effect.