Editing User:Clouddrift/GSoC2014/Logs

From BRL-CAD

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
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.
 

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)