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 238: Line 238:
 
'''Tuesday, July 1'''
 
'''Tuesday, July 1'''
  
Obviously, my branch nmgreorg is not synchronous with the trunk. Some compile errors appear but fixed in trunk,
+
Obviously, my branch nmgreorg is not synchronous with the trunk. Some compile errors appear but fixed in trunk, eg:
  
eg: .\src\other\stepcode\src\express\parse_data.h.  
+
.\src\other\stepcode\src\express\parse_data.h.  
  
 
So, I try to make them both synchronous by using 'svn merge', and fix the conflicts after the operation.  
 
So, I try to make them both synchronous by using 'svn merge', and fix the conflicts after the operation.  
Line 262: Line 262:
  
 
I check the detailed URL of nmgreorg, relocate 'http://svn.code.sf.net/...' to 'http://svn.code.sourceforge.net/...'. Then, it works.
 
I check the detailed URL of nmgreorg, relocate 'http://svn.code.sf.net/...' to 'http://svn.code.sourceforge.net/...'. Then, it works.
 
=== Week 8 ===
 
 
'''Monday, July 7'''
 
 
Although MERGE operation and make nmgreorg branch be able to compiled on Linux, the new nmg structure still cannot deal with multiple shells. There are two kinds of situation: separated shells and overlap shells. two situation cause runtime errors in two different places.
 
 
By research, Adding a calling of 'nmg_s_reindex' directly after moving faces/edges of second shell into the first one can promote the first problem.
 
 
'''Tuesday, July 8'''
 
 
It seems more complicated to fix the second problem. By consulting Daniel, some functions should be changed because calling of them in 'nmg_classify_shared_edges_verts' makes no sense after NMG reorganization. e.g.:
 
 
* nmg_find_s_of_lu
 
* nmg_find_s_of_eu
 
* nmg_find_s_of_vu
 
 
The shells to merge don't belong to one model any more, and they are two independent shells without any connection.
 
 
'''Wednesday, July 9'''
 
 
I remove the calling of 'nmg_find_s_of_eu' and 'nmg_find_s_of_vu' in routine 'nmg_classify_shared_edges_verts', use another kind of judgement method with lower performance to achieve the same function.
 
 
But such change causes a new unexpected running error that some edgeuse point to bad address.
 
 
 
'''Thursday, July 10'''
 
 
I hope to fix the new error found yesterday, but has no progress today.
 
 
'''Friday, July 11'''
 
 
I track the calling order of the whole facetize routine, then find the nmg structure is incomplete after tesselation operation. To avoid introducing the problem by myself, I update the latest version of trunk and do this series of  test, then get the same result.
 
 
So, I am almost sure the incomplete structure hides in codes before and haven't been discovered because no usage or check done on it. I will try to find the fundamental reason for it at the weekend.
 
 
=== Week 9 ===
 
 
'''Monday, July 14'''
 
 
Another kind of method is used to compare two edge's equality. check one edgeuse's point of them and the mate edgeuse is enough to judge. Such improvement can skip the iteration error and make codes passed to next step.
 
 
'''Tuesday, July 15'''
 
 
Some minor errors are fixed, but it's no use to promote the bad pointer error. A bad address always be visited when ray-intersect faces.
 
 
'''Wednesday, July 16'''
 
 
By carefully check, nmg_classify_shared_edges_verts() is superfluous because it mainly deal with shared elements. But now there must be no shared elements between two shells to be executed BOOL OPERATION. So remove it simply.
 
 
 
'''Thursday, July 17'''
 
 
According to the debug result, the root of errors are about maxindex. When I use following codes to test, the result confirms to 'index + 1 == sA->maxindex'. That's right.
 
 
* nmg_s_reindex(sA, 0);
 
* int index = nmg_find_max_index(sA);
 
 
But if I reindex sB after reindex sA, the result is wrong.
 
 
* nmg_s_reindex(sA, 0);
 
* nmg_s_reindex(sB, sA->maxindex);
 
* int index = nmg_find_max_index(sA);
 
 
It's not difficult to make sure sA and sB have some shared structure which should be avoid after NMG reorganization work because they are completely respectively independent now.
 
 
Finally, such wrong situation make following routines read wrong address.
 
 
'''Friday, July 18'''
 
 
Succeed to facetize a combination of default sph and rcc. Use a workaround to simulation former index domain to make sure the process of nmg_bool, then refresh it at the end.
 
 
Then, compare carefully the bool-relavant files between branch and trunk. Add some missing functions. According to Daniel's suggestion, more test is required especially import/export. The codes should be merged into trunk and moved into a new lib NMGLIB if tests are all no problem.
 
 
=== Week 10 ===
 
 
'''Monday, July 21'''
 
 
Merge updates from trunk to nmgreorg. Though some reversion fails several times due to net problem, succeeds finally.
 
 
'''Tuesday, July 22'''
 
 
Facetize some existing model to test the convert functions after reorganization. Simple structure and combination are all OK, but fails when facetizing toyjeep.g.
 
 
Then I try to facetize toyjeep.g in trunk and it fails either. According to this situation, I am sure there are some bugs in trunk originally.
 
 
'''Wednesday, July 23'''
 
 
Dealing with import/export takes precedence over fixing minor bugs.
 
 
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.
 
 
So IMPORT is OK, the next step is to deal with EXPORT.
 
 
'''Thursday, July 24'''
 
 
I read the suggestion sent by Daniel a month before and do more research in EXPORT. I think a simulate old-model/nmgregion/nmgregion_a should be put into file space before saving new-shell. To keep maxindex property of new-shell consistent, calling of nmg_s_reindex() is nessesary to force the allocation function reserve extra space for these three structure.
 
 
'''Friday, July 25'''
 
 
Discussing some more implementing details 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)