Why write triangles like quads during export?

[Malo]

Good evening everyone,

I ask myself this question for a few years already, without finding a logical answer.
I noticed that the AM export Obj writes the triangles like quads.
That is to say for a triangle ABC, the convention is to write as follows: f A B C
But AM write them: f A B C A, which is the convention of writing quads (f A B C D).
Some programs like Wings3D play them correctly, others like Blender, consider them as bad quads that they ignore, which creates holes and therefore unusable.
I thought this was because the three-sided patches are a variant of the four-sided patches, but I do not understand the usefulness of keeping this writing export that makes it heavier files and that do not make them compatible with any programs.
But seeing changes this done during the past years on the export plugin of obj, without this triangle writing being changed; I tell myself that there is something that I do not know or that I do not see, hence my question: why write triangles as quads?
Thanks in advance for those who will be able to show me the benefits of writing these triangles as well.

 

I ask this question, to know if it would be interesting to request an option to Stephen Gross to correct this problem in the export plugin. Not wanting to post this request if she is stupid.

[Rodney]

I can't really address your question although I could guess at it... but I won't.

 

It'd be worth presenting to Stephen or Arthur Waselek who as far as I know was the original author of the OBJ plugin (there were several export plugins I just assume his was the one deferred to for most uses of the OBJ format). He had stated that he would try to address any issues raised... of course that was a very long time ago.

[robcat2075]

Yeah, I think it's originally Arthur's code. Anyone know how to contact him?

[Malo]

Hi, thank you for your answers.

 

Is the problem not found in the SDK libraries? because the problem is found in the Lwo export.

 

I doubt that the answer is not as simple as rewrite the line of triangles when exporting because it would have been done for a long time. And I am aware that the interpretation of the patches is a real puzzle, seen the number of non-visible combinations that exists. (even if I would like to hope that it is simpler than I imagine)

Here is another problem related to the export and the three-sided patches. Here are the same three-sided patches, copy 4 times, which gives different topologies.
We can see that sometimes the hook is attached to the wrong side. Is it due to the fact that he is lost to know if he is attached to AB, BC, CD or AA?

[nemyax]

HModel::BuildExportModel and HModelCache::BuildExportModel are probably buggy.

[robcat2075]

Do you get a different result if you the model through some other polygon app, like Wings 3D, first?

[Malo]

I think as you Nemyax, but I am not sure.

 

Passing through Wings3D corrects the writing of triangles (without keeping vertices numbers), but does not correct the topology that is internal to AM. Part of the problem of topology does not come only from triangles, but from writing hooks that do not write enough information to know where to attach but try to guess it.

[robcat2075]

Do you need triangle export? What is the advantage over quads?

[Malo]

It is true that the export triangles can provide a solution (without correcting the problem of hooks).
The advantages of quads is multiple : a file less heavy to treat, may subdivide for zoom, or to make it more smooth, or to sculpt details over it, or to apply a displacemant map.

[robcat2075]

Could you export a quad model from A:M, then convert that into a proper triangle model in another App?

 

Does Blender or other 3D modeler have a button to convert quad meshes to triangle?

[pixelplucker]

Are those actual missing faces or are they the result of a flipped normal on the patch? Winding order on the exporter might be causing flipped faces that some programs may have trouble reading in. Usually any models I have exported from AM out as quads to use in other programs I use the other programs to do the subdivision when possible (doo sabin is closest to AM smoothing).

[robcat2075]

That is to say for a triangle ABC, the convention is to write as follows: f A B C

But AM write them: f A B C A, which is the convention of writing quads (f A B C D).

 

 

Crazy idea... could a small text macro be written to strip out the second A and just leave f A B C?

[robcat2075]

I made simple model to export and when I look at the triangles only OBJ it only has three edges to each face, not four.

 

Where does the four problem come up?

# OBJ - Exported from Animation Master
# 1OBJ

mtllib ModelTris.mtl
o ModelTris.OBJ
v 5 15 0
v 5.96244e-08 15 5
v 1.78873e-07 10 15
v 15 10 0
v 1.13247e-06 10 -15
v 3.77489e-07 15 -5
v -15 10 -2.26494e-06
v -5 15 -7.54979e-07
v 2.38498e-07 -0 20
v 20 -0 0
v 1.50996e-06 -0 -20
v -20 -0 -3.01992e-06
# 12 verticies

vt 0.00000 1.00000
# 1 texture coordinates


