Obj with complex faces not loading correctly

[yperess]

Hey, I'm trying to debug this one... I've got an obj that I loaded from Google Poly where the faces aren't being drawn quite right. I think it has to do with the complex faces that it defines. If I find the fix I'll send a pull request but I figured you should know about it. model.zip

[yperess]

Never mind, I was using ObjUtils.convertToRenderable incorrectly (after splitting the object instead of before). Sorry!

[javagl]

Thanks for this hint. I remember trying out this case, namely whether it makes a difference whether one

• first splits and then converts to renderable
• first converts to renderable and then splits

I think it should work also when first splitting and then converting to renderable. I'll try it out with your model and try to figure out where the difference comes from, and whether it can be fixed sensibly.

(Reopening, so that it doesn't get buried (so easily))

[wvc]

Hi,

Not sure if it is related to this issue, but your triangulation code is wrong (ObjUtils.triangulate) . It creates a triangle fan starting from the first vertex, but this doesn't work for concave (non-convex) facets/polygons. It can create triangles that overlap each other. I haven't found a java-implementation of triangulation for concave polygons/facets yet. I've seen some libraries (in c++, javascript) that delegate to an OpenGL method: gluTesselate , which should do it correctly. But no pure-Java implementation yet.

If it is not related to this issue, could you create an issue from this?

[javagl]

@wvc This is probably unrelated to the original issue, but we can quickly talk about this here.

I disagree when you say that the code of triangulate is "wrong". It is not. It does triangulate the face, exactly as described in the JavaDoc:

 * This method will simply subdivide faces with more than 3 vertices so 
 * that all faces in the output will be triangles.

That's the claim. Nothing more. Nothing less.

Right now, the implementation is trivial, and essentially consists of 3 lines of code - it indeed only creates a simple triangle fan. If this is not a satisfactory output, then everybody is free to either use any tool to preprocess their OBJ, or to use this library (free of charge...) to load an OBJ, and handle the non-triangular faces as they wish: They can think about concave polygons, non-planar polygons, degenerate polygons, self-intersecting polygons, non-connected polygons, winding rules, or even try to compute a conforming delaunay triangulation (if the face is planar).

This library is supposed to do one job, and to do it right. And this job is to load OBJs.

^{(The claim that it does this job better than most other OBJ loaders may sound bold. But... let's be honest: That's not such a high bar. Everybody who is concerned with graphics has written some ""OBJ loader"" at least once in their life...)}

Things like the triangulation (or convertToRenderable in general, or the OBJ splitting) are convenience functions that are still simple enough to be justified, considering that basically everybody who wants to load an OBJ wants to render it. But more complex triangulations are a rabbit hole that I certainly won't dive into in the context of this library.

[wvc]

Alright, just wanted to point it out in case it was related to this issue (since it is still open). I came across your library while searching for a Java triangulation library. In the end, I decided to implement an ear-cutting algorithm myself, which seems to work ok for regular, simple polygons without holes. It still produces very slender triangles though (much like with triangle fans), but a refinement step with flipping triangles according to the Delauney criterion should improve that.

There are some nice references here (not affiliated): http://vterrain.org/Implementation/Libs/triangulate.html Unfortunately, most are c++ implementations which hampered my all-Java approach.

[javagl]

(That link is broken in some odd way, but one can copy+paste it).

Indeed, I've recently been looking at triangulation as well. I considered creating a standalone library for that (independent of this OBJ loader). In fact, I created Java bindings for http://www.cs.cmu.edu/~quake/triangle.html quite a while ago, and contacted the author (several times) whether it's OK to publish them, but received no response. A few days ago, I tried to compile the library on Windows 10, and encountered some unexplicable issues, so I'll likely abandon that.

But I still consider to create 1. either a Java library for Delaunay triangulation or 2. create bindings for a more "modern" (C++-based) library, or 3. create a Java port of an existing implementation, like https://doc.cgal.org/latest/Triangulation_2/index.html or https://www.geometrictools.com/Samples/Geometrics.html#Delaunay2D

But again: This would all be independent of the OBJ library (of course), and is nothing that I've scheduled right now - only something of which I thought "yeah, could be nice to have...".

[javagl]

This issue was actually resolved, and only kept open because I intended to do further tests. If I'm gonna do that, it will be independent of this issue.