Why am I getting a high tricount warning after exporting avastar DAE?

[Antumbra]

I keep getting this high tricount warning after exporting my model as avastar DAE. Why is this? There's only 23k triangles why is it saying it's a high tricount? how can i remove this tricount warning?

I get this warning after merging 2 of my objects together. why is that? am i merging them incorrectly?



The triangle count has a green check mark when I select one of the objects.



then when I merge the 2 objects together, the triangle count doesn't have a green check mark anymore, it has a warning symbol. Why is this? I merge the objects by using CTRL+J

[Aquila Kytori]

Hi

I'm guessing it is because you only have one material in your mesh Object?

The maximum number of triangles per material is 21844 and by joining the two objects you now have exceeded this limit.

Quoting from :   http://wiki.secondlife.com/wiki/Mesh/Technical_Overview

 

" 65536 vertices per texture Face

21844 triangles per Texture Face.

Note: there is a caveat here:

Whenever the triangle count of a Texture Face exceeds the limit of 21844 triangles, then the SL Importer automatically creates a new texture face, thus it automatically fixes your mesh when the triangle count per face gets too high. Actually the Importer creates as many texture faces in chunks of of up to 21844 triangles as needed for your model. "

[Gaia Clary]

The warning symbol (the blue circle with the "i" in it) in the Mesh Info Panel is meant to show a popup box with a detailed explanation about what's up. However this text was missing. Here is what should be seen when you click on the ( i ) icon and i hope this gives a reasonable explanation for why this is flagged as problematic (This text will be added in the next Avastar update):

---- Begin of text ----

At least one Texture Face with high Triangle count (nnnnnn).

DETAIL INFO:
In SL any Texture Face has a limit of 21844 Triangles.
If a texture face uses more than 21844 Triangles
The SL Importer automatically splits the face into subfaces.
And each subface is treated by the SL Importer as one extra Material.
This can lead to unexpected results:

More than 8 materials
If a Mesh has more than 8 materials the entire mesh gets split into submeshes.
You might want to avoid this.

Missing Material in LOD
When you let the SL Importer generate LOD, then it may end up in a weird state
where it calculates different Material counts in the lower LOD's
which results in an Importer Error.

YOUR ACTION:

• Reduce the number of Triangles in your Mesh
• Take care to create texture faces with less than 21844 triangles

---- end of text ----

If anybody believes this text can be improved, feel free to correct me :matte-motes-sunglasses-1:

[arton Rotaru]

FWIW, the 21844 triangle limitation doesn't apply to files exported with autodesk software. I guess this is just an issue with exported files from Blender, or let's say, the limit appears with collada files that have <polylist> attributes instead of <triangles>.

[Drongle McMahon]

ETA: red->green edits made when Arton de4tected a mistake.

This is quite true. There is an explanatory note in a comment on the BUG-1001 jira. The relevant line of code is different in the two functions that are used to load the dae file data...
In the <polylist> function, it's
if (indices.size()%3 == 0 && indices.size() >= 65532)

In the <triangles> function it's
if (indices.size()%3 == 0 && verts.size() >= 65532)

In either case, if the result is true, that triggers the new secret material. The "indices" list is a list of indices into "verts" list of vertices. Every triangle must have three entries in the "indices" list, one for each of its vertices. This means that the <polylist> function always triggers the new material after 21844 triangles. However, entries in the "verts" list can be shared between multiple triangles, as long as the position, normal and UV coordinates are the same. This means the limit in the <triangles> function depends on the extent of sharing of vertices between triangles. For an extended sheet of smooth shaded triangulated quads, I think this is about two triangles per vertex. So the limit would then be reached at 43688 triangles 65532 vertices, which would be 131062 triangles!. So in general, the trigger for a dae file using <triangles> should be one to two three to six times higher than the 21844 triangle count for the <polylist> file. In any case, the 65532 limit will still be reached before the 65536 vertex limit which raises an error. So the extra secret material effect should still happen eventually.

Having said that, I haven't experimented with <triangles> since abandoning Blender 4.x, which used them. So some experimental (in)validation of these statements would be worthwhile.

There is a third function that loads the data from a <polygons> section instead of the other two. The structure of this code is quite different, and I don't know if or where equivalent limits are imposed. I don't know of any, but the code mentions that some fbx to dae converters use this kind of data.

There's no reason obvious to me why the code should impose these limits on the number of triangles or vertices. Restriction of the number of distinct vertices to 65536 is a requirement of the upload data format, in which the three pointers for each triangle into the vertex list are limited to 16 bits, but these limits are always more stringent*. There aren't any pointers into the triangle table, as far as I know, so there is no obvious reason to limit its length, unless there is a 16 bit counter somewhere I am unaware of.

