Only support convex polygon?

[wxfred]

Is there any plan to support concave polygon without hole?

[kaisalmen]

Hi @wxfred could you elaborate more what you mean?
Do you have an example .obj file showing your problem? Thank you

[wxfred]

Search earcut on npm, you will know what i mean.

[kaisalmen]

That is a triangulation library. This is a loader for the OBJ file format which describes triangles/mesh data, etc.
Are you talking about a post-process? What is your idea and please describe it? Thanks

[wxfred]

The obj file exported from Blender may have some concave polygon faces, unfortunately, your obj loader will parse it with some errors.

the correct triangulation should be like this

So, do the triangulation by using the earcut will be nice.

[kaisalmen]

Ok, thank you. That's something I can work with. I wasn't aware there is specific problem. So, either the OBJ contains errors or the OBJLoader2 does it wrong (more likely).

[kaisalmen]

@wxfred #74 should fix this problem.
I have published a preview version based on the PR:
https://www.npmjs.com/package/wwobjloader2/v/6.0.1-next.0

Please, let me know if this works as expected. Thank you for reporting the issue.

[kaisalmen]

I searched npm, found your package, thought you may have the ambition to implement a full-featured obj parser, maybe I was wrong.
It's up to you.

Like many other OBJ parser this parser is not fully featured (e.g. free-form curves), but with regard to standard polygonal mesh related things it does a fairly good job (this is a spare time project).

The important point here is that the faces description in the OBJ specification (http://paulbourke.net/dataformats/obj/) only allows to specify triangle fans. Do you have any other information I am not aware of? There is no way to distinguish between concave and convex polygons in the OBJ file that's why you have to use triangulation before exporting as suggested above OR
we could make this library depend on earcut and add a parser option to use it.

Feel free to offer support and open a PR. Thanks

[wxfred]

I didn't see any fan description in http://paulbourke.net/dataformats/obj/, pls paste them.
If there is a fan statement in obj format standard, I will admit I was wrong.
Whatever, Blender supports importing concave face obj without triangulating, I think concave parse supporting is really helpful.

[kaisalmen]

You build faces from referencing other things, like vertices, uvs and normals. This the simplest case with only referencing vertices:

f 1 2 3 4 5 6

All cases here: https://github.com/kaisalmen/WWOBJLoader/blob/main/packages/objloader2/src/OBJLoader2Parser.ts#L396-L435).

You build the following faces/triangles 1,2,3; 1,3,4; 1,4,5; 1.5.6 from that. The spec doesn't give you any further hints regarding ordering or structure of the data. So from just looking at what you see, you cannot derive a higher ordering/structure or whatsoever.

Blender seems to interpret the data the same way when exporting and importing again, but that doesn't help you with other software if the spec isn't specific about it (this is independent of OBJLoader2).

OBJ format is super old. Are you using it for a specific reason? Doesn't it make more sense to move to GLTF these days if your starting point is Blender?

[wxfred]

I don't think f 1 2 3 4 5 6 means you should convert this face to triangle fans. In OpenGL, you can use GL_TRIANGLE_STRIP (same as THREE.TriangleStripDrawMode in three.js) to present some kinds of concave face.

You assume f 1 2 3 4 5 6 in obj file should be parsed to GL_TRIANGLE_FAN, but in my opinion the f 1 2 3 4 5 6 in obj file is only describe a face surrounded by p1 p2 p3 p4 p5 p6 with a clockwise or counter-clockwise order. This is the point where we disagree with each other.

And, yes, in my recent project, I use obj to do some other things, like physical calculations, I didn't choose GLTF because some CADs is not support this format.

[kaisalmen]

@wxfred feel free to propose a PR that adds an option for altering the interpretation (fans or strips) of faces.
Use "Triangulated Mesh" as workaround for now.