Latest revision |
Your text |
Line 350: |
Line 350: |
| '''Wednesday, July 23''' | | '''Wednesday, July 23''' |
| | | |
− | Dealing with import/export takes precedence over fixing minor bugs.
| + | Daniel suggests me to deal with import/export at first. |
| | | |
| Read codes related to NMG import/export. Then change some places in import funtion that it will skip model/nmgregion information when reading a *.g file made by trunk. | | Read codes related to NMG import/export. Then change some places in import funtion that it will skip model/nmgregion information when reading a *.g file made by trunk. |
Line 362: |
Line 362: |
| '''Friday, July 25''' | | '''Friday, July 25''' |
| | | |
− | Discussing some more implementing details which makes the solution clearer. I am trying to finish this in this weekend.
| + | Daniel gives some more detailed implementing advice to me which makes the solution clearer. I am trying to finish this in this weekend. |
− | | |
− | === Week 11 ===
| |
− | | |
− | '''Monday, July 28'''
| |
− | | |
− | I have finished the work about export of new NMG and have tested it. Now it's no problem to read a *.g file from trunk by nmgreorg and vice versa. The storage format keep consistent no matter created by nmgreog or trunk.
| |
− | | |
− | * When import, new NMG skip redundant model/nmgregion information.
| |
− | * When export, new NMG add simulating model/nmgregion information and make sure the new shell is in one nmgregion as well as the nmgregion is located in a model.
| |
− | | |
− | '''Tuesday, July 29'''
| |
− | | |
− | Do much more tests about import/export functionality. It seems no problem, but there are still some bugs in BOOL OPERATION even if some test cases can pass. I guess the root of problem is the shared structure mentioned before.
| |
− | | |
− | '''Wednesday, July 30'''
| |
− | | |
− | Track the routine:
| |
− | | |
− | * nmg_isect_two_generic_faces(fu1, fu2, tol);
| |
− | * nmg_isect_two_face3p(&bs, fu1, fu2);
| |
− | * nmg_isect_fu_jra(is, fu1, fu2, &eu1_list, &eu2_list);
| |
− | * nmg_isect_eu_fu(is, &verts2, eu, fu2);
| |
− | * new_vu = nmg_make_dualvu(v, fu, &is->tol);
| |
− | | |
− | Before calling nmg_make_dualvu, the belonging shell of v and fu are different. But after calling it, it's strange that the two structure share the same shell structure.
| |
− | | |
− | '''Thursday, July 31'''
| |
− | | |
− | With further research, nmg_mlv in nmg_mk.c is called. It seems two shell (sA and sB ready to bool operation) have shared structure since here. I guess the correct method is copy a vertex to put in the other shell.
| |
− | | |
− | '''Friday, August 1'''
| |
− | | |
− | Make some try to disconnect the relationship between two shell when calling nmg_make_dualvu, but not works. These will cause other errors in the next steps.
| |
− | | |
− | === Week 12 ===
| |
− | | |
− | '''Monday, August 4'''
| |
− | | |
− | I skip some codes in BOOL OPERATION to make program 'can' facetize the shifter in toyjeep.g. But it just cut off the main process and not reach the critical parts.
| |
− | | |
− | '''Tuesday, August 5'''
| |
− | | |
− | Compared all files before and after change, I notice the nmg_shell_fuse(sA, tol) and nmg_shell_fuse(sB, tol) before calling nmg_crackshells(sA, sB, tol). The function nmg_shell_fuse remove the repeat elements vertex/edge/edge_g in sA and sB respectively. But in trunk, it's nmg_model_fuse, which acts on the whole model. It means the same elements between sA and sB can also be removed. But in branch nmgreorg, they are not.
| |
− | | |
− | To restore the original function, I should write another version of
| |
− | | |
− | * nmg_vertex_fuse
| |
− | * nmg_break_e_on_v
| |
− | * nmg_face_fuse
| |
− | * nmg_edge_fuse
| |
− | * nmg_edge_g_fuse
| |
− | | |
− | I believe for this reason (sA and sB still have same element such as vertex), it cause the zero-length edge appearance when calling nmg_crackshells. The change is large, I decide to do the movement work (move some files to a new-created nmglib) at first after discuss with mentor.
| |
− | | |
− | '''Wednesday, August 6'''
| |
− | | |
− | Start the movement work and finish some basic parts.
| |
− | | |
− | * move all nmg_XXX except a few e.g. nmg.c (becasue it includes import/export functionalities) into libnmg.
| |
− | * move bspline dictionary into libnmg.
| |
− | * leave all db relevant files in librt.
| |
− | * leave all tree relevant files in librt.
| |
− | * leave basic shapes definition (e.g. rcc sph arb8....) in librt.
| |
− | | |
− | '''Thursday, August 7'''
| |
− | | |
− | Define the NMG_EXPORT just like the RT_EXPORT to make rtlib and nmglib import/export functions correctly when reading include files. But some functions reference each other which makes harder to separate them.
| |
− | | |
− | '''Friday, August 8'''
| |
− | | |
− | The movement method done in Wednesday is wrong because they lose the history. With Sean's lesson, I revert codes to r62036. Then use the right way (svn mv) to do the movement and redo the following operations.
| |
− | | |
− | '''Saturday, August 9'''
| |
− | | |
− | Fix some compile errors and link errors to make it able to run in Visual Studio, but fail in GCC for its more strict compilier. It wouldn't be a thorny problem if I find how to separate nmg.h and raytrace.h perfectly.
| |
− | | |
− | === Week 13 ===
| |
− | | |
− | '''Monday, August 11'''
| |
− | | |
− | Create a new variable nmg_debug to replace RTG.NMG_debug. This separation means it's unnecessary to move other unrelated struct 's definition into nmg.h. Then change all RTG.NMG_debug's reference to nmg_debug. libbu is a good example for this problem.
| |
− | | |
− | '''Tuesday, August 12'''
| |
− | | |
− | Create a new variable rtg_vlfree to replace the same member in RTG for the same reason and target as yesterday's change. It's helpful to break some redundant connection between librt and libnmg.
| |
− | | |
− | '''Wednesday, August 13'''
| |
− | | |
− | The ideal is only nmg_xxx.c files in libnmg without others. now there are plenty of nurb_xxx.c files stay here, and nmg files depend on them. So I plan to move them into a new lib named libnurb after some investigation.
| |
− | | |
− | '''Thursday, August 14'''
| |
− | | |
− | I move nurb_xxx.c files into libnurb, and change correlative header files, CMake files and so on.
| |
− | | |
− | '''Friday, August 15'''
| |
− | | |
− | The task to split librt into three smaller lib: librt, libnmg and libnurb is basically finished and be able to compiled on Linux. Notably, there is cyclic dependency among them which maybe a kind of bad smell.
| |
− | | |
− | For example, functions in nmg_class.c depends on nmg_rt_isect.c, but nmg_rt_isect.c depends on the struct xray and ray_data defined in raytrace.h. I hope neither put nmg_class.c back into librt, nor put so many obvious ray-trace struct in libnmg. So that's it.
| |
− | | |
− | I'd like to find better solution to solve it at the weekend.
| |