*except for highly contrived structures with redundant triangles, I think.

[arton Rotaru]

So for triangle lists collada files, the trigger is more, or less unpredictable, at least from an modeling artist standpoint of view? Unless you just make just polygon strips I guess.

[Drongle McMahon]

I guess so, although staying inside the 21844 triangle limit will always avoid the problems with the secret extra materials, because a triangle can't have more than three vertices.

[arton Rotaru]

Yes indeed, above 21844 I meant. I noticed it just recently with a mesh cushion which had 102000 Tris, and ~ 52000 verts (no worries, it was just for demonstration purposes:matte-motes-little-laugh:). Which worked just fine with a single material.

That's quite a few more than 21kTris. :matte-motes-sing:

[Drongle McMahon]

ETA - this was mistaken ... see above

I don't think you can have those numbers without getting the extra materials*. As long as you only apply one texture or colour to the whole thing, you won't see the effects of the extra materials. To see if they are there, you have to activate "Select Face", click on the mesh, and then change the coulor. By clicking on different places, you can eventually make each secret material a different color, as long as it's not the "master" material which will recolour all the others. The patchwork colouring will not be visible to other observers and will disappear if you relog. In tjose cases, the "master" always overrides. If you want to give me a copy of the cusion on Aditi, I would be interested in checking it out.

*That is unless your dae uses <polygons>, in which case I don't know what happens.

[arton Rotaru]

I just hit Ctrl+Shift+Alt+T for texture info. Look, it's just a single "prim" selected, and it's not in face selection mode.

I tried to post the dae file at pastebin, but it crashes my browser. It's 16,1 MB :matte-motes-little-laugh: You can create <triangles> collada files with the free Autodesk FBX Converter x64 2013 though. With exported FBX files from Blender.

I have sent you a copy of the cushion on Aditi.

[Drongle McMahon]

Ah yes. My mistake. The extra material won't be triggered with <triangles> until you get 6532 vertices, not 21844. I edited the post above to give the correct numbers. Your cushion is a bit short of the threshold for <triangles> files. By the way, I didn't get it yet, but it doesn't matter now.

[Gaia Clary]

I could change the Blender Collada exporter to use <triangles> instead of <polygons> when the "triangulate" option is enabled. This seems to make sense. A user could triangulate manually before exporting and then export with triangulation enabled. this should not do any harm when the meshes are already triangulated.

I could also do some optimisation and inspect the meshes before deciding whether to use <polygons> or <triangles>. This seems to make sense as well, but maybe its a bit too much?

Another thought comes to mind: Doesn't this make people believe that higher poly counts become more tolerable? Not sure...

[arton Rotaru]

Thats actually how the collada exporter in 3ds Max works. Polylist with the Triangulate option unticked, and triangles with the option ticked.

If this is good or bad, Idk. At least it would make things more consistant.

[Drongle McMahon]

"Doesn't this make people believe that higher poly counts become more tolerable?"

That would be my worry, as far as SL is concerned. <triangles> also introduce some uncertainty because the threshold number of vertices would depend on smooth/flat shading and UV mapping, while the <polylist> function doesn't vary. However, it would reduce the problem for some users. I would rather see an explicit option, use <triangles> or <polylist>, instead of a hidden response to triangulation. As well as giving more control, that would make sure the results of uploading existing files doesn't change unless the option is selected.

Of course the "correct" resolution would be for the code to be fixed. At the least, the <polylist> function could be based on the vertex count instead of the index count, like the <triangle> function, giving a higher limit. Better still, as far as I can see, these tests could be completely removed. That would mean they no longer pre-empted the 65536 vertex limit, elsewhere in the code, that raises an error and stops the upload. That way the originally intended limit of 6536 vertices per material would be enforced, and the whole secret material thing would disappear, along with the effects it has on objects with more than eight materials. Unfortunately, that would probably also break a lot of existing files. It's also unlikely because the jira has been there for several years without any response.

 

[Gaia Clary]

---

Drongle McMahon wrote:

I would rather see an explicit option, use <triangles> or <polylist>, instead of a hidden response to triangulation. As well as giving more control, that would make sure the results of uploading existing files doesn't change unless the option is selected.

---

From the user's point of view it should make no difference how the tools talk to each other. The only true benefit for using Triangles where ever possible is that the collada files can become a bit smaller: You do not need to record the number of verts per face because this is 3 for all entries.

So i guess it is best to use triangles when the exporter is called with the triangulation option and use polygons otherwise. And then fix the collada importer in the SL viewer. :matte-motes-sunglasses-1:

[Drongle McMahon]

