Menu
Logged-In As
ACCOUNTNot Logged In
Investigate permuted vertex lists from g-iges + iges-gBRL-CAD
Status: ClosedTime to complete:
72 hrs
Mentors: Sean
BRL-CAD has a geometry exporter and importer for the International Graphics Exchange Standard (IGES) file format. If you run our g-iges exporter on some geometry, then run iges-g on that same geometry to import it back to BRL-CAD format, the geometry will have permuted vertex lists. Particularly for geometry already in polygonal format, such as our NMG or BoT geometry, this conversion should result in identical geometry but presently does not.
This task involves investigating why this occurs, reporting (in detail) why it occurs, and if obvious, making a recommendation on how to fix the problem.
Code:
- src/conv/iges
Uploaded Work
| File name/URL | File size | Date submitted | |
|---|---|---|---|
| iges-permutation.txt | 192 bytes | December 08 2013 23:42 UTC | |
| iges-permutation.txt | 309 bytes | December 09 2013 03:43 UTC | |
| iges-permutation_rev2.txt | 824 bytes | December 10 2013 15:20 UTC |
I would like to work on this task.
This task has been assigned to Andromeda Galaxy. You have 72 hours to complete this task, good luck!
The work on this task is ready to be reviewed.
One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to complete this task, submit your work again and mark the task as complete once you re-submit your work.
More details please? It's not clear to me why the container would cause permuted vertices if they are iterated to write them out and inserted back into that same container. Neither the export or the insertion involves anything random.
Also, if you really do understand the issues, please make a recommendation (mentioning file(s) and lines of code) on how to fix it.
Because I cannot find a specification for the IGES file format, I could only look at the existing code; as far as I can tell the faces are written out as a point and a direction vector, and some importation code figures out which vertices are intersected by that plane, though I am not completely sure. This means that the information is intrinsically lost because the file format does not store it; for example, if a triangle was written out with vertices in the order of P1,P2,P3, then the importer does not know this order, because it was never stored in the file.
For the standard, see my comment on IRC (nick maths22). You will need to download the zip of the github repo I referenced.
Thank you for the link to the standard!
Thanks to Jacob B.'s helpfully provided standard, I think that the problem is that write_shell_face_loop outputs the line segments that make up the loop in the wrong order.
The work on this task is ready to be reviewed.
Andromeda, I think you're still missing the mark here. This problem doesn't really have to do with the IGES specification and obviously pertains to data getting read and written differently. That latter is even in the task description. To say that the reason is "one of them is wrong" isn't information we can do anything with to fix the problem.
You say that you think the problem is in write_shell_face_loop(), which resides in src/conv/iges/iges.c and which IS getting more specific, but still not what in detail is actually wrong so that a fix can be devised. From your description, the problem could just as well be in whatever code reads the data back in too.
Note that one can certainly write out vertices/polygons/geometry without ordering information and still retain a consistent order by reading/writing consistently. We know this currently does not work for the g-iges followed by iges-g; they are inconsistent. More than likely one is iterating from start to finish and writing data out (e.g., 1 2 3) and the other is reading from start to finish (i.e., 1 2 3), but pushing into a container that reverses the data (e.g., pushing onto a stack would make that 3 2 1). Alternatively, data is getting written out in LIFO order (e.g., 3 2 1) and getting read back in order (e.g., 1 2 3). Or some variation thereof.
Again, we KNOW they are permuted and it's going to be an inconsistency between a reader and a writer and/or how geometry is getting stored into a data container. This task is to figure out exactly why there is an inconsistency.
Basically, figure out exactly how to fix it and tell us how to fix it. Do everything except fix it. Fixing it will make a great follow-on task.
One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to complete this task, submit your work again and mark the task as complete once you re-submit your work.
The work on this task is ready to be reviewed.
Congratulations, this task has been completed successfully.
Now that's actionable, nice work! A follow-on to this task has been posted: http://www.google-melange.com/gci/task/view/google/gci2013/5833138295013376?validated
You're welcome to claim it or let someone else try, but obviously the first step is to reproduce the issue. Once the issue is observed, then attempts at a solution can be tested. It's likely that the solution is ultimately going to be VERY simple...
I just wanted to tell you that the link that you posted (http://www.google-melange.com/gci/task/view/google/gci2013/5833138295013376?validated) says "this page is inactive at this time"; it also does that if I remove the ?validated. Can you please send a new link? I cannot find that task on the main task-list for brl-cad either... I am going to choose a new task for now, but I would definitely like to do this follow-on.