Sean (Apr 04 2022 at 16:10): Sean (Apr 04 2022 at 16:10):Hi @GregoryLi, it's better to discuss here so everyone is aware of the conversation. The 2016 and 2017 projects that you linked to are not what I was referring to. The two different idea directions would be to work on polygonal boolean evaluation or NURBS boolean evaluation, which have aspects in these projects:
Sean (Apr 04 2022 at 16:17):NURBS boolean evaluation:
https://brlcad.org/wiki/Google_Summer_of_Code/2013#NURBS_Intersections
https://brlcad.org/wiki/Google_Summer_of_Code/2012#Implicit_to_NURBS_Conversion
https://brlcad.org/wiki/Google_Summer_of_Code/2009#Hybrid_Representation_through_BREP_on_BREP_CSG
https://brlcad.org/wiki/NURBS_Booleans
Polygonal boolean evaluation (and editing):
https://brlcad.org/wiki/Google_Summer_of_Code/2015#NMG_.2F_BoT_Editing
https://brlcad.org/wiki/Google_Summer_of_Code/2014#Mesh_Library_Cleanup
https://brlcad.org/wiki/Mesh_library_cleanup
Sean (Apr 04 2022 at 16:18):Also of relevance to the big picture for NURBS with anything related being suitable and on-topic is https://brlcad.org/wiki/NURBS
starseeker (Apr 04 2022 at 19:05):For mesh booleans (which are properly speaking a subset of the NURBS boolean problem) I believe there have been a number of academic papers since the last time BRL-CAD looked into the matter - those would be worth looking into if there is interest in that topic.
GregoryLi (Apr 05 2022 at 07:35):@Sean OK,I am looking into the references, and looking for papers to understand the aspects.
GregoryLi (Apr 05 2022 at 07:37):Are these two missions more urgent than Nurbes editing? If so, I am willing to choose topics based on a combination of urgency and personal interests.
starseeker (Apr 05 2022 at 13:07):@GregoryLi Some starting points for papers: https://arxiv.org/pdf/2103.02486.pdf https://dl.acm.org/doi/abs/10.1145/2897824.2925901
starseeker (Apr 05 2022 at 13:10):I think the arxiv.org paper is the newest. I've not dug into these in detail to see how much work they would be to implement.
Sean (Apr 05 2022 at 15:15):Note those are specifically for going down the polygonal route, but they are indeed excellent relevant current research on the topic.
Sean (Apr 05 2022 at 15:17):@GregoryLi "urgency" isn't quite an appropriate term. I would absolutely say robust export and graphical display is higher priority as it impacts so much, but if NURBS editing is what excites you the most and is most familiar to you, then that is what you should propose. Open source is often about scratching your own itch.
Sean (Apr 05 2022 at 15:24):Currently, polygonal export in BRL-CAD is around 95% reliable, which means any given model with 100+ objects is going to have several objects that fail to export to other formats such as STL, OBJ, 3DM, etc. It really needs to be 99.99999% reliable.. (one in a million failure rate). But that's an NP-complete problem and the reason why it's still an area of research. It's hard to implement something robust and without caveats. So that's why that's an interesting project -- you could A) propose implementing something new based on current research, or you could B) propose expanding our current implementation(e.g., utilize an existing library) with a new evaluation method, or you could C) propose approaching this from a TDD perspective and work on systematically proving each of the functions in libnmg is robust.
Sean (Apr 05 2022 at 15:32):NURBS geometry is our newest major feature addition, so it's more about improving usability. We can import NURBS, but then someone can edit it with a Boolean operation (e.g., subtract a cylinder) and we need to be able to evaluate it. That's useful for 3D display as well as basic export. It's also related to polygonal Booleans in that if implicit geometry (e.g., sphere UNION cylinder) can be converted to NURBS (e.g., sphere.brep UNION cylinder.brep), and Boolean evaluation on NURBS is robust (i.e., sphere.brep UNION cylinder.brep -> newobject.brep), then conversion to polygons (ie.., newobject.brep -> newobject.triangles) will also be robust. This is a far superior method of Boolean evaluation that avoids trying to evaluate in polygonal space.
Sean (Apr 05 2022 at 15:36):NURBS being new means it has a number of other areas of high-impact potential too -- including editing. There currently exists no way to edit them outside of Boolean operations with other geometry, so it would be useful to have that. It'd also be very useful if they could be raytraced faster (i.e., the existing implementation is currently unoptimized). So there are lots of possibilities!
GregoryLi (Apr 06 2022 at 01:13):Thanks for your papers and reply. I totally understand and agree with you. It’s clear they are in high priority because of their importancy. As you say, polygonal export is a pioneering work and an interesting work, which also means it’s not realistic to come to a feasible proposal before April 20.
GregoryLi (Apr 06 2022 at 01:13):(deleted)
GregoryLi (Apr 06 2022 at 01:14):I’m now committed to NURBS geometry. I have read previous GSOC work and wiki, get to know it better, but I still need some time to investigate existing functionality and read papers before make useful comments.
GregoryLi (Apr 09 2022 at 11:30):Accoding to issues in wiki, I have investigated and concluded the following two aspects
GregoryLi (Apr 09 2022 at 11:31):aspect1: tessellation from splines
usage: Coverting BREP model to triangle mesh is very helpful in real-time visualization and ray tracing. They may also serve as the basis for generation of analysis suitable meshes by either providing a starting mesh or by facilitating its sizing field and gradation.
method: Following reference 3, implement a robustly approximate CAD surfaces that define the boundary of complicated three dimensional geometric shapes with a minimum number of triangles NURBS tessellation method.
references:
GregoryLi (Apr 09 2022 at 11:31):aspect2: Implicit boolean operation
(why not explicit? because I saw it in previous GSoC and I’m not sure is it still under developing)
usage: In many applications concerning the analysis of multi-body interactions as in analysis of contact between two bodies,often it is not required to explicitly compute the intersection between interacting B-rep CAD models. Besides, I think the bounding box build is useful in ray tracing for plate model.
method: Following reference 1, implement a purely algebraic, and therefore non-iterative, approach to carrying out point containment queries on complex B-rep models built using low-degree NURBS surfaces.
references:
GregoryLi (Apr 09 2022 at 11:37):These are outlines of my current ideas, I don't know whether they are developing or useful in the big picture of NURBS. If any of them is suitable, I will investigate in more detail and make a detailed proposal.
Sean (Apr 09 2022 at 15:19):@GregoryLi I'm impressed with your thoroughness. It's giving some reassurances that you will propose something good. Keep it up! ;)
Sean (Apr 09 2022 at 15:21):so for aspect1 and aspect2 it will be import to realize that brl-cad has nurbs tessellation and nurbs booleans respectively, they're just incomplete or not as robust as they need to be. So familiarizing yourself with their current status will be essential in scoping what exactly you plan to do so that you either take the existing implementation into consideration, or have a good reason for ignoring what's there to implement a different method.
Sean (Apr 09 2022 at 15:32):I have a general sense that the existing nurbs tessellation implementation is actually pretty good for visual purposes -- just not necessarily for export where it's supposed to guarantee that if an object is solid, that it's tessellation is also solid.
Sean (Apr 09 2022 at 15:33):I do know the boolean evaluation support is pretty far along also, but definitely needs more work. we even have documentation explaining where it's at. if you read the "NURBS Boolean Evaluation Development Guide" it's a docbook article in our repo (bool_eval_development.html)
Sean (Apr 09 2022 at 15:41):NURBS-Boolean-Evaluation-Development-Guide.pdf It's in the source repo, but here's the doc in pdf form.
Sean (Apr 09 2022 at 15:42):So proposing something/anything that extends that effort would be golden. Especially if you can submit something related to it, even if it's a simple unit test or demonstrates an approach or improves it in any way.
Sean (Apr 09 2022 at 15:43):that guide is exquisitely detailed, but if it's too overwhelming, you can always fall back on implementing a CLI editing interface
GregoryLi (Apr 11 2022 at 08:02):I have noticed that the NURBS Tessellation part is in src/librt/primitives/nmg/nmg_tri.c, using Marching Cube(MC) algorithm. I see there is a rough game plan in the notes of the file, but it hasn’t updated for years.
GregoryLi (Apr 11 2022 at 08:03):Luckly I just had looked into the MC algorithm. MC is popular for its simplicity, robustness and efficiency, but the origin MC algorithm (also the current brl-cad method) is not enough to generate a high quality mesh. Here are some up-to-date MC algorithms listed in the references. The advantages are:
So for the usage of the project, it can be used as export generated triangle meshes from NURBS. And maybe it also can be used in visual.
GregoryLi (Apr 11 2022 at 08:04):references:
Sean (Apr 11 2022 at 08:06):MC is kind of sucky, imho.
the code you're looking at in nmg is not the right/current code, that was a nurbs implementation done in the late 80's early 90's.
Sean (Apr 11 2022 at 08:07):you'll want to look at libbrep for current nurbs code, and it's corresponding entity is the 'brep' primitive (so look in src/librt/primitives/brep)
Sean (Apr 11 2022 at 08:08):src/libbrep is where most of the logic resides, notably the large intersect.cpp and boolean.cpp files.
Sean (Apr 11 2022 at 08:10):the idea with nurbs booleans is that evaluation happens in the original nurbs boundary representation (brep) space, not in polygonal space. so sampling methods like MC aren't even necessary and the evaluated result is quite superior.
GregoryLi (Apr 11 2022 at 08:11):OK... Do you think tessellation part still needs developing?
Sean (Apr 11 2022 at 08:14):when working with NURBS, the only place where polygons are involved in any way is for display meshes (e.g., for temporary opengl display purposes) or export to a polygonal format. if one has a sphere represented by a single NURBS surface, and it's intersecting another NURBS sphere with a union boolean operation, the evaluation of that boolean should result in 2+ surfaces in a new NURBS entity (and with no Boolean).
Sean (Apr 11 2022 at 08:16):GregoryLi said:
OK... Do you think tessellation part still needs developing?
Well yes, that's why it was mentioned as a potential project, but that task should not / cannot start from scratch. There is already extensive code in src/libbrep that generates a tessellation of NURBS surfaces quite reliably. What it doesn't necessarily do is ensure that if an object is solid, that its tessellation will also be solid. That is critically important for exporting to polygonal formats.
GregoryLi (Apr 11 2022 at 08:17):Yes, I can understand the operation flow of NURBS or CAD. I've looked into explicit and implicit boolean operations, but haven't looked at the source code of brl-cad.
GregoryLi (Apr 11 2022 at 08:23):I have doubts about the meaning of NURBS “evalution”. Is it means to evaluate the effect of explicit boolean operations implemented? Or implement explicit boolean operations? I thinking it's better to make it clear to me to avoid misunderstanding like MC.
Sean (Apr 11 2022 at 08:35):Sorry, I'm not understanding your question..
Sean (Apr 11 2022 at 08:39):say you have two NURBS spheres. they are each defined by a single surface. they overlap halfway and are combined together with an intersection operation. something like... GUID-4775186F-4BCD-4BAF-BA15-6AE8B2575105.png
Sean (Apr 11 2022 at 08:40):lens_object = sphA INTERSECT sphB
Sean (Apr 11 2022 at 08:42):lens_object in that case is a combination object (i.e., its type is actually a 'comb' and it is not a brep/nurbs entity) that includes a boolean recipe. that is called implicit or unevaluated representation. lens_object is type comb, sphA is type ell, sphB is type ell.
Sean (Apr 11 2022 at 08:46):now that's all fine and that works now. but a very useful operation is to eliminate the boolean. if we evaluate the boolean expression in lens_object, we should get a brep/nurbs entity that is the lens shape on the right (which has two surfaces) and there's no longer a boolean.
Sean (Apr 11 2022 at 08:46):strongly recommend reading the aforementioned NURBS-Boolean-Evaluation-Development-Guide.pdf
GregoryLi (Apr 11 2022 at 09:13):To be more precise, implicit boolean I said is determine whether two objects intersect, explicit refers to calculate the precise area of intersection, including union and other boolean operation.
GregoryLi (Apr 11 2022 at 09:16):Sean said:
lens_object in that case is a combination object (i.e., its type is actually a 'comb' and it is not a brep/nurbs entity) that includes a boolean recipe. that is called implicit or unevaluated representation. lens_object is type comb, sphA is type ell, sphB is type ell.
yes, I can get it. But in my incomplete survey, I did not find relevant papers.
GregoryLi (Apr 11 2022 at 09:18):Do you have any suggestions？
GregoryLi (Apr 11 2022 at 09:20):Is "trimmed" a related keyword？
GregoryLi (Apr 11 2022 at 11:10):I'm reading the NURBS-Boolean-Evaluation-Development-Guide.pdf, found many questions can be answered in the pdf. I'll reply after I read it totally.
Sean (Apr 11 2022 at 19:30):GregoryLi said:
Is "trimmed" a related keyword？
Yes, trimmed NURBS is what we have and use. With NURBS, you define a surface, and then use trimming curves to dictate where the surface physically exists and where it does not. E.g., https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.146.3590&rep=rep1&type=pdf
Sean (Apr 11 2022 at 19:33):also relevant: https://mcmains.me.berkeley.edu/pubs/SPM08gpuSSI.pdf
starseeker (Apr 12 2022 at 00:56):src/libbrep/cdt has the triangulation code - fast.cpp is the display tessellation, by far the fastest option but also will show cracks at the seams. ON_Brep_CDT_Tessellate is an attempt at watertight tessellation, and if you grep the code for that function you'll find it is exposed in a couple of libged commands. There's more in that logic than just watertightness - it will also locally converge the meshing to try and reduce the volume of overlapping between nearby brep objects.
starseeker (Apr 12 2022 at 00:58):See https://apps.dtic.mil/sti/pdfs/AD1094344.pdf
starseeker (Apr 12 2022 at 00:59):(The most elaborate attempt at avoiding overlaps had to be backed out of the repo - we weren't able to mature it sufficiently in the available time. Git has it in the history if/when we can revisit it. For just watertight meshing, it's not necessary.)
starseeker (Apr 12 2022 at 01:00):The watertight tessellation code needs robustness testing and improvements.
GregoryLi (Apr 12 2022 at 11:57):I have read BRL-CAD NURBS Boolean evaluation guide.pdf carefully, as well as source code and test code about NURBS boolean and intersect, and the two references listed.
GregoryLi (Apr 12 2022 at 11:58):It seems ON_Boolean() function in src/libbrep/boolean.cpp has implemented boolean operation using OpenNURBS, with ON_Brep variables input and ON_Brep variable output.
GregoryLi (Apr 12 2022 at 12:05):Sean said:
lens_object in that case is a combination object (i.e., its type is actually a 'comb' and it is not a brep/nurbs entity) that includes a boolean recipe. that is called implicit or unevaluated representation. lens_object is type comb, sphA is type ell, sphB is type ell.
I'm wondering what is needed to be done in the boolean operation. Does it mean there needs to be a type conversion from ellipse and other data structure to ON_Brep or rt_brep_internal? Or improve boolean function to combine the two input Brep into one, just like Watertight Trimmed NURBS?
Sean (Apr 13 2022 at 06:00):The latter. There actually are already functions that convert nearly every primitive like ell to brep/ nurbs (see rt_ell_brep() in src/librt/primitives/ell.c)
Sean (Apr 13 2022 at 06:01):In the example I gave .. it doesn’t matter if that’s an ell or ell that was converted to brep as it’s simple to get it in brep form. The difficulty is the surface surface intersections
GregoryLi (Apr 13 2022 at 06:06):So it means there are something to be improved in ON_Boolean() and other functions in src/libbrep/boolean.cpp & intersect.cpp, am I right?
Sean (Apr 13 2022 at 06:10):You got it. That’s the entirety of the project. Make that function work. Make it more robust. Create tests that more systematically explore what is working and what is not working. Or simply identify specific failures and create a plan for fixing them. From there create a plan of attack to fix whatever else is not working and so on.
Sean (Apr 13 2022 at 06:12):It would probably help if you create two overlapping brep spheres and try to Boolean evaluate them, now that you’ve ref the paper. See if it works. If I’d does, see if it fails when they nearly tangent. If that works, see if one is fully inside/outside the other, and so on
Sean (Apr 13 2022 at 06:14):If that all works great then maybe propose a project to do the same patter to all possible combination of two primitives
GregoryLi (Apr 13 2022 at 06:16):Yes, I see. There has been a lot of work in NURBS Boolean and it works in many cases. I can test normal and special cases, evaluate and improve the performance or accuracy of some of the functions.
GregoryLi (Apr 13 2022 at 06:18):But for the GSoC proposal deadline in one week, I think I need to proposal something concrete and digitized.
GregoryLi (Apr 13 2022 at 06:25):Should I test manually to get boolean issues? Maybe this will take some time and is not very efficient.
GregoryLi (Apr 13 2022 at 06:26):So I want to know where in NURBS Boolean or Intersect there is a higher modification priority, so that I can study the source code in a targeted manner, consult the papers and propose a concrete and detailed proposal.
Sean (Apr 13 2022 at 06:35):The short summary that you hopefully understood from reading the paper is that it’s good, really good, but it’s stilll incomplete.
Sean (Apr 13 2022 at 06:37):I think you should test manually enough to understand what works and what does not. If you very quickly find issues, then you can simply propose to work on them for starters and will plan to continue that approach perhaps using TDD.
Sean (Apr 13 2022 at 06:38):If you have trouble finding one that doesn’t work, then that would imply a very different project, one more automated and systematic. Aim to prove just how good it is, or systematically test all possible conditions
GregoryLi (Apr 13 2022 at 06:45):OK.. It will be a different GSoC project. I will test it manually in the following days, report it here, write them in the document as well as my proposal. If it's accepted in GSOC, I will continue to TDD, record the process of my own testing, and improve or prove the functions according to the situation.
GregoryLi (Apr 13 2022 at 06:46):There will not a very accurate description of the project progress and workload in the proposal, but I will reflect them in the later reports.
GregoryLi (Apr 13 2022 at 11:57):I found there are lots of todo works in wiki,but but it looks like it hasn't been updated for a long time. I will pay more attention to these aspects.
GregoryLi (Apr 15 2022 at 14:19):Here is one error I found test brep.
GregoryLi (Apr 15 2022 at 14:20):(deleted)
GregoryLi (Apr 15 2022 at 14:27):Snipaste_2022-04-15_22-16-47.png Snipaste_2022-04-15_22-17-04.png
GregoryLi (Apr 15 2022 at 14:28):Above is two arb8 objects
GregoryLi (Apr 15 2022 at 14:29):Snipaste_2022-04-15_22-17-23.png Snipaste_2022-04-15_22-17-38.png
GregoryLi (Apr 15 2022 at 14:33):Below are union the two objects together, then convert the union to Brep.
GregoryLi (Apr 15 2022 at 14:34):Snipaste_2022-04-15_22-34-10.png
GregoryLi (Apr 15 2022 at 14:37):I'm writing my proposal and plan to send you a draft tomorrow.
Sean (Apr 18 2022 at 12:46):Yep that looks like a bug in the eval.
Sean (Apr 18 2022 at 12:47):Would be interesting to know if the bug happens if the arb is fully inside the face versus aligned to some side.
GregoryLi (Apr 18 2022 at 13:01):OK, I will test it later. Here are another bug
GregoryLi (Apr 18 2022 at 13:02):Snipaste_2022-04-18_14-06-18.png These are four solids before Brep
GregoryLi (Apr 18 2022 at 13:03):Snipaste_2022-04-18_14-06-29.png This is after Brep operation.
Not only some faces of arb8 are lost, but also one sph is lost totally.
GregoryLi (Apr 18 2022 at 13:06):I think these bugs have something in common. I'm doing more tests, and try to locate the bugs.
GregoryLi (Apr 20 2022 at 08:21):I have found some errors in BRL-CAD, not only in terms of NURBS. How should I document these issues? Shall I add them to github issues?
Sean (Apr 20 2022 at 20:54):Sure @GregoryLi if you found a bug and can reproduce it, sounds great for submitting an issue.. or if you fix it, submit a pull request.
Sean (Apr 20 2022 at 20:55):Those bugs you found are great examples of simple failures. One of the interesting and useful outcomes would be to systematically perform a broad variety of configurations and dashboard the failures.
GregoryLi (Apr 21 2022 at 01:53):Yes, I'm trying to list all the possible cases and combine them. Recoding them clearly will be useful for ensuring robustness of the system.
GregoryLi (Apr 25 2022 at 08:00):I have found some errors and added to issues:
Compile error in windows about character encoding
Display error while doing a boolean operation in archer
Missing surfaces while boolean and brep
Missing entity while boolean and brep
GregoryLi (Apr 25 2022 at 08:04):I am trying to read and modify the source code. And I will update important findings into issues.
Sean (Apr 26 2022 at 15:33):@GregoryLi those look great. Looks like there's no shortage of issues to investigate and work on! Do you think you could create a systematic test? Like create a program that creates a 1000mm unit cube (0,0,0 to 1000,1000,1000), then creates another object (e.g., another unit cube) in all positions with respect to the other object.
Sean (Apr 26 2022 at 15:34):ideally something systematic with a directly computable result so you can know when brep eval fails just by asking for the volume, for example, or evaluating a shotline thickness.
GregoryLi (Apr 27 2022 at 01:03):Sean said:
GregoryLi those look great. Looks like there's no shortage of issues to investigate and work on! Do you think you could create a systematic test? Like create a program that creates a 1000mm unit cube (0,0,0 to 1000,1000,1000), then creates another object (e.g., another unit cube) in all positions with respect to the other object.
I think these tests will be useful. If possible, adding topology testing would be a good extension.
Shall I write these tests using C or shell script?
GregoryLi (Apr 27 2022 at 01:10):I have another question. According to NURBS-Boolean-Evaluation-Development-Guide.pdf chapter 4.1, bool1* and bool2* files are created for development convenience. But I can only find them when I run a shell script to test brep on linux. Running neither in archer nor megd generates.
GregoryLi (Apr 28 2022 at 02:07):GregoryLi said:
I have another question. According to NURBS-Boolean-Evaluation-Development-Guide.pdf chapter 4.1,
bool1*andbool2*files are created for development convenience. But I can only find them when I run a shell script to test brep on linux. Running neither in archer nor megd generates.
OK..I find those files on windows. After boolean operation, those files are generated in C:\Users\xxx... But here it is generated, and it's not deleted. It's weird...
GregoryLi (May 10 2022 at 08:51):Sorry for the delay because I took several midterm exams some days ago.
GregoryLi (May 10 2022 at 08:54):I think calculating the length(or thickness) of the intersection of one ray and one Brep model is useful for testing. I didn't find it in current project, I'll list it into my TODO list.
GregoryLi (May 10 2022 at 09:00):GregoryLi said:
Snipaste_2022-04-15_22-17-23.png Snipaste_2022-04-15_22-17-38.png
For missing faces cases, I think it's important to tell if a Brep model is a manifold. As a simple start, I can start with determining whether each edge links two faces or not. If not, it's a non-manifold.
Sean (May 12 2022 at 18:04):Hi @GregoryLi hope your exams went well! Note that the "nirt" command in mged will fire a single ray (at any geometry). It's often used to inspect geometry and ray tracing behavior, or even help with debugging a specific issue.
Sean (May 12 2022 at 18:06):GregoryLi said:
For missing faces cases, I think it's important to tell if a Brep model is a manifold. As a simple start, I can start with determining whether each edge links two faces or not. If not, it's a non-manifold.
````
There are functions in OpenNURBS that report whether geometry IsSolid() and IsValid(), among other properties. Can possibly look there to see if there's a manifold test at each phase of a given boolean evaluation.
Thanks! I will check these comands and functions.
GregoryLi (May 31 2022 at 11:09):Hi, I just finished all the exams this semester. I have more time available to invest in GSOC.
GregoryLi (May 31 2022 at 11:10):Here are some TODOs before June 13.
GregoryLi (May 31 2022 at 11:17): GregoryLi (May 31 2022 at 11:19):@Sean Do you have any opinion? I think I need to do something as soon as possible to start my first commit.
Sean (May 31 2022 at 16:29):@GregoryLi in general that all sounds good, though #1-#4 seem rather ill-defined / unactionable. I suggest doing #5, particularly reading the nurbs guide, but instead work on something that helps you get familiarized with the opennurbs data structures
One idea that comes to mind is to re-implement converting an arb8 to brep, and see if you can make it support non-planar arb8 faces.
Sean (May 31 2022 at 16:30):For example, currently if you create an arb8 box and just move one vertex, the resulting faces are non-planar. You can see an example here:
Uploading Screen Shot 2022-05-31 at 12.27.34 PM.png…
Sean (May 31 2022 at 16:31):That renders with rt, but it renders incorrectly (it assumes it's planar). It could render correctly if we converted it to brep on the fly. However, if I run the brep command now to convert it, it apparently splits the non-planar faces. It could just convert them to brep as-is.
Sean (May 31 2022 at 16:32):In fact, we have an example of non-planar cube code in src/proc-db/brep_simple.cpp (also see twistedcube.cpp) that shows it's possible.
Sean (May 31 2022 at 16:34):I suggest familiarizing yourself with brep_simple (run it, render the model with rt, shoot it with nirt), create a cube and move one of the vertices (and test that with rt and nirt), and see if you can figure out how to get the brep command to generate the appropriate conversion. Code for arb8 is in src/librt/primitives/arb8 directory.
GregoryLi (Jun 01 2022 at 00:37):Thanks! Your suggestion is very clear and useful, I will try and solve it as my first step. Although I can't open the png, but I can get your idea. I will reproduce the problem.
GregoryLi (Jun 01 2022 at 00:41):Btw, here is my detailed and pubilc TODO board for BRL-CAD. You can see and comment on it if you want.TODO list
GregoryLi (Jun 01 2022 at 00:43):For #5 and your suggestion, I will mark them as top priority. I think they would be a good start.
Sean (Jun 02 2022 at 16:59):@GregoryLi ah, I see you have a dev log at https://brlcad.org/wiki/User:GregoryLi/GSoc2022/DevLog, which is great -- can you link to it on the 2022 page?
GregoryLi (Jun 03 2022 at 01:45):Sure, I will begin to update my devlog from today.
Sean (Jun 03 2022 at 13:11):Apparently that screenshot upload never succeeded. Here it is again: Screen-Shot-2022-05-31-at-12.27.34-PM.png
GregoryLi (Jun 04 2022 at 09:29):Thanks, I can see it now and reproduce it.
GregoryLi (Jun 04 2022 at 09:31):image.png from this point of view, it's clear that there is problems while rt.
GregoryLi (Jun 04 2022 at 09:45):btw, how to delete wiki page? I have created one wrong wiki page: https://brlcad.org/wiki/User:GregoryLi/GSoc2022/DevLog
The correct site should be:
https://brlcad.org/wiki/User:GregoryLi/GSoC2022/DevLog
with GSoc to GSoC
GregoryLi (Jun 04 2022 at 09:45):I created both but I couldn't delete the wrong one...
Erik (Jun 04 2022 at 15:04):I think it requires admin access. I've deleted the one with the lower case c
GregoryLi (Jun 05 2022 at 01:14):Thanks! I get it.
Sean (Jun 06 2022 at 14:07):@GregoryLi there are a number of issues with rt rendering that arb8, but what's more interesting is whether it can be converted to brep/nurbs cleanly. if it can, then we could probably detect non-planar faces and auto-convert during prep. first step would be getting the brep command to successfully turn it into a brep though -- it currently doesn't from what I can see meaning the implementation in arb8_brep.cpp could be improved.
GregoryLi (Jun 07 2022 at 05:05):Yes, I'm now looking into src/librt/primitives/arb8.c/rt_arb_tess(). I can see it facetized in nmg_cmface(). What do you mean by "improved"? Here is one: we can get two facetize output as picture below. I think it's better to make it configurable or set a default case, such as convex as default. image.png
GregoryLi (Jun 07 2022 at 05:09):And I will try brep_simple now.
Sean (Jun 07 2022 at 17:52):@GregoryLi converting an arb8 to a brep should not involve calling rt_arb_tess() .. that's for turning an arb8 into a tessellated triangle mesh
Sean (Jun 07 2022 at 17:53):which explains why it splits the non-planar faces with an edge, but notice how the original object surface when you move just one vertex should be a smooth warped surface
GregoryLi (Jun 08 2022 at 01:05):Oh, it suddendly came to me brep and facetize are two totally different things!
Sean (Jun 08 2022 at 03:18):indeed, brep is a general purpose command for creating and manipulating brep (aka nurbs) objects; facetize is a command that performs conversions of input geometry to a facetized (aka polygonal) format such as our Bag of Triangles (aka 'bot') format and N-Manifold Geometry (aka 'nmg') for more generalized polygons.
GregoryLi (Jun 15 2022 at 14:36):I'm sorry that I was quarantined due to policy about covid-19 :(. I had little time on BRL-CAD and I missed one work-day, which is going to be filled this Saturday. So far I have tested brep_simple.cpp/brep_cube.cpp and do it in the normal way.
GregoryLi (Jun 15 2022 at 14:38):I see there is non-planar log info while convrting it into brep in mged.
image.png
GregoryLi (Jun 15 2022 at 14:43):The result seems confusing in brep_simple.cpp: the rt picture shows the none-planar faces have a fixed normal or a smoothly changing normal, with four non-planar vertex and four straight edge. It's hard to imagine how the surface looks like...
GregoryLi (Jun 15 2022 at 14:50):I looked into source code of brep_simple.cpp, twistedcube.cpp and arb8_brep.cpp, try to find the differences between them. But further research is required...
And I want to replace the input data in brep_simple with arb8. I wrote some code but still need to adapt to the transition from C++ to C. (Because there are some C style codes)
Sean (Jun 16 2022 at 04:14):Imagine a cube made out of clay, and you grab the top four vertices and rotate it some. That’s the example.
Sean (Jun 16 2022 at 04:15):The twisted cube brep should render with rt just fine to get an idea for what it should look like.
GregoryLi (Jun 19 2022 at 06:59):Hi, I have wrote one example about arb8 test and I want to upload it, what should I do? Shall I fork BRL-CAD on github, or just create another branch?
GregoryLi (Jun 24 2022 at 02:32):@Sean Hi, I just wrote some test projects like brep_simple, brep_trimmed and I'd like to upload them. What should I do?
choice 1: create a branch in BRL-CAD and upload them.
choice 2: fork BRL-CAD to my personal github and upload them.
I think I will write lots of test projects, I don't konw if it will be too many and boring for BRL-CAD.
GregoryLi (Jun 24 2022 at 06:39):I ran surfaceinteresct project but error occured. I tried to fix it but failed. Can you help me?
GregoryLi (Jun 24 2022 at 06:39):image.png
This is the error stack.
GregoryLi (Jun 24 2022 at 06:46):I think the reason is that the four ON_Curve object was not created and initialized properly. I changed them to ON_Curve *left1 = new ON_NurbsCurve(), *right1 = new ON_NurbsCurve(), *left2 = new ON_NurbsCurve(), *right2 = new ON_NurbsCurve(); and failed still....
Sean (Jun 28 2022 at 12:48):@GregoryLi Sorry I was consumed the past few days wrapping up a task and holiday. As for your choices, you wont' be able to do #1 without having commit access and you won't have that until you successfully submit a couple PRs. So I think that's your best bet -- submit changes as PRs that are clean.
Sean (Jun 28 2022 at 13:04):GregoryLi said:
I ran surfaceinteresct project but error occured. I tried to fix it but failed. Can you help me?
surfaceintersect is a good one to look at but understand that it's a work-in-progress code by another dev in an unknown working state. I'm not sure it ever worked. looking at the implementation, it appears to be trying to implement a SurfaceIntersect() function as that's one of the functions that opennurbs removes from their code. however, the implementation still relies on ON_NurbsCurve::Split() which does exist and is where it's crashing -- so you'd have to debug through that function to see what it's expecting there.
Sean (Jun 28 2022 at 13:10):I also get the same error stack, for what it's worth. I think you're on the right track as the implementation seems to be expecting them to be ON_NurbsCurve() and cannot be ON_Curve entities. My first thought would be to simply make them ON_NurbsCurve left, right; and pass references to Split(). I'd step through that in a debugger to see how it proceeds.
GregoryLi (Jun 28 2022 at 14:04):Sean said:
GregoryLi Sorry I was consumed the past few days wrapping up a task and holiday. As for your choices, you wont' be able to do #1 without having commit access and you won't have that until you successfully submit a couple PRs. So I think that's your best bet -- submit changes as PRs that are clean.
Thanks! I will clean up my code and submit them tomorrow. I want to make my test more formal and reproducible, that make a comparison of the changes before and after TTD for brep boolean. : )
GregoryLi (Jun 29 2022 at 10:18):Hi, I just created one PR here(https://github.com/BRL-CAD/brlcad/pull/53).
GregoryLi (Jun 29 2022 at 10:21):If it works well, you can see two error brep objects: brep.arb_3 and brep.arb_4
image.png
image.png
GregoryLi (Jun 29 2022 at 10:27):The brep objects created by my project are wong. While converting them to brep using brep cmd in archer, the outputs are right. I found the problem just now. Looking into the problem :(
GregoryLi (Jul 05 2022 at 12:19):@Sean I spend serval hours to rebuild the project after pulling recent merges and found serval problems while building.
GregoryLi (Jul 05 2022 at 12:26):In brlcad\src\conv\ply\g-ply.c, error occurs about array definition. C2057: expected constant expression
I thought it is caused by C language standard, but still failed after using std:c17 image.png
Finally rebuild succeed by modifing the code.
image.png
GregoryLi (Jul 05 2022 at 12:33):GregoryLi said:
The brep objects created by my project are wong. While converting them to brep using brep cmd in archer, the outputs are right. I found the problem just now. Looking into the problem :(
As for the problem I mentioned, I use file output to track code stack by _brep_cmd_brep and found it's the same as my test case.
GregoryLi (Jul 05 2022 at 12:35):And I'm still debuging the brep funciton... I think there are more problems than I thought.
Daniel Rossberg (Jul 05 2022 at 17:02):GregoryLi said:
In brlcad\src\conv\ply\g-ply.c, error occurs about array definition. C2057: expected constant expression
I thought it is caused by C language standard, but still failed after using std:c17 image.png
Finally rebuild succeed by modifing the code.
image.png
Microsoft Visual Studio does not support the C99 feature VLA (variable length array). In C11 it isn't mandatory. You can check there if the __STDC_NO_VLA__ macro is defined or not.
Don't forget to free the array if it isn't needed anymore.
GregoryLi (Jul 06 2022 at 02:26):Thanks, you hit the bullseye! It seems VLA is illegal in the ISO standard and not supported in Visual Studio. So do I need to change to a legal way such as using bu_calloc? Or I just use it in my local repository?
Daniel Rossberg (Jul 06 2022 at 06:40):I haven't looked at what you are doing there exactly, but there are already similar constructs in g-ply.c using bu_calloc(). You can use them as template for your changes. At the end, the code should compile with all major compilers.
Sean (Jul 11 2022 at 06:56):Hi @GregoryLi that build error you ran into was fixed last week, so it won't be a problem if you update. windows should be building cleanly (is for me), but let me know if you encounter an issue.
Sean (Jul 11 2022 at 07:03):I'd like to see a summary of progress sometime later this week, and we need to discuss. "Debug brep using file output system" doesn't really say anything useful or actionable about what you're doing at all. You have 7-8 days where you generally indicate that you're debugging, but no successful outcomes from any of them so whatever you're doing seems ineffective and probably shouldn't continue like that. If this debugging is at the limit of your skills after reading the NURBS Development Guide, then we should shift your focus to something more productive like categorically identifying issues instead of debugging them.
GregoryLi (Jul 11 2022 at 07:34):I'm seriously behind schedule due to personal reason. I will organize my recent works and make dev log clear. Maybe reread NURBS Development Guide is critical to remind me not to go to the horns.
GregoryLi (Jul 11 2022 at 07:35):Hope to make a breakthrough before our discussion and work more efficiency.
GregoryLi (Jul 11 2022 at 08:34):Sean said:
Hi GregoryLi that build error you ran into was fixed last week, so it won't be a problem if you update. windows should be building cleanly (is for me), but let me know if you encounter an issue.
I rebuild the newest code and no error occured!
GregoryLi (Jul 12 2022 at 15:25):Find multiple outputs with the same 'brep' operation among three BRL-CAD versions:
GregoryLi (Jul 12 2022 at 15:27):current main branch:
image.png
GregoryLi (Jul 12 2022 at 15:28):7.32.6 release package:
image.png
GregoryLi (Jul 12 2022 at 15:30):build with BRL-CAD 7.32.6 source code:
image.png
GregoryLi (Jul 12 2022 at 15:31):More boolean cases will be tested. And I will compare the differences among them.
Sean (Jul 13 2022 at 02:27):@GregoryLi thanks for sharing
Sean (Jul 13 2022 at 02:28):note that the only value in comparing different versions would be what you show above -- a version that worked, and a more current version that does not -- but then bisecting to find what commit caused it to stop working
GregoryLi (Jul 13 2022 at 02:35):I get it. This will be my main TODO today.
Sean (Jul 13 2022 at 02:36):see if you can find where it stops working. you'll need to self-compile from a git checkout and obviously get your compiled version to work first. then you can test different versions to find what change seemed to cause problems.
Sean (Jul 13 2022 at 02:37):git bisect can greatly help, if you know how that works, or if you check out a tutorial. or you can simply jump forward and backwards through commits until you narrow in on the commit
Sean (Jul 13 2022 at 02:39):note, your 7.32.6 build with the abort message is not terribly helpful -- you'd need to either run that in a debugger to know where abort is being called, or see if you can get a stack trace some other way (I don't know what your buttons say). simply knowing that it threw up an error is not useful information, however, as any number of unrelated things could be wrong.
GregoryLi (Jul 13 2022 at 02:42):Thanks, I will check them! Note that in Archer build by 7.32.6, brep cmd crashed only in some models, while others not.
Sean (Jul 13 2022 at 02:47):you may want to compile in release mode as that does change the assertion checks that are performed on windows. the release version may be silently ignoring errors. release mode isn't terribly useful for debugging but there's no point trying to debug old versions, so it can help find what change succeeds correctly vs incorrectly
Sean (Jul 13 2022 at 02:56):After that's all done, I have an idea for something you could work on that would be helpful. Implement something that tells us which primitives convert to brep and which do not. This could be a program like some of the src/proc-db programs, it could be a shell script, it could be a cmake script, it could be a ged script -- what matters is getting an output that includes entries for all of the various solid primitives in src/librt/primitives/table.cpp and reports which convert successfully, which fail (and shouldn't), which fail (and should), and/or which do not have an implementation. The output can be text or a webpage or similar, but should ideally just be something we can simply run and get a report. make sense?
GregoryLi (Jul 13 2022 at 02:59):OK, I ignored it.. Build Release now. So more current version should also be tested in Release mode.
GregoryLi (Jul 13 2022 at 03:01):Sean said:
After that's all done, I have an idea for something you could work on that would be helpful. Implement something that tells us which primitives convert to brep and which do not. This could be a program like some of the src/proc-db programs, it could be a shell script, it could be a cmake script, it could be a ged script -- what matters is getting an output that includes entries for all of the various solid primitives in src/librt/primitives/table.cpp and reports which convert successfully, which fail (and shouldn't), which fail (and should), and/or which do not have an implementation. The output can be text or a webpage or similar, but should ideally just be something we can simply run and get a report. make sense?
OK, i understand.
starseeker (Jul 13 2022 at 10:28):Note if you need Release mode with debug info on Windows, you can get it as an option by setting the ENABLE_ALL_CONFIG_TYPES option in CMake
starseeker (Jul 13 2022 at 10:29):That will enable RelWithDebInfo - that's not a normally used BRL-CAD config (we generally limit the build to Debug and Release modes), but it's sometimes necessary to use RelWithDebInfo with MSVC
Sean (Jul 14 2022 at 02:00):That's okay, he really doesn't need to debug the old versions. But good to know.
GregoryLi (Jul 14 2022 at 05:02):Thanks! I just located the merge 660c8f is the key to solve the problem.
GregoryLi (Jul 14 2022 at 05:06):GregoryLi said:
current main branch:
image.png
By the way, although it works well for arb_4.r in current main branch in RELEASE mode, errors still occurs for some other combinations.
Sean (Jul 15 2022 at 04:29):@GregoryLi how do you figure 660c8f is key? that's a merge commit on a different branch... I would think you should only be iterating through commits on main.
Sean (Jul 15 2022 at 04:31):that commit merged a bunch of changes from main to swrast, so it's a commit to the swrast branch.
GregoryLi (Jul 15 2022 at 04:36):Sorry, I think the merge did not introduce errors. Now I'm locating it using bisect. But it's time consuming...
GregoryLi (Jul 15 2022 at 04:37):Still building now.
image.png
GregoryLi (Jul 15 2022 at 04:52):I think it means it's one merge from Release branch to main... Using source tree.
image.png
GregoryLi (Jul 16 2022 at 01:03):I located the error around 1583360. For the specific test case, newer commits get wrong output, older get correct output, some middle versions crashed even in Release mode. Tring to figure it out.
Sean (Jul 16 2022 at 04:38):@GregoryLi that's actually entirely possible that doing some initialization is changing behavior. If you manually edit src/libbrep/opennurbs_ext.cpp from DBL_MAX to uninitialized, does it work?
Sean (Jul 16 2022 at 04:39):that's actually a change in the area of code that could indeed affect the behavior of the boolean evaluation
GregoryLi (Jul 16 2022 at 14:40):Sean said:
GregoryLi that's actually entirely possible that doing some initialization is changing behavior. If you manually edit src/libbrep/opennurbs_ext.cpp from DBL_MAX to uninitialized, does it work?
Actually it's not a problem caused by one commit, but serval commits around it. So far I have found that commit 8a508c8 makes arb_4.r test case go from correct to crash, and c39d657cd makes arb_4.r test case go from crash to error output. And it seems that these commits solved another brep problem while causing this new problem...
Sean (Jul 17 2022 at 06:17):Sean said:
After that's all done, I have an idea for something you could work on that would be helpful. Implement something that tells us which primitives convert to brep and which do not. This could be a program like some of the src/proc-db programs, it could be a shell script, it could be a cmake script, it could be a ged script -- what matters is getting an output that includes entries for all of the various solid primitives in src/librt/primitives/table.cpp and reports which convert successfully, which fail (and shouldn't), which fail (and should), and/or which do not have an implementation. The output can be text or a webpage or similar, but should ideally just be something we can simply run and get a report. make sense?
Here's a diagram kind of showing what I had in mind for evaluating all evaluation conditions more systematically: image.png
Sean (Jul 17 2022 at 06:18):Basically you have pairs of geometry that you'd create in all possible configurations, which would be 5 x 5 x 5 = 125 pairings
Sean (Jul 17 2022 at 06:19):The images is just a 2D depiction, but the idea would be to create each pair in 3D using two primitives created in different positions and then booleaned together using each operator.
Sean (Jul 17 2022 at 06:22):this is just one height, of course, as there'd be 4 more heights to create pairings for (which would all be trivial using for() loops on the creation).
Sean (Jul 17 2022 at 06:27):For starters, can just focus on arb8, where you'd create the first red box probably centered near the origin, and then make a second green one bigger at each of the corresponding positions in a loop. It would then be easy to make the code create combinations of "Red u Green", "Red - Green", "Red + Green" (so 125 x 3 = 375 combinations). We could then also see what the results look like for sph/sph or arb8/sph or sph/rcc etc too.
Sean (Jul 17 2022 at 06:29):This would be very useful as we could also use it to test other algorithms like facetize, or create a fuzz test that creates random combinations looking for failures.
Sean (Jul 17 2022 at 06:44):could encapsulate the entire generation in a function like func(struct wdb *wdbp, enum type1, enum type2, int size1, int size2, double stepsize) and it'd automatically figure out where to generate all pairings based on those integral sizes and it can just iterate the creation of type2 across all positions (maybe more than 5 x 5 x 5) depending on stepsize.
GregoryLi (Jul 17 2022 at 08:54):Sean said:
Sean said:
After that's all done, I have an idea for something you could work on that would be helpful. Implement something that tells us which primitives convert to brep and which do not. This could be a program like some of the src/proc-db programs, it could be a shell script, it could be a cmake script, it could be a ged script -- what matters is getting an output that includes entries for all of the various solid primitives in src/librt/primitives/table.cpp and reports which convert successfully, which fail (and shouldn't), which fail (and should), and/or which do not have an implementation. The output can be text or a webpage or similar, but should ideally just be something we can simply run and get a report. make sense?
Here's a diagram kind of showing what I had in mind for evaluating all evaluation conditions more systematically: image.png
Thanks! The method is clear and I have made a similar framework. It's part of the primitives test, am I right?
GregoryLi (Jul 17 2022 at 09:05):Btw, the dplot command in NURBS Development Guide can not be used though Archer have the entrance.., Luckly plot and brep can perform most of its functions. I used them to debug the issues and found the error ssx, but I'm not very proficient in using it.
Sean (Jul 18 2022 at 02:38):What primitives test are you referring to? I think the answer is "no" ... what I described is a tool that does not exist. I'm suggesting you implement a tool that autogenerates all pairings of two specified primitive types.
Sean (Jul 18 2022 at 02:40):"the dplot command .... can not be used though Archer have the entrance" <-- I don't understand what you wrote there.
Sean (Jul 18 2022 at 02:42):dplot is a subcommand to the brep command. are you saying it doesn't work in archer? the doc may have been written prior to it becoming a subcommand (in which case you should update the nurbs dev guide -- it's an xml doc under doc/docbook)
GregoryLi (Jul 18 2022 at 02:49):Sean said:
What primitives test are you referring to? I think the answer is "no" ... what I described is a tool that does not exist. I'm suggesting you implement a tool that autogenerates all pairings of two specified primitive types.
the primitives test means "which primitives convert to brep and which do not". I get your idea.
GregoryLi (Jul 18 2022 at 02:51):Sean said:
"the dplot command .... can not be used though Archer have the entrance" <-- I don't understand what you wrote there.
image.png here is an example, I use dplot but it prompts for overlay usage.
GregoryLi (Jul 18 2022 at 02:53):I'ill check the map from dplot command to brep.
GregoryLi (Jul 18 2022 at 14:22):I've updated brep_arbintersection project. Now it can generate the 125 arb union cases and convert to brep, the other two operation are in development. How shall I test if one cases is correct or not? Shall I visualize them then record, or use some functions or properties such as how many brep faces, are they manifolds?
GregoryLi (Jul 18 2022 at 14:23):image.png
This is an error case.
Sean (Jul 19 2022 at 16:19):GregoryLi said:
[image.png](/user_uploads/1549/1g5LzD4kIYg6d8U6A2ccerpD/image.png) here is an example, I use dplot but it prompts for *overlay* usage.
Ah, I think I understand now! Yeah, I think there's two things going on there.. first dplot was moved to a brep subcommand, but the archer command table was not updated (bug #1). Second, the archer dplot command binding is calling ged_exec() on "dplot" and somehow that is matching the "overlay" command (bug #2).
Sean (Jul 19 2022 at 16:38):GregoryLi said:
I've updated brep_arbintersection project. Now it can generate the 125 arb union cases and convert to brep, the other two operation are in development. How shall I test if one cases is correct or not? Shall I visualize them then record, or use some functions or properties such as how many brep faces, are they manifolds?
We actually already have a tool that does a comparison and validation check that can probably be adapted to testing if the conversion worked, but a couple alternative ways comes to mind also. The ground truth is typically going to be the ray tracing result of the non-nurbs version. That's what the tool relies on, so for it, you just create the arb8's and it'll do the brep conversions and evaluate if they worked.
GregoryLi (Jul 20 2022 at 12:36):Sean said:
GregoryLi said:
I've updated brep_arbintersection project. Now it can generate the 125 arb union cases and convert to brep, the other two operation are in development. How shall I test if one cases is correct or not? Shall I visualize them then record, or use some functions or properties such as how many brep faces, are they manifolds?
We actually already have a tool that does a comparison and validation check that can probably be adapted to testing if the conversion worked, but a couple alternative ways comes to mind also. The ground truth is typically going to be the ray tracing result of the non-nurbs version. That's what the tool relies on, so for it, you just create the arb8's and it'll do the brep conversions and evaluate if they worked.
So how can I use the tool?
GregoryLi (Jul 20 2022 at 12:45):I generated the intersection and subtraction test cases and checked the results, only a few cases get correct answer... Most of the intersection cases result in brep obj with none faces, and most subtraction cases result in brep obj of the bigger arb8, with the part should be subtracted.
GregoryLi (Jul 20 2022 at 12:50):I almost thought I not testing properly. Here is the corresponding command to make a combination with intersection operation
r u.1 u arb_1 + arb_0
I think it mean the area arb_1intersects with arb_0, am I right?
Sean (Jul 21 2022 at 03:53):correct, that creates a region called u.1 that has "arb_1 + arb_0" (i.e., intersect)
Sean (Jul 21 2022 at 03:53):definitely want to either create all three operations or start with union
Sean (Jul 21 2022 at 03:54):which would be:
r u.1 u arb_1 u arb_0
Sean (Jul 21 2022 at 03:54):to keep this in order, really needs to use some meaningful names or it's going to be a mess
Sean (Jul 21 2022 at 03:59):probably would be good to use some form of grid notation like 0x0x0.r for the bottom corner, then 1x0x0.r for the first X-shifted position, etc until you get to 4x4x4.r in the opposite corner (or however many steps across there are)
Sean (Jul 21 2022 at 04:04):as for how to use the tool, check out the conversion.sh script that is in the sh/ dir and I think also gets installed. it's not been run in a while, so may need some minor updating (might not). by default, it will simply try to convert everything, which will actually be very informative.
Sean (Jul 21 2022 at 04:04):would be really cool to create a combination that has all the regions moved into a gridded position so they can all be visualized simultaneously
GregoryLi (Jul 21 2022 at 10:35):Sean said:
probably would be good to use some form of grid notation like 0x0x0.r for the bottom corner, then 1x0x0.r for the first X-shifted position, etc until you get to 4x4x4.r in the opposite corner (or however many steps across there are)
got it. So it seems intersect and subtract are kind of bad.
GregoryLi (Jul 21 2022 at 11:44):I think you can consider removing brep command file output in Release version. Now the test cases create thousands of brep files...
GregoryLi (Jul 21 2022 at 14:13):Do you mean this?
image.png
GregoryLi (Jul 21 2022 at 14:17):It works really cool with regular expressions!
GregoryLi (Jul 21 2022 at 14:17):
Sean (Jul 21 2022 at 14:48):GregoryLi said:
It works really cool with regular expressions!
Do you mean globbing? What are regular expressions being used for?
Sean (Jul 21 2022 at 14:53):GregoryLi said:
Do you mean this?
image.png
YES! This is exactly what I had in mind. Very nice. I'll have to look at your proc-db in close detail but I think it'd be helpful for debugging if all the pairings were the same identical two objects (just in different positions), and just let the relative sizes be specified/overridden as input parameters.
Sean (Jul 21 2022 at 14:56):so the fixed inner object would be something like 1^3 and the outer would be 3^3 in this example configuration, and we could then script it to compare 3^3 vs 2^3 or 2.5^3 vs 5.01^3 etc.. Currently using a stepsize of 5 positions, but that could be an input too, and just have it go across the entire potential range of interaction
Sean (Jul 21 2022 at 14:56):Well done.. this is going to be incredibly helpful!
GregoryLi (Jul 21 2022 at 15:06):Sean said:
GregoryLi said:
It works really cool with regular expressions!
Do you mean globbing? What are regular expressions being used for?
Yes, it's globbing.
GregoryLi (Jul 21 2022 at 15:13):Sean said:
GregoryLi said:
Do you mean this?
image.pngYES! This is exactly what I had in mind. Very nice. I'll have to look at your proc-db in close detail but I think it'd be helpful for debugging if all the pairings were the same identical two objects (just in different positions), and just let the relative sizes be specified/overridden as input parameters.
Do I need to upload the database? I don't konw how to use the same two objects to create 125 cases while visualizing them at the same time. Do you mean create the 1st brep obj, then update arb vertices positions followed by creating 2rd brep obj using the two arb?
GregoryLi (Jul 21 2022 at 15:21):Sean said:
so the fixed inner object would be something like 1^3 and the outer would be 3^3 in this example configuration, and we could then script it to compare 3^3 vs 2^3 or 2.5^3 vs 5.01^3 etc.. Currently using a stepsize of 5 positions, but that could be an input too, and just have it go across the entire potential range of interaction
I see, I think you mean we should make the project more configuable, such as to config the size of arb and stepsize?
Sean (Jul 21 2022 at 15:22):No you don't need to upload -- I'm referring to the code generating this. That you'd create the same two objects for all specified positions. It depends how you're creating the objects, whether you're a) creating primitives and moving them or b) creating primitives in position or c) creating just two primitives, then creating combs that moves them into position.
GregoryLi (Jul 21 2022 at 15:28):Now it is #b. It generates 125 pairs of arb in position, combine them using three operations.
GregoryLi (Jul 22 2022 at 14:52):This is a table about converting primitives to brep form, it's manually tested.
GregoryLi (Jul 22 2022 at 14:53):
GregoryLi (Jul 22 2022 at 14:57):I create the primitives with default values, then use brep command to convert them. epa and rhc went wrong with brep while part and bot went wrong with shaded render(maybe normal errors).
GregoryLi (Jul 22 2022 at 15:12):now here are at least three works to be done:
Sean (Jul 22 2022 at 19:31):Let’s start there @GregoryLi that 1234 is a great list to be working on. This is already helpful. The only other work that comes to mind is a tool that generates a grid of all primitives so we can regenerate your table automatically, retest easily as changes are made. There are already some tools that create primitives so one of them may already be suitable.
GregoryLi (Jul 23 2022 at 07:04):Ok, I think for non-soild primitives, such as half, annot, there is no need to test the brep function of them.
GregoryLi (Jul 26 2022 at 14:04):I use shell script to create the primitives, then convert them to brep format.
GregoryLi (Jul 26 2022 at 14:05):primitives:
image.png
GregoryLi (Jul 26 2022 at 14:08):brep format
image.png
GregoryLi (Jul 26 2022 at 14:12):Obviously there are some wrong with brep format. Now trying to evaluate them using 'nirt'.
Sean (Jul 28 2022 at 03:53):Yeah, looks like two, maybe epa and rhc are quite wrong -- probably a very obvious mistake if you want to try and see if you can fix them. One's clearly being created in the wrong position, the other appears to have a parameter or two in the wrong position or using a wrong value.
GregoryLi (Jul 28 2022 at 13:00):OK, I'm working on it.
GregoryLi (Aug 02 2022 at 13:56):I'm trying to debug rhc error. Now I've found that the Bezier curve of the bottom face is not on the plane, most likely it has something to do with second control point's weight.
GregoryLi (Aug 02 2022 at 13:59):It's confusing that the three control points are on the same plane while the curve is not. I'm looking at algorithms for bezier curves and source codes.
GregoryLi (Aug 02 2022 at 14:07):image.png
Here are two bugs to be fixed for the bottom plane:
GregoryLi (Aug 02 2022 at 14:08):
GregoryLi (Aug 04 2022 at 14:49):image.png This is the formula caculated by the source code.
GregoryLi (Aug 04 2022 at 14:50):image.png This is the correct formula.(https://pages.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/NURBS/RB-conics.html)
GregoryLi (Aug 04 2022 at 14:53):I think the reason is:
GregoryLi (Aug 04 2022 at 14:55):Hope I am correct....
I think #1 explains the bottom in brep format is larger than primitive format. #2 explains the curve of the bottom is not on the bottom plane.
Sean (Aug 04 2022 at 19:48):@GregoryLi impressive sleuthing on the math... have you tried fixing it? is that calculation happening in the rt_*_brep() function or elsewhere?
GregoryLi (Aug 05 2022 at 00:24):I have not tested #1. I plan to do it today.
GregoryLi (Aug 05 2022 at 00:26):It's in the src\other\openNURBS\opennurbs_evaluate_nurbs.cpp ON_EvaluateBezier function.
GregoryLi (Aug 05 2022 at 00:30):GregoryLi said:
I think the reason is:
- It misses a coefficient.
- We shall use relative coordinates while scaling the position of a vertex on the curve.
I've tesed #2, it could keep the curve on the plane. Although there are some other problems.
GregoryLi (Aug 06 2022 at 00:01):image.png The yellow curve is generated by adding the coefficient. It makes the bottom keep its height and on the plane, but it's wider..
GregoryLi (Aug 06 2022 at 00:07):The result makes sense from math. So the rounder one is corresponds to the formula given by the website.
GregoryLi (Aug 06 2022 at 00:11):@Sean If we use the rounder (yellow) curve to represent the bottom, the rhc primitive would be reshaped, I don't know if it leads to a big influence and shall I do it.
GregoryLi (Aug 06 2022 at 00:12):
GregoryLi (Aug 06 2022 at 00:13):GregoryLi said:
Sean If we use the rounder (yellow) curve to represent the bottom, the rhc primitive would be reshaped, I don't know if it leads to a big influence and shall I do it.
The code to be changed belongs to OpenNURBS(brlcad\src\other\openNURBS\opennurbs_bezier.cpp)
GregoryLi (Aug 06 2022 at 00:17):It influents the drawing of BezierCurve.
Sean (Aug 09 2022 at 17:55):@GregoryLi src/other is not our code to modify, and unlikely there's a bug in there... the bug would be in our calculations in src/librt/primitives/*
Sean (Aug 09 2022 at 17:56):now that I read your link more closely, note that https://pages.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/NURBS/RB-conics.html is going through the math for a PARABOLOID ... not HYPERBOLOID ...
Sean (Aug 09 2022 at 17:57):rhc is a right hyperbolic cylinder, i.e., it's defined by hyperboloids (which is why it doesn't match your yellow parabolic curve)
Sean (Aug 09 2022 at 17:58):I think you're maybe closer on point with #2 in that the scaling or translation is off
GregoryLi (Aug 09 2022 at 23:25):Sean said:
now that I read your link more closely, note that https://pages.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/NURBS/RB-conics.html is going through the math for a PARABOLOID ... not HYPERBOLOID ...
OK.... I saw the reference link in rhc_brep.cpp.
image.png
GregoryLi (Aug 09 2022 at 23:28):And I proved the reason why the curve is not on the plane is the formula(now it's Paraboloid formula) by OpenNURBS.
GregoryLi (Aug 09 2022 at 23:28):
GregoryLi (Aug 09 2022 at 23:28):
GregoryLi (Aug 09 2022 at 23:36):Those three surface are bottom surfaces of one rhc in different positions. So they share the same w and same P0 P1 P2 in local coordinate. By the formula, all the midpoint of the curve leads to 1/1+w multiply a fixed point in local coordinate then plus (0,0,0), and the screenshot proved it.
GregoryLi (Aug 09 2022 at 23:44):Sean said:
now that I read your link more closely, note that https://pages.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/NURBS/RB-conics.html is going through the math for a PARABOLOID ... not HYPERBOLOID ...
So I'd like go through hyperboloids formula and sort out the suitable parameter passing between OpenNURBS and BRL-CAD.
Sean (Aug 10 2022 at 00:47):I take it back about that being equations for paraboloid on the RB-conics page... I read it too quickly.. It'll take some concentration to fully grasp the context here to understand where the error(s) are with respect to the code..
GregoryLi (Aug 15 2022 at 05:45):Good news! I find the data we created does not fit with openNURBS algorithm. Our data is correct if we just look into alone, but evaluating bezier using Casteljau algorithm in openNURBS requires a scale for input data.
GregoryLi (Aug 15 2022 at 05:46):image.png this is the rhc primitive.
GregoryLi (Aug 15 2022 at 05:48):image.png this is the brep after debuging.
GregoryLi (Aug 15 2022 at 05:51):But their shapes are not exactly the same, working to solve it. image.png
GregoryLi (Aug 15 2022 at 05:52):image.png image.png hidden line and rt of brep.
GregoryLi (Aug 15 2022 at 15:35):Btw, the codes changed are in src/librt/primitives/rhc_brep.cpp
GregoryLi (Aug 15 2022 at 15:36):And the page (https://pages.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/NURBS/RB-conics.html) tells about HYPERBOLOID but not PARABOLOID, although it mentioned PARABOLOID in the beginning.
GregoryLi (Aug 19 2022 at 14:08):I spend several days understanding NURBS surface formula, looking into codes of epa elliptical parabolic NURBS surface and drawing, trying to debug and write a Transform function which is extremely complicated... I just found it's done in ON_NurbsSurface :upside_down:
GregoryLi (Aug 19 2022 at 14:25):
GregoryLi (Aug 19 2022 at 14:27):Now epa primitive without rotation can be converted to brep correctly. Going to solve epa bugs tommorrow.
GregoryLi (Aug 21 2022 at 15:08):I just solved all the problems when converting epa into brep format. This is the link https://github.com/BRL-CAD/brlcad/pull/56
GregoryLi (Aug 21 2022 at 15:11):image.png image.png The results are correct in any position and rotation.
GregoryLi (Aug 24 2022 at 13:19):I have solved the hyperbola problem in rhc.
GregoryLi (Aug 24 2022 at 13:23):Snipaste_2022-08-24_21-10-04.png
GregoryLi (Aug 24 2022 at 13:24):Snipaste_2022-08-24_21-10-13.png
GregoryLi (Aug 24 2022 at 13:24):Snipaste_2022-08-24_21-12-18.png
GregoryLi (Aug 24 2022 at 13:35):Here are the key formula about drawing rhc primitive and hyperbola...It's really dizzying
GregoryLi (Aug 24 2022 at 13:35):Snipaste_2022-08-24_21-29-23.png Snipaste_2022-08-24_21-29-32.png
Sean (Aug 29 2022 at 04:13):@GregoryLi Thank you so much for all the updates. I was away a few days but am catching up on everything.
I'm very impressed at the depth you've gone to solve the math.
Sean (Aug 29 2022 at 04:16):GregoryLi said:
Can you make a side-by-side comparison with non-brep rhc and brep rhc? It'll take me a while to digest your math, but this brep rendering looks parabolic to me ... The rt of both brep and non-brep forms should match identically.
Also, how does it compare with rpc and brep rpc?
GregoryLi (Aug 29 2022 at 08:59):case1.png case2.png case3.png case4.png case5.png case6.png
GregoryLi (Aug 29 2022 at 09:02):Here are six test cases for rhc. the green lines are rhc primitives, and the red lines are rhc primitives. the bigger the 'c' is, the larger the difference is. I don't know why yet.
GregoryLi (Aug 29 2022 at 09:07):the brep converting of rpc primitives are correct with change its parameters and rotations.
GregoryLi (Aug 29 2022 at 09:14):The rhc primitive is hyperbola at least for it's parameters.
''The rational Bézier curve defined by three non-collinear control points P0, P1 and P2 and weights 1, w and 1 is a hyperbola, a parabola or an ellipse if w is greater than, equal to, or less than 1.'' according to RB-conics
GregoryLi (Aug 29 2022 at 09:18):GregoryLi said:
Snipaste_2022-08-24_21-29-23.png Snipaste_2022-08-24_21-29-32.png
Picture 1 here is some steps of drawing conic arcs. I didn't finish the math sluthing because I thought the rhc error was caused by hyperbola parameters.
GregoryLi (Aug 30 2022 at 08:29):I'm updating previous arb8intersection project to make it more configurable and not limited to arb8 primitives.
GregoryLi (Aug 30 2022 at 08:30):@Sean Do you have any suggestion about to do what next?
GregoryLi (Aug 30 2022 at 08:32):now here are at least three works to be done
GregoryLi (Aug 31 2022 at 06:48):Here are two pull requests. who should I look for as a reviewer?
https://github.com/BRL-CAD/brlcad/pull/57
https://github.com/BRL-CAD/brlcad/pull/56
Sean (Sep 01 2022 at 02:51):@GregoryLi I'll definitely be reviewing them. They're in my evening review queue. Just a few things ahead of them.
Sean (Sep 01 2022 at 02:52):I did take a quick look at them when you submitted them and first glance looked really good.
Sean (Sep 01 2022 at 02:53):As for what to do next, what do you think would be the most helpful? I have my opinions on this, but wondering what you think.
GregoryLi (Sep 01 2022 at 06:27):Sean said:
GregoryLi I'll definitely be reviewing them. They're in my evening review queue. Just a few things ahead of them.
Thanks a lot. They haven't been dealt with for ten days so I care about if they are on the schedule.
GregoryLi (Sep 01 2022 at 06:33):I have extended the boolean and brep converting of arb8 primitive to sph and rcc primitives. Some of the results are wrong in missing faces, but I think extending primitives is not really helpful in locating the problem or fix it.
GregoryLi (Sep 01 2022 at 06:35):So I'd like to locate error codes and scenarios of arb boolean test cases as my first step, meanwhile I can update NURBS Boolean Guide.
GregoryLi (Sep 06 2022 at 13:36):@Sean I have made some progress in making primitives boolean test cases more configurable, locating boolean error codes and getting started with fix bool_eval_development.xml. But I think it's a long process to start fixing boolean operation because it needs to read papers and codes. I'm not sure if we can see some substantial change before GSOC deadline.
GregoryLi (Sep 06 2022 at 13:39):I remember a good work that the dplot command in archer is incorrect in some cases. Do you think fixing it is more feasible and meaningful?
GregoryLi (Sep 06 2022 at 13:41):just like this image.png
GregoryLi (Sep 06 2022 at 13:44):Sean said:
GregoryLi said:
[image.png](/user_uploads/1549/1g5LzD4kIYg6d8U6A2ccerpD/image.png) here is an example, I use dplot but it prompts for *overlay* usage.Ah, I think I understand now! Yeah, I think there's two things going on there.. first dplot was moved to a brep subcommand, but the archer command table was not updated (bug #1). Second, the archer dplot command binding is calling ged_exec() on "dplot" and somehow that is matching the "overlay" command (bug #2).
it has been clarified before.
Sean (Sep 08 2022 at 17:35):GregoryLi said:
I remember a good work that the dplot command in archer is incorrect in some cases. Do you think fixing it is more feasible and meaningful?
Yes, fixing any minor bugs like that are always appreciated. They're nuisance and sometimes distractions, and sometimes outright significant problems so yes .. please do :)
GregoryLi (Sep 16 2022 at 16:21):I have fixed ploting faces one by one for 'dplot xx faces' cmd by plot split face files instead of outloop curves. But when it comes to plot all the faces at last, the 'overlay' cmd can't plot all the faces(split face files) at the same time. How to solve this problem?
GregoryLi (Sep 16 2022 at 16:24):And I tried some boolean and brep cases, the results are wrong and the brep function doesn't involve any face trim operations(no ssx events), so some cmds of dplot just can't be tested successfully....
GregoryLi (Sep 16 2022 at 16:27):Snipaste_2022-09-17_00-26-24.png Snipaste_2022-09-17_00-26-30.png Snipaste_2022-09-17_00-26-40.png Here are some snipastes of dplot xx faces cmd
Sean (Sep 16 2022 at 20:29):I'm not fully understanding. Can you give me a complete mged transcript I can repeat on my side (including arb creation)?
Sean (Sep 16 2022 at 20:30):you should be able to overlay multiple plot files at the same time (or sequentially) ... at least I think so!
GregoryLi (Sep 17 2022 at 01:47):OK, now I can overlay multiple plot files sequentially.
GregoryLi (Sep 17 2022 at 01:51):Here are snipastes by plotting bool*_split_face*_outerloop_curve*.plot3 files. To show these curves, you need to rollback to https://github.com/GregoryLi0/brlcad/tree/b1a76f1d06f3708928b91a51c29d3a89bb057010
GregoryLi (Sep 17 2022 at 01:54):image.png image.png image.png
As shown in snipastes, only 1 or none curve of each face is drawn.
GregoryLi (Sep 17 2022 at 02:11):arb_simple_brep.sh This is a simple shell to regenerate plot files.
GregoryLi (Sep 28 2022 at 13:48):I was absent because of getting back to school and COVID-19 policy. I did some unreported work
GregoryLi (Sep 28 2022 at 13:50):Now dplot is almost fixed. I roll back to a previous commit which can cause ssx event files to help debug dplot cmd. But the overlay cmd can't plot every .plot3 files.
GregoryLi (Sep 28 2022 at 13:52):For example, some of ssx_event.plot3 and clipped_curve*.plot3 files can't be plotted using overlay cmd, so I have to draw other files with the same effect if possible.
GregoryLi (Sep 28 2022 at 13:52):
Sean (Sep 29 2022 at 04:00):welcome back @GregoryLi !
The plot interface is entirely for devs, so it's not critical but do you have any more info on why they can't be plotted using the overlay command? What happens? Does it crash? Does it just not render correctly? Usage error? Are the plot files valid?
GregoryLi (Sep 29 2022 at 11:11):Sean said:
welcome back GregoryLi !
The plot interface is entirely for devs, so it's not critical but do you have any more info on why they can't be plotted using the overlay command? What happens? Does it crash? Does it just not render correctly? Usage error? Are the plot files valid?
it didn't crash or render. Here is one example: overlay the first file get error and nothing plotted.
GregoryLi (Sep 29 2022 at 11:11):
GregoryLi (Sep 29 2022 at 11:12):overlay the second file get correct image.
GregoryLi (Sep 29 2022 at 11:12):
GregoryLi (Sep 29 2022 at 11:15):I don't know whether the plot files are valid or not. I'm finding it out and updating NURBS Boolean Evaluation Development Guide
GregoryLi (Oct 04 2022 at 14:10):@Sean After switching the base commit to a previous one, it's much more clear to debug brep and boolean function. The brep cmd can introduce trimmed faces. To be more clear, run the same brep command with same data and codes before 8a508c8f commit in 2021-11-09, the ssx events are recorded. but up-to-date codes won't record ssx events. I'm comparing related code changes and debuging the 8a508c8f commit.
GregoryLi (Oct 04 2022 at 14:16):image.png image.png
Here are two screenshot to show the difference of two brep objects created using same cmd and same union.
GregoryLi (Oct 04 2022 at 14:20):I updated some of the NURBS Boolean Evaluation Development Guide. But I'm not sure if the plot files are not valid or not loaded correctly. All the codes related to generate or draw plot files seems correct... I'm still tracking.
Sean (Oct 07 2022 at 05:06):GregoryLi said:
image.png image.png
Here are two screenshot to show the difference of two brep objects created using same cmd and same union.
If I'm not mistaken, they both look wrong, correct?
Sean (Oct 07 2022 at 05:08):@GregoryLi will you be writing up a final report? A brief 1-page summary of everything you did this GSoC would be very valuable to have and a nice showcase of your work. I'd hope you'd particularly emphasize the work you put on the testing tool as that should be very helpful for identifying the current functionality status.
Sean (Oct 07 2022 at 05:11):GregoryLi said:
Sean said:
welcome back GregoryLi !
The plot interface is entirely for devs, so it's not critical but do you have any more info on why they can't be plotted using the overlay command? What happens? Does it crash? Does it just not render correctly? Usage error? Are the plot files valid?
it didn't crash or render. Here is one example: overlay the first file get error and nothing plotted.
Without knowing if the plot files are valid or not, it's almost impossible to debug. Basically.. finding issues in the plotting isn't going to be terribly helpful unless you debug and understand them enough to also fix them. There's simply too many other things going on to stop and chase down dev infrastructure issues that might simply be bad input... unless you can figure it out.
GregoryLi (Oct 07 2022 at 05:16):Sean said:
GregoryLi said:
image.png image.png
Here are two screenshot to show the difference of two brep objects created using same cmd and same union.If I'm not mistaken, they both look wrong, correct?
Yes, the two results are both wrong. For brep boolean function, I have located the error that the trimmed faces are not generated and stored correctly.
GregoryLi (Oct 07 2022 at 05:18):If we trim one surface with a closed curve, we should get two subsurfaces,but we only get one now(commit 8a508c8f).
Sean (Oct 07 2022 at 05:18):you should definitely document that somewhere so it can be reproduced and inspected in specific detail
Sean (Oct 07 2022 at 05:18):two subsurfaces? how is that?
GregoryLi (Oct 07 2022 at 05:20):Yes. I'm sorting out the work I have done and recording possible problems and solutions.
GregoryLi (Oct 07 2022 at 05:23):for example, we trim the black face with red curves, we shall get inner area and outer area. But now we can get one of them. image.png image.png
GregoryLi (Oct 07 2022 at 05:28):Here is a more intuitive example. I created two arb8 and convert the union to brep form. I keep all the subsurfaces no matter it should be kept or not. If everything works correct, we shall get two arb8 with trim lines.
GregoryLi (Oct 07 2022 at 05:31):But know each origin face creates one subface.image.png image.png
GregoryLi (Oct 07 2022 at 05:34):For this case, we have 12 origin faces(two arb8), we shall get 18 trimmed subfaces(8+10). But now we only get 12 trimmed subfaces.
GregoryLi (Oct 07 2022 at 05:36):GregoryLi said:
But know each origin face creates one subface.image.png image.png
I'm now debuging at commit 8a508c8f. The up-to-date code does not trim the surface properly...
GregoryLi (Oct 07 2022 at 05:38):I will sort out the work I have done and record possible problems and solutions before final evaluation, and continue to debug boolean funciton after final evaluation. :smile:
GregoryLi (Oct 09 2022 at 01:12):@Sean Here is my final report. Is there anything to be modified or given more details? Shall I send it to the mailling list? Final_Report.pdf
GregoryLi (Oct 09 2022 at 14:08):I have fixed some of the boolean function. The up-to-date code won't record trimmed faces. Now it can record one of them.
GregoryLi (Oct 09 2022 at 14:13):
GregoryLi (Oct 09 2022 at 14:17):GregoryLi said:
If we trim one surface with a closed curve, we should get two subsurfaces,but we only get one now(commit 8a508c8f).
And I believe the reason for missing subfaces is about trimming face with ssx_curve. The related source code is split_trimmed_face() function in boolean.cpp.
GregoryLi (Oct 09 2022 at 14:19):This is a summary for the function. image.png
GregoryLi (Oct 09 2022 at 14:20):I think we shall get two subfaces for not closed ssx_curve, as shown at the bottom of the picture.
GregoryLi (Oct 18 2022 at 10:39):Thanks @Sean . It's really a great summer to work with you! I will continue to contribute to the community :)
GregoryLi (Oct 18 2022 at 10:44):I'm debugging split_face_into_loops() function these days, hope to get two closed loop instead of one. I believe it will help a lot for boolean function. But I'm busy with school things in the next week or two. I will report on my progress as soon as I get the result :)
GregoryLi (Oct 28 2022 at 13:03):@Sean I'm glad to tell you I have located the lowest level bug. The ON_PolyCurve::IsClosed() function of OpenNURBS has no tolerance about FindNextGap(). I simply remove the judgement about IsClosed() of splitted loop, the test case works well!
GregoryLi (Oct 28 2022 at 13:04):
GregoryLi (Oct 28 2022 at 13:07):I will run previous test intersection cases to see if it works well.
GregoryLi (Oct 28 2022 at 13:10):Is code of OpenNURBS can't be modified? I think we need to add a tolerance to FindNextGap(), or we have to come up with another way to test is the loop closed.
Sean (Nov 04 2022 at 05:22):Hmm.. @GregoryLi FindNextGap() utilizes a tolerance that is at least as big as ON_ZERO_TOLERANCE in determining whether there's a gap. In HasGapAt() it uses that along with some extra logic to take the curvature into account as well, but is fundamentally underpinned by ON_PointsAreCoincident() which is also whether points are within ON_ZERO_TOLERANCE or ON_RELATIVE_TOLERANCE.
Sean (Nov 04 2022 at 05:24):We should really not be modifying OpenNURBS. Is it the case that the curve is discontinuous perhaps? Looking at the screenshot, it appears to be discontinuous (the stair-stepping), and that's a bit unexpected. Do you know why it's like that?
GregoryLi (Nov 26 2022 at 05:43):Hi, I had a busy month and need two weeks to deal with my school things. I will check it these days if I have time. I stepped though boolean function and found it's closed. I thought it was caused by some other judgements.
GregoryLi (Feb 27 2023 at 13:43):Hi, I'm back :)
I tested the brep intersection cases and it seems it haven't be fixed. So I'm trying to finish it these days, and finish my previous PRs.
GregoryLi (Mar 05 2023 at 14:56):Now I can generate all trimmed surfaces by removing wrong judgement (polycurve->IsClosed() in boolean.cpp), here are something to be done:
GregoryLi (Mar 06 2023 at 03:04):To generate all trimmed surfaces, some curve of outerloop_segs (in split_face_into_loops(), libbrep/boolean.cpp) are in dimen 2 while others are 3 dimension. Points on 2d curve only get x y value when evaluating using OpenNURBS though they have 3d info, while 3d curve get x y z value. So it’s a mass to determine whether 2d point and 3d point overlap or not. It leads to we get false answer calling ON_PolyCurve::IsClosed() with correct data.
I think simply removing the OpenNURBS judgement is fine because we already have codes that check if it’s closed in boolean.cpp.
GregoryLi (Mar 06 2023 at 03:07):Maybe converting 2d curves to 3d curves when generating trimmed surfaces is also a good method, because the 2d curves already have all the 3d infos we need. What do you think? @Sean
GregoryLi (Mar 06 2023 at 14:13):You can see my code here. https://github.com/GregoryLi0/brlcad/tree/brep_boolean_debug
Btw, I can compile the latest brlcad code of main branch. But archer crashes as soon as I open it, both on ubuntu and windows...
starseeker (Mar 06 2023 at 14:55):Just noticed the Archer crash here as well.
starseeker (Mar 07 2023 at 02:35):@GregoryLi I think Archer is working again?
GregoryLi (Mar 07 2023 at 02:47):starseeker said:
GregoryLi I think Archer is working again?
Yeah, it works well on ubuntu now.
GregoryLi (Mar 08 2023 at 07:12):GregoryLi said:
To generate all trimmed surfaces, some curve of outerloop_segs (in split_face_into_loops(), libbrep/boolean.cpp) are in dimen 2 while others are 3 dimension. Points on 2d curve only get x y value when evaluating using OpenNURBS though they have 3d info, while 3d curve get x y z value. So it’s a mass to determine whether 2d point and 3d point overlap or not. It leads to we get false answer calling ON_PolyCurve::IsClosed() with correct data.
I think simply removing the OpenNURBS judgement is fine because we already have codes that check if it’s closed in boolean.cpp.
I find it has been solved in the latest edition by standardizing data into 3-d. image.png image.png
GregoryLi (Mar 08 2023 at 07:15):GregoryLi said:
Now I can generate all trimmed surfaces by removing wrong judgement (polycurve->IsClosed() in boolean.cpp), here are something to be done:
- Look into and fix IsClosed() function. Now the test data is correct but get wrong answer.
- The code to decide whether to keep trimmed surfaces is wrong.
- Look into and fix stair-stepping cases.
So it semms the 1st question is fixed now. Running my arb8 test cases will confirm it.
Sean (Mar 09 2023 at 08:25):You mean IsClosed() is fixed? It's possible our openNURBS update introduced some fixes but I thought we were seeing some other issue too (related to the stair-stepping and general book-keeping).
GregoryLi (Mar 10 2023 at 06:39):I'm looking into stair-stepping, do you mean it like this? image.png
GregoryLi (Mar 10 2023 at 06:41):@Sean What does book-keeping mean? Is there any test case?
Sean (Mar 10 2023 at 20:31):That's not specifically what I was referring to -- just the general issue of having two boxes that align on just their edge evaluating incorrectly.
As for book-keeping, that refers to how the code keeps track of what it is doing, what it has done, what it needs to do next, etc. From the failure examples I've seen, it looks like the code sometimes incorrectly determines when two things intersect and/or performs an edit to join/split the surfaces and gets it wrong.
GregoryLi (Mar 16 2023 at 11:38):Good news! Just fixed the bug that jump over categorize_trimmed_faces(). Now the simple two arb8 union case is correct.
GregoryLi (Mar 16 2023 at 11:39):
GregoryLi (Mar 16 2023 at 11:40):I will add the arb8 intersection grid to test it. image.png
Sean (Mar 16 2023 at 18:30):Wow, that's great @GregoryLi .. is the error and fix easy to explain? How'd you figure it out?
GregoryLi (Mar 17 2023 at 01:53):@Sean Yeah, it's quite simple. :sweat_smile: One former commit tried to add cache vectors instead of modifying output value, but some judging code is not modified to check the cache vector. This resulted in skipping lots of important codes.
More clearly, in get_face_intersection_curves() of boolean.cpp, we use st1&st2 as a cache vector for surf_tree1&surf_tree2, but we still use surf_tree2 to detect exceptions, causing ON_Intersect() to always be skipped.
GregoryLi (Mar 17 2023 at 05:30):I created a sheet of arb8 unions. Now we can get all subfaces properly, but miss some of them in the end. It means bug exists in categorize_trimmed_faces() very likely.
image.png image.png
GregoryLi (Mar 17 2023 at 05:36):The intersection cases also show missing or redundant subfaces.
image.png
Sean (Mar 17 2023 at 08:08):It sounds like you're getting more and more familiarized with the issues in the code and how to fix them! That's excellent progress and understanding.
Sean (Mar 17 2023 at 08:09):GregoryLi said:
I created a sheet of arb8 unions. Now we can get all subfaces properly, but miss some of them in the end. It means bug exists in
categorize_trimmed_faces()very likely.
image.png image.png
Looks like there's a couple other errors in there too. I see a missing face and all the dark faces have to be wrong too.
GregoryLi (Mar 18 2023 at 02:54):Sean said:
GregoryLi said:
I created a sheet of arb8 unions. Now we can get all subfaces properly, but miss some of them in the end. It means bug exists in
categorize_trimmed_faces()very likely.
image.png image.pngLooks like there's a couple other errors in there too. I see a missing face and all the dark faces have to be wrong too.
Yes, I think they are all caused by categorize_trimmed_faces().
Last updated: Nov 15 2024 at 00:49 UTC