#8 OBJ: Add support for p and l elements


Please add support for rendering point and line primitives (e.g. loaded from OBJ files).


  • Hi -

    can you elaborate? Assimp does support reading of line and point primitives and its viewer application will render them (at least the lines, I'm not sure about points).

    Or are you referring exclusively to OBJ?

    Bye, Alex

  • I'm referring to OBJ in particular. As the viewer did complain that "aiScene::mNumMeshes is 0" when loading an OBJ with only points and lines, I assumed the OBJ loader is not capable of parsing the "p" and "l" elements. And as the viewer statistics only show "Verts" and "Faces", but no "Lines", I assumed the library itself might not be able to handle line primitives.

    • status: open --> closed
  • Re-opened, changed title, this is an Obj specific problem.

    • summary: Support for point and line primitives --> OBJ: Add support for p and l elements
    • priority: 5 --> 6
    • status: closed --> open
  • Added support for p and l elements: r1070. More test coverage would be good to have.

    • status: open --> pending
  • I'm be happy to test if you could provide a snapshot build of the Windows viewer application.

    • status: pending --> open
  • Works great, thanks a lot! The only thing that's a little bit confusing now is that points / lines are listed as faces in the statistics and in the model tree view. Maybe just replace "faces" with "primitives"?

  • I just found an issue: When opening an OBJ with point and / or line primitives, "Export" -> "Wavefront OBJ format" does not work correctly. Instead of points / lines, it always exports (degenerated) faces.

  • r1074 implements this. I uploaded a new binary at the same location.

    • status: open --> pending
    • status: pending --> open
  • Thanks again. It works perfectly for points, but for lines the export is suboptimal. Almost all vertex coordinates are exported twice, and line strips are exported as single lines. For example, instead of

    v 67.3816 161.476 -24.1538
    v 68.0594 161.09 -23.5353
    v 68.0594 161.09 -23.5353
    v 69.2883 160.942 -22.7824
    l 1 2
    l 3 4

    you should export

    v 67.3816 161.476 -24.1538
    v 68.0594 161.09 -23.5353
    v 69.2883 160.942 -22.7824
    l 1 2 3

    As a side note, there are always two spaces after the character denoting the primitive, e.g. "v<space><space>1.0 1.0 1.0". Would you mind just using just a single <space>? This would simplify comparing the exported OBJ files to reference files.

  • That's a general limitation of the Obj exporter at this point. Since we need to expect arbitrary input data, all exporters will need a vertex merging step - unfortunately, the requirements vary across the formats, but I still want to implement this centrally. So strictly speaking it's not an Obj issue anymore.

  • (What is Obj-specific is to merge multiple lines into strips ... but that doesn't make sense unless the big issue is resolved)

  • OK, got it, thanks for the explanation. So, from my point of view, only two minor aspects (which are slight unrelated to the issue's title) are missing to close this bug:

    1) the "<space><space>" issue,
    2) the "faces" with "primitives" issue.