"the collada files can become a bit smaller"

True, although maybe not really much benefit because the collada files are only read locally by the viewer. If you do this, please leave it as <polylist> if the triangulate option isn't selected, even if the mesh is all triangles*. That way it will be possible to triangulate explicitly in Blender before upload and still upload as <polylist>. It's a very long time since I uploaded anything with <triangles>, since the old python exporter. So I haven't got too much faith in the <triangles> function (although I guess Arton has).

There is a more severe problem with the triangulate though, as it destroys custom normals. If you could fix that in the exporter at the same time, that would be great. The Blender people told me there were no plans to make custom normals survive any changes in geometry. So I don't know if that's even possible.

While I seem to be compiling an exporter wishlist :matte-motes-nerdy:, there's the normals from activating Auto-smooth. Any chance of exporting those? It is possible to get them exported by duplicating the mesh and transferring the normals, but that's not exactly intuitive. (I'm assuming you haven't done this already).

*sounds like what you intended - so that should be ok.

 

[arton Rotaru]

---

Drongle McMahon wrote:

(although I guess Arton has).

---

I always have the Triangulate option ticked in 3ds Max's Collada exporter, and never encountered any issues. Edited normals are exported correctly either way with it as well.

[Drongle McMahon]

In Blender, edited normals are also exported correctly, but if you use the "triangulate" option on (or apply some modifiers after the normal-editing ones) make any changes to the geometry after editing them, they get badly distorted (unless the mesh is already only triangles). In general, custom normals are not stable in the face of subsequent changes to the mesh geometry. The "Auto-smooth" thing on its own apparently uses a different mechanism such that the altered normals are not recognised by the exporter functions, but if you copy them onto a duplicate of the mesh, then they use the edited normal mechanism and are therefore recognised.

[Gaia Clary]

---

Drongle McMahon wrote:

In Blender, edited normals are also exported correctly, but if you use the "triangulate" option on (or apply some modifiers after the normal-editing ones) make any changes to the geometry after editing them, they get badly distorted (unless the mesh is already only triangles).

---

I thought we had fixed custom normals issues in the Blender Default Collada exporter. It should export meshes "as is" (with all modifiers applied except the Armature modifier) and take care of custom normals as well. Is there any situation where the Exporter itself exports normals in the wrong way? Maybe there is something missing in Blender or something has changed recently.

When you triangulate a Mesh that already has custom normals, then i believe the result does not preserve the normals. This could be also true when you use the triangulate modifier in the modifier stack. But this is related to blender and not to the exporter.

If you have a demo blend file that shows that a visibly (in the Viewport) intact mesh gets exported with wrong normals, can you create a report on the blender site for this? Please add the keyword "Collada" to the report title. that helps to get those things fixed much faster :matte-motes-nerdy:

thanks

[Drongle McMahon]

Indeed, the distortion of the custom normals is a Blender problem, not an Exporter problem. Last time I tried, choosing the triangulate option on export also distorted the custom normals. Maybe you fixed it since then. I have just avoided the triangulate option since then. Maybe you fixed it. I wouldn't have noticed. I will make sure I've got the latest Blender release and try again, then add the result to this post. Should I use something later than 2.77a?

Here's the results...

1) Square plate with one-segment bevels and normals transferred with Data Transfer modifier from similar plate with two segment bevels with profile=1.0: Triangulate option distorts normals. So does triangulate modifier if it's applied after the Data Transfer modifier, but not if it's applied before. This is the same behaviour observed before.

2) Cylinder with/without either edge-split modifier or auto-smooth, with angle 30 degrees. Now the auto-smooth normals are correctly exported after import into SL. That is new. Last time I tried, it ignored the results of the auto-smoothing.

So I guess the problem with not exporting the auto-smooth normals is fixed, which is excellent, but the problem with triangulation of transferred normals is still there. If there is only a data transfer modifier, that would be easy to fix because the effects with the ordering of the triangulate and data transfer modifiers suggests that it is only necessary to do the triangulation before applying the data-transfer. However, triangulating before other preceding modifiers might interfere with them. So I guess you can't just do it before applying all modifiers. Some more complicated ordering might be necessary. Maybe inserting a triangulation modifier before the data transfer modifier?

For me, it's fine as it is, because I can leave the triangulate option off and either do it explicitly in Blender or rely on the viewer to do it. I suppose others may not be as happy with that.

Here's a picture of the normal corruption by the triangulate option. Option on at left, off at right.



Interesting to note that the triangulation done in the viewer appears not to interfere with the custom normals. So it's not an impossible task.

 ETA: I guess Lithium have completely messded up the image handling. Can't see the normals properly here. Here's a close-up...