g default
s 1
usemtl UnKnown0
f 1/1/1 2/1/2 3/1/3
f 3/1/3 4/1/4 1/1/1
f 1/1/1 4/1/4 5/1/5
f 5/1/5 6/1/6 1/1/1
f 6/1/6 5/1/5 7/1/7
f 7/1/7 8/1/8 6/1/6
f 8/1/8 7/1/7 3/1/3
f 3/1/3 2/1/2 8/1/8
f 4/1/4 3/1/3 9/1/9
f 9/1/9 10/1/10 4/1/4
f 4/1/4 10/1/10 11/1/11
f 11/1/11 5/1/5 4/1/4
f 5/1/5 11/1/11 12/1/12
f 12/1/12 7/1/7 5/1/5
f 7/1/7 12/1/12 9/1/9
f 9/1/9 3/1/3 7/1/7
# 16 triangles

[Malo]

This missing faces it is not a problem of normal inverted, but of interpretation of a triangles written like a quads.
It seems to me that the problem comes from the fact that the three-sided patches are not a triangle but a four-sided patches whose one side is zero. That's why the quad topology focuses on one of the corners and not the center of the patches. The dynamic subdivision of AM does the rest, it eliminates the quads whose volume is almost zero, a flat quad is zero, it eliminates it. on the other hand, if a quad at a null side is volume it is not zero, so it remains. AM only manages quads inside a patch.
Yes it is possible to create an external tool to correct the triangles of files exported by AM, but it seems to me that it is better to correct at the source.
Here is a model where there is a 4-sided and a 3-sided patches, move the CPs for the differentiators.

MODEL

[robcat2075]

Is the problem that "Remove degenerated faces at export" isn't removing triangles?

 

 

Are these red bold line unneeded triangles?...

 

f 1/1/1 2/1/2 3/1/3
f 3/1/3 1/1/1 1/1/1
f 1/1/1 3/1/3 4/1/4
f 4/1/4 1/1/1 1/1/1
f 2/1/2 5/1/5 6/1/6
f 6/1/6 3/1/3 2/1/2
f 3/1/3 6/1/6 7/1/7
f 7/1/7 4/1/4 3/1/3
f 1/1/1 4/1/4 8/1/8
f 8/1/8 1/1/1 1/1/1
f 1/1/1 8/1/8 9/1/9
f 9/1/9 1/1/1 1/1/1
f 4/1/4 7/1/7 10/1/10
f 10/1/10 8/1/8 4/1/4

[robcat2075]

When I export your model to OBJ and re import it into A:M I see that the triangle on the left, that was made by moving two corners of a 4-point patch together, exported with un-necessary edges, but the triangle on the right which is a real triangle exported without un-needed edges.

 

 

 

 

 

the left triangle has 5 vertices at the top but the right one has only one vertice at the top.

 

 

[robcat2075]

 

Are these all from the same A:M model or is each one different?

[Malo]

Robcat,

 

Yes, "f 3/1/3 1/1/1 1/1/1" is not correct. It's a flat triangle, it will not be visible. Fot me their writing lulls the file and does not bring any interest.

The import of AM is a step that is not to do with the subdivision of the patches, however it remains interesting to study how the import interprets the writing of triangle-quads export by AM. if we look at the file export in a text reader, we see that there are only quads.

 

The model is the same crtl / copy four times in the same file. So the order of writing the triangular patches is not the same. Hence the difference of topology.

It is by modeling the foot of this dog that I noticed this problem:

[robcat2075]

What might you propose as better subdivision of the triangular patch?

[robcat2075]

I think I recall you or someone talking about this previously and proposing that 3-pointers be subdivided like 5-pointers are...

 

[Rodney]

On that image of the bottom of your dogs foot.

I doubt it would matter but the thought occurred that I would generally not want that 3 pointer to be on the outside edge of the foot like that (for export purposes).

Would anything change or become any more optimized if you connected those two outliers creating four point patches on the outer rim and thus driving the three pointers further inward toward the center?

 

The added issue is that you have unnecessary hooks at that location.

I realize that you said that is just the case that brought the matter to your attention but that's the thought that occurred to me.

[Malo]

Hello Robert,
Yes, the ideal for exporting triangular patches into polygons would be this topology. Now I doubt that we will not rewrite a polygonal subdivision express for export. But I thought it would be possible to filter its triangles-quads to rewrite them into triangles.

Hello Rodney,
The proposal (left back foot) is good to avoid the problem of hooks, only does not solve the problem of triangles-quads. The best solution in this case would be to turn the hook into a CPs for export (see the front left foot). There I had to think about it before, because I have to redo the UVs.

Hooks and triangles are two differents problems.
What is strange to me is that this bad topology in AM is not seen, whereas when we push the creation of weird patches with the hooks, it is seen in general as for the following image.

[Malo]

Among the strange patches, there is this case in yellow. the subdivision is not done in x16 in AM, it is different from its mirror patch, and there is a bug to the export of this patch, but its subdivision is done.