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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Re-opened, changed title, this is an Obj specific problem.
Added support for p and l elements: r1070. More test coverage would be good to have.
I'm be happy to test if you could provide a snapshot build of the Windows viewer application.
http://www.greentoken.de/download/assimp_view.exe
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.
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.