I am doing research on project NURBS Editing Support in BRL-CAD
okay, so for that you don't really need to install anything, you just need to compile. the tools exist in the build tree and can be run from there on the command line
the primary GUIs of the main repo are called MGED and Archer in src/mged and src/archer respectively. there's also other experimental GUI work in src/qged and in another separate repository called arbalest
nurbs logic is in src/libbrep and src/other/ext/openNURBS, and all editing commands are in src/libged
yes I go through it
so for that project, you have to understand the code well enough to figure out a propopsal
ok first I will go through the code
but the general idea expected would probably be to first create basic editing commands (CLI) in src/libged which becomes command-line commands in mged and archer
then if you got that working, the next step would be to figure out what GUI to integrate that with, whether mged or archer or qged or arbalest
sir , figure out a whole code , that is hard for me
Sean said:
nurbs logic is in src/libbrep and src/other/ext/openNURBS, and all editing commands are in src/libged
Are you looking here for code, right? @Neeraj Sharma
Himanshu Sekhar Nayak said:
Sean said:
nurbs logic is in src/libbrep and src/other/ext/openNURBS, and all editing commands are in src/libged
Are you looking here for code, right? Neeraj Sharma
yes sir
Neeraj Sharma said:
Himanshu Sekhar Nayak said:
Sean said:
nurbs logic is in src/libbrep and src/other/ext/openNURBS, and all editing commands are in src/libged
Are you looking here for code, right? Neeraj Sharma
yes sir
so any other option for familiar with the NUBRS base code
There's not a better option than reading the code as that is the latest status of the implementation, but there are certainly books and websites that explain what NURBS are and how to work with them. There IS a NURBS development guide in BRL-CAD, but that's not particularly relevant for editing -- still you can see it in doc/docbook/devguides/bool_eval_development.xml
Sean said:
There's not a better option than reading the code as that is the latest status of the implementation, but there are certainly books and websites that explain what NURBS are and how to work with them. There IS a NURBS development guide in BRL-CAD, but that's not particularly relevant for editing -- still you can see it in doc/docbook/devguides/bool_eval_development.xml
can you exactly share location ,where the base code of implementing of NURBS
Neeraj Sharma said:
Sean said:
There's not a better option than reading the code as that is the latest status of the implementation, but there are certainly books and websites that explain what NURBS are and how to work with them. There IS a NURBS development guide in BRL-CAD, but that's not particularly relevant for editing -- still you can see it in doc/docbook/devguides/bool_eval_development.xml
can you exactly share location ,where the base code of implementing of NURBS
bezier curve
-> B-Spline curve
-> rational B-Spline curve
bezier surface
-> B-Spline surface
-> rational B-Spline surface
Neeraj Sharma said:
can you exactly share location ,where the base code of implementing of NURBS
The location information was already provided earlier the first time you asked where -- it's a lot of code spanning multiple directories and those directories were itemized. Honestly if that wasn't enough information, then you may be attempting to propose a topic far too complex for your abilities. NURBS is an advanced topic. I would suggest focusing on a different project proposal that is a bit easier to navigate.
17 messages were moved here from #general > Compiling BRL-CAD by Sean.
I also moved this topic thread since you had hijacked the thread about compiling BRL-CAD with unrelated discussion about NURBS. Both remain accessible.
Sean said:
Neeraj Sharma said:
can you exactly share location ,where the base code of implementing of NURBS
The location information was already provided earlier the first time you asked where -- it's a lot of code spanning multiple directories and those directories were itemized. Honestly if that wasn't enough information, then you may be attempting to propose a topic far too complex for your abilities. NURBS is an advanced topic. I would suggest focusing on a different project proposal that is a bit easier to navigate.
BRLCAD issue section contain the project list or there another list of projects
can you tell me easier project or all project list those are mentioned in GSOC'23
All the project ideas have a difficulty rating.
They're all listed at https://github.com/opencax/GSoC/issues?q=is%3Aopen+sort%3Aupdated-desc+label%3A%22GSoC+2023%22+label%3A%22Project%3A+BRL-CAD%22
We're an umbrella org, so each project has a separate list: https://opencax.github.io
I'm wondering how do we use NURBS editing operations? I have not find how to create a NURBS curve or surface directly in mged or archer. I see we can get the NURBS form of some primitives. Do we need additional cmd to create and modify NURBS directly?
I noticed some CAD software have a unique tool for creating NURBS.
image.png
I don't understand what "wrapping the openNURBS library by a scripting language" means here NURBS Editing Support in BRL-CAD. Are commands of mged command form suffice? Or do we need to wrap it for other purposes?
GregoryLi said:
I have not find how to create a NURBS curve or surface directly in mged or archer.
That's the point: There is no such functionality. The only way to create (openNURBS) NURBS, is by importing Rhino files as BLOBs.
GregoryLi said:
I don't understand what "wrapping the openNURBS library by a scripting language" means here NURBS Editing Support in BRL-CAD. Are commands of mged command form suffice? Or do we need to wrap it for other purposes?
The mged commands trigger functions in libged, which call functions in other libraries. So, the "other purposes" could do something similar than the function in libged. I.e., it would be sufficient to implement it up to the libged TCL hooks.
BTW, the main primitive creation command is in
, implemented in src/libged/typein/typein.c.
Daniel Rossberg said:
GregoryLi said:
I have not find how to create a NURBS curve or surface directly in mged or archer.
That's the point: There is no such functionality. The only way to create (openNURBS) NURBS, is by importing Rhino files as BLOBs.
OK, I think create NURBS curve & surface using mged command is be a good target to start with.
@GregoryLi Nearly all of BRL-CAD's non-NURBS implicit solids (e.g., ell, torus, arb8, tgc, etc) have function implementations that express them in NURBS form (like in your screenshot they show torus and some other starter shapes in addition to curve and surface creation). It's the rt__brep() callback which you can see in all the src/librt/primitives//*.cpp subdir files. As mentioned, conversion is one current way to get NURBS brep entities, but also a way is the mged "brep" command. That converts an existing solid into a brep solid.
That said, you're on the right track thinking about how to create them first. That's why I mentioned src/proc-db/brep_simple.cpp and friends where you can see examples how they're created in code, one curve, edge, trim, and surface at a time.
I created one cylindrical side in proc-db.
image.png
I noticed we have bspline_brep.cpp in librt/primitives/bspline, but it seems we have no corresponding option of in
command. Maybe we should call the function through in
command to create NURBS?
@GregoryLi Note that there are two boundary representation implementations in librt. One is the 'bspline' entity and the other is the 'brep' entity. What you're looking at there is the older bspline which implements boundaries by defining bspline patches. It works, but it's a slow 1980's approach and yes it also lacks an 'in' interface. The 'brep' entity (see src/librt/primitives/brep and src/other/ext/openNURBS) is the modern approach.
There's very likely code and algorithms in 'bspline' that should/could be migrated to 'brep', particularly for boolean evaluation, but the datastructures are different so any utilization will require some work.
Yeah, I'm trying to generate the 'brep' form NURBS surface. I think the difference is that 'brep' form need to create vertex, curve, edge, trim compared to 'bspline' form. Am I right?
Besides, I find one possible problem... If a 'brep' object have a edge which is a loop in Cartesian space but not a loop topologically, the 'brep' is not valid(b->IsValid()=false). And the code belongs to openNURBS. Just like the cylindrical side.
image.png
GregoryLi said:
Yeah, I'm trying to generate the 'brep' form NURBS surface. I think the difference is that 'brep' form need to create vertex, curve, edge, trim compared to 'bspline' form. Am I right?
Well the API is different because 'brep' uses the openNURBS API. They both create parametric surfaces that are stitched together with vertices, curves, and edges. 'bspline' doesn't to trimming curves whereas 'brep' does use trimming curves is probably the biggest practical difference in construction.
somewhere in the code is a function that converts a bspline to a brep. I think that might even be what I did to fix ray tracing for bspline. The only reason the bspline code is still there is for reading/writing old .g files with them and as a reference if there are functions in there that might be useful for migrating to 'brep'
GregoryLi said:
Besides, I find one possible problem... If a 'brep' object have a edge which is a loop in Cartesian space but not a loop topologically, the 'brep' is not valid(b->IsValid()=false). And the code belongs to openNURBS. Just like the cylindrical side.
image.png
Yes the topological structure of brep can be valid/invalid and really unrelated to the geometric structure. It's our job to make sure they match and form a valid definition.
Your cylinder is a valid surface but is not a valid brep because it doesn't enclose a volume.
Thanks! Very detailed and interesting distinction.
@Sean I'm wondering if we wrap nurbs in brep
format, what format should users edit them in?
For example, One user want to 'attach' two spline curves. So he/she should have two curve in brep format like curve1.brep
and curve2.brep
, then run mged command like attach curve1.brep curve2.brep [other parameters]
. BRL-CAD core will check if curve1.brep
and curve2.brep
each owns a single curve. If not, the operation is illegal. Otherwise BRL-CAD core will perform attach operation. Am I right?
@GregoryLi you might have some misunderstanding. You're not "wrapping" nurbs in brep format. nurbs are defined using a boundary representation format so for all intents and purposes nurbs==brep. I also don't think it would make any sense to put curves into separate breps if the point is to join them. What you'd probably do is create a brep, add a curve to it, add another curve to it, join them.
Did you read the the src/proc-db/brep_simple.cpp ?
Run that and look at the model it produces in mged. Now imagine wanting to edit it in mged to move a vertex. What would that command look like. That's a first step.
Once you can move a vertex, then try moving an edge. After you can move a vertex and an edge, now what about moving a face. Figure out what that looks like from an editing perspective. Once you can move those pieces around, what about deleting a vertex, or deleting an edge, or even deleting a face? What about adding a vertex in the middle of an edge? What about the middle of a face? And so on... that's the general idea for building up a command that will let you do all of that in a user-friendly way.
Once you can do all that, how about generating that same brep_simple object on the command line.. figure out what that looks like.
At that point, you'll need to figure out how to deal with trimming curves, control points, and knot values too.
Sean said:
Run that and look at the model it produces in mged. Now imagine wanting to edit it in mged to move a vertex. What would that command look like. That's a first step.
Yeah, I can imagine that. So what we want to do is editing nurbs that belongs to brep, not separate nurbs?
there are no separate nurbs... brep==nurbs
they're one in the same. so if we have a brep, we want to edit the "brep nurbs" structures it contains. we need the ability to add those structures to an empty or existing brep too (so we can manually create things like brep_simple does, but as a user).
As far as my understanding from openNURBS, one brep contains curves, surfaces(geometry) and vertexes, edges, trims, loops, faces(topology) info, where curves and surfaces may be NURBS. So maybe a more precise description would be there is no separate NURBS, they shall be geometries of brep?
I want to understand how to use NURBS editing operations from user perspective.
For operation like "move a vertex":
brep *.brep plot V *
or other operationMoveVertex [brep name] [vertexid] [position to be moved]
For operation like "create and attach two spline curve":
AddCurve [brep_name] [curve info]
twice to add two spline curve into the brep object.AttachSpline [brep name] [curveid_1] [curveid_2]
to attach the two spline@Sean @Daniel Rossberg I looked though the structure of brep and how to create a brep object. And I'm trying to figure out how users use the NURBS editing. I checked blender and some other softwares and libs. I think our operating logic is different from theirs. They are editing one separate NURBS curve/surface directly. Am I right? :grinning_face_with_smiling_eyes:
I think, you are on the right way. The details depend on how the data is stored in openNURBS. Do the curves and/or points have an ID? Or just an index in an array? Etc..
What I had in mind, was a command like in myNurbs.s brep <parameters>
. <parameters> being something like "[curve 1 info] u [curve 2 info] ...". I.e., the real task would be to draft a concept for [curve info] and implement it.
The task of editing NURBS is not important at this level/stage. E.g., at the lower level, a vertex doesn't need to be movable. It would be good too, if the curve, the vertex belongs to, could be replaced by another curve (with the vertex moved).
Then, it would be a task of the GUI, to take the original curve, move a vertex there, and replace the original curve with the changed one.
Yeah, I think I get the point! I'm writing my proposal.
..
@GregoryLi you're on the right track thinking about what a CLI might look like. Editing can happen in a variety of ways as noted. Could be a write/overwrite/delete interface like daniel mentioned where you just replace entities with different entities the have the edit. Could propose a set of relevant subcommands to an existing command (e.g., "brep translate mybrep.edge[54] 100 0 0". Could be something hooked into the existing 'adjust' command. There are tradeoff considerations with all of them. You'd probably want to budget some time to study options during the bonding phase to finalize exactly what approach will be taken, but you should understand what those options are and explain them in your proposal so you can demonstrate you've thought about this some.
@Sean @Daniel Rossberg What's the difference between 'attach' and 'connect' two NURBS curve? I can imagine two cases:
ConcatNC
in AyamThe points/curves/surface only have an index in an array of brep, without a name. So it is not easy to perform nurbs editing operations for users. They should find the index by drawing and NURBS operation will change the index.
And I'm thinking about if it's proper to do NURBS operation in brep. For example, we have a cube 'brep' in brep format, and we just perform 'trim' operation on one edge curve or 'connect' two edge curve. This will make the 'brep' object irregular(mass up topology and relationship between topology and geometry entities of the cube). Shall we check if the operation is legal to keep some property of the brep valid?
I'm a bit confused about the definition and implementation of some operations.
projection
for curve to surface operation
Rebuild/Simplify(remove unnecessary control points)
function in surface operations
Trim (evaluate to untrimmed)
in surface operations
I had hoped that you would tell me that :wink:
I didn't looked at the openNURBS/brep internals yet.
I thought we have a detailed description and goal about operations in NURBS Editing Support.:sweat_smile:
It's okay if not! I think the operations may not be limited to the wiki, we need NURBS editing operations just like any other lib such as Ayam and Blender. I have describled these NURBS editing operations in detail and hope to extend the operations as one part of my proposal. My proposal will be relatively long, so I will send out the first half of it as soon as possible to discuss with you.
GregoryLi said:
I'm a bit confused about the definition and implementation of some operations.
you can certainly propose changing what was written up on the wiki. I think it's mostly taking a very low-level approach of operations that could be performed on specified curves and surfaces, but it's certainly not the only approach possible.
I don't personally see operations #2 or #3 being important and #4 is a "nice to have" but not strictly necessary for editing either.
They won't/don't need to be limited to what's on the wiki. I think that was just envisioned as a potential starting point approach.
Myself, I would approach it the way I mentioned a few days ago. Assume you have the brep_simple object. Now make it so you can move any of the vertices, edges, or surfaces (maintaining connectivity/topology) of that cube. Once that's all working, and that'd likely take a month, then focus on creating that brep_simple cube on the command-line (however you can achieve that easily). That'd be basic construction and another month. With those two achieved, just about any edit operation should be possible and it stays focused on the end-user's perspective, not the data structure.
Basically keep it simple. Do the simplest things first like moving existing things around, and tackle the harder problems when nothing simpler remains.
OK, I will start with simple operations like create, move vertices as you said. Think of the wiki as a borader suggestion.
I give a detailed description about operations on wiki. I will update the wiki if my description meets our expectations about NURBS editing. detailed description
The most important point from the task description is for me:
The key-feature would be to have ged command(s) that lets you build NURBS objects from scratch. This could be done by having a declarative ASCII description of these entities and/or wrapping the openNURBS library by a scripting language.
It comes from the need to convert NURBS-like entities from another program. The project, this was part of, ended however some years ago. Nevertheless, I would like to have it, in case I need it again.
This can be read as "The key-feature would be to have a ged command that lets you build NURBS objects from scratch. This could be done by having a declarative ASCII description of these entities." too
I can imagine two approaches, I think these are what we want to do.
For #1, we have implemented the first half of it.
So in general we need to create and modify geometry and topology of a brep using command line or interface. I hope I'm right.
Yes, I think what you've described is basically edit existing brep vs create brep from scratch. Both have strong use cases, and both are non-capabilities at the moment. Their need is far greater than higher level operations like lofting, fillets/bevels, reparameterization, etc.
Hi, I have made a draft of my proposal. Please review my proposal :smile: @Sean @Daniel Rossberg
https://drive.google.com/file/d/1NUOx-cnQrl5c9-W_k8_a8bqZ7xmJxEpW/view?usp=sharing
I think "brep editing" is a better name than "NURBS editing". Brep involves geometry and topology. NURBS is a part of geometry. What do you think?
while we call the entity "brep" and currently only store nurbs in them, boundary representation is a broad term and can refer to polygonal meshes, NURBS, sketches (but not extrudes), and a few others.
Yeah, 'brep' is too broad for the project.
I think some plot functions are needed to help users to select control vertex etc. Just like blender draw a control vertex mesh of NURBS surface.
image.png
I updated my proposal with few changes. https://drive.google.com/file/d/1o5IfQQSHajEZSZsXUkGBWlmw7JZtjbJO/view?usp=sharing
image.png image.png
I can move curves through cmd now. :grinning:
I wrote this function by imitating _brep_cmd_flip
. When we modify a brep object, we copy a new one ande delete the old object. I feel it's strange to do it this way. Won't this reduce efficiency?
@GregoryLi depends on the nature and size of the edit. a very large brep with lots of data will be inefficient, but whether that matters or is even noticeable by users remains to be seen. by doing the edit on a separate copy, that at least avoids a slew of validation code that'd be needed otherwise if/when an edit fails or cannot be applied.
worth noting that approach is also consistent with bot editing, which are typically as big or bigger than nurbs, with minimal impact.
@GregoryLi Congratulations on getting selected in GSoC 2023. Looking forward to work with you :tada:
Amanjot Singh said:
GregoryLi Congratulations on getting selected in GSoC 2023. Looking forward to work with you :tada:
thanks! I'm very excited to be selected :smile: I will check up the checklist :)
I'm trying to create an empty brep using command line, but I can't access ON_brep
in make.c
. I can only access _on_brep_placeholder
in include/brep/defines.h, a placeholder when compiling with a C compiler.
Now I add a brep_create
command. I can create an empty brep using "brep_create <brep_name>". But I think a subcommad of make like "make <brep_name> brep" is more suitable. Can you tell me what shall I do?
Did you had a look at libwdb? There is a brep.cpp with a mk_brep
function. The low level database object creation functions should go to libwdb.
Regarding the methodology used in make.c: Maybe, you can use the NMGs in libnmg as a kind of template. E.g., there is a function nmg_mm()
, which creates a new empty NMG. Can you do something similar in libbrep?
GregoryLi said:
I'm trying to create an empty brep using command line, but I can't access
ON_brep
inmake.c
. I can only access_on_brep_placeholder
in include/brep/defines.h, a placeholder when compiling with a C compiler.
ON_brep is a C++ class, so any code that accesses, creates, inspects, or otherwise uses one needs to be from within a C++ source file. For C files, it resolves to a pointer placeholder that you can't do anything with.
Basically, add a new c++ file, and access code through C functions if you need to bridge to an existing C file like make.c
I'm using mk_brep
in my 'brep_create` command. I hope to call 'brep_create' command in 'make.c' using 'ged_exec()'. 'brep_create' command run but error occurs. I have checked and verified that all the parameters in 'brep_create' are correct.
Log info:
rt_db_cvt_to_external5(A_b): ft_export5 failure
rt_db_put_internal5(A_b): export failure
Sean said:
Basically, add a new c++ file, and access code through C functions if you need to bridge to an existing C file like make.c
I'll try to make a bridge to call mk_brep
function. Thanks!
I tried two methods to call mk_brep
, but both had problems.
brep_create [brep_name]
and it works well. Then I add a subcommand in make
like make [brep_name] brep
to call brep_create
command using ged_exec()
.make [brep_name] brep
, I get this error message: Error: Database write failure
. But if I add or delete any other object, the brep object occurs, which means it's created but didn't display.make [brep_name] brep
are the same.mk_brep()
directly in make
. The problem that appeared is exactly the same.@Sean @Daniel Rossberg @Amanjot Singh Where do you think the problem lies? Could it be due to the addition of locks or something similar in the make
command?
Can you show us your code? Do you have a github account?
Yes, it's quite simple. https://github.com/GregoryLi0/brlcad/commit/97dfd3b85f1dc68a23627fdcc4ae22c67b0db7ab
For comparison, brep_craete
command is here. https://github.com/BRL-CAD/brlcad/commit/4ac8818438ac0f3fbb2f830a22d89fc71ebfc093
@GregoryLi What's getting written to disk is &internal, which you don't set/initialize
It's also strange to me that you'd call wdb_dbopen().. I see that hyp is also calling that, but I think that's "a mistake" of sorts -- someone was being lazy and I think creating a memory issue (they don't call close).
You'll want to initialize the &internal like the other primitives. The only complication you have is that you need the pointer to the brep. I don't think you want to call mk_brep(). Probably better to make a function that returns a void* to the brep -- can make mk_brep() call that as well as in ged_make_core().
Sean said:
You'll want to initialize the &internal like the other primitives. The only complication you have is that you need the pointer to the brep. I don't think you want to call mk_brep(). Probably better to make a function that returns a void* to the brep -- can make mk_brep() call that as well as in ged_make_core().
It works! Thanks :smiley:
Now, I am able to create an empty BREP object and generate new curves within it. However, it should be noted that only a limited number of parameters can be configured now.
I think users can input simple information such as the dimensions and degree of the curve using "brep [name] create_curve [curve_info]", while the specific information on controlling point positions could be set by other commands. You think it's a good idea?
Well, I have researched some alternative libraries... NURBS-Python, blender-python requires lots of codes to create a curve.
The Python script for creating nurbs curves in Blender is more concise.
image.png
Btw, is there a plugin in VScode that can automatically format our code? The auto-formatting tool in VScode tends to mass up the existing code.
@Daniel Rossberg Hi, I updated codes about make [name] brep
. I created function brep_create_empty_brep()
in libbrep to create rt_brep_internal
.
It seems to be running well.
Nice :smile:
Some comments regarding your code:
brep_create_empty_brep()
is an unusual long function name, for what it does. How aboutbrep_create()
for constructing a new rt_brep_internal?brep_add_~
, brep_insert_~
for adding new curves, etc.?brep_remove_~
for deleting features?I'm getting a compilation warning/error:
/home/rossberg/Devel/BRL-CAD/brlcad.GregoryLi0/src/libged/make/make.c:75:27: error: unused variable ‘brep_ip’ [-Werror=unused-variable]
75 | struct rt_brep_internal *brep_ip;
| ^~~~~~~
cc1: all warnings being treated as errors
Thanks! I will shorten the names of these functions and fix the error.
And now I think brep_create()
in libbrep should create an ON_Brep
instead of rt_brep_internal
like other primitives in make.c
.
Does rt means ray tracing? I tracked boolean
subcommand of brep
, the function call stack is libged/_brep_cmd_boolean()
→ librt/rt_brep_boolean()
→ libbrep/ON_Boolean()
. I'm not sure why we shall go through librt..
@Daniel Rossberg I think the brep editing operations shall be implemented in libbrep
, and we can access them directly in libged
?
GregoryLi said:
Does rt means ray tracing? I tracked
boolean
subcommand ofbrep
, the function call stack islibged/_brep_cmd_boolean()
→librt/rt_brep_boolean()
→libbrep/ON_Boolean()
. I'm not sure why we shall go through librt..
rt stands for "ray-trace", and it is the prefix of librt's symbols. The point is that both the librt ray-tracing as well as the libged brep bool sub-command need the functionality in rt_brep_boolean(). See the comment for the include of this function in src/libged/brep/brep.c: librt may not be the final place/rt_brep_boolean not the final name of this function.
However, editing the breps (NURBS) is not directly connected with ray-tracing, and the low level code should go to libbrep
, where it can be accessed from libged
.
Yeah, thanks. Now the development is going well, slightly ahead of schedule.
@Daniel Rossberg Hi, I have just submitted the PR for Milestone 1 as schedule. (https://github.com/BRL-CAD/brlcad/pull/80). Let me know if you have any feedback, suggestions, or questions :)
Actually, some of the tasks for Milestone 2 have already been completed. I'm planning to conduct further research and define the required function functionalities.
Do you have some examples and/or advice about how to test the new features?
I will write a shell script to test them, as well as change my code styles.
brep_curve_edit.sh
brep_surface_edit.sh
I made two shell scripts to perfrom curves & surfaces operations. You can also execute these commands step by step and monitor the changes in data using the "brep .. info" command. @Daniel Rossberg
@GregoryLi, please, consider my comment on https://github.com/BRL-CAD/brlcad/pull/80 too.
I see :smile:
Screenshot.png
Yes, I'm checking and modifying my codes.
Thanks, I saw your modifications. I may need however some days to review them...
That's alright :) I'm now implementing local cubic curve interpolation, to support functions like InterpCrv in Rhino.
@GregoryLi can you show me an example for making a brep cone?
(deleted)
Sean said:
GregoryLi can you show me an example for making a brep cone?
I'm currently unable to create a brep cone using the mged command. While NURBS curve/surface editing operations are now supported, topology operations are not yet supported. I can make it by cpp code.
The topology modification function belongs to milestone3(July 25 - August 21) in the schedule. But the current progress is about one week ahead of schedule,I plan to handle topology operations after writing the NURBS editing operation documentation.
And I am also considering and looking at other software about brep operations. I think it is inappropriate to wrap all NURBS operations into mged command lines for users. Maybe the topology operations shall be implicitly included in. For example:
If we want to make a cylinder by a circle and a line. We can run 'extrude' cmd. Topology operations are implicitly included in.
Hi, I was one week away to join a meeting :) The current project schedule and timeline are aligned. I'm going to submit PR of Milestone 2 this weekend. PR 2 includes advanced NURBS geometry operations: curve/surface interpolation, create surface by tensor product and rotating a curve.
There are still some issues with the last feature Surface interpolation. I want to achieve higher continuity with fewer control points following The NURBS Book. This is quite different with the already realized local curve interpolation. I do apologize for being confused by the complexity of the math formula. :face_with_spiral_eyes:
I should need another two or three days to implement it and prepare PR2.
This can happen that problems turn out to be harder than expected. And, NURBS have some heavy math. Therefore, thanks for letting us know. I'm optimistic that you will overcome the difficulties. A few day more doesn't matter there.
Hi, I just submit PR of milestone 2 :). https://github.com/BRL-CAD/brlcad/pull/92
There are some potential threats to the ''remove'' operation now as my comment in github PR.
brep_curve_edit.sh
brep_surface_edit.sh
Here are two shell script to test new features of milestone 2.
Hi Daniel, I'm working on the issues you pointed out. But I didn't have the environment to compile the code until the day after tomorrow. Sorry about that :(
GregoryLi said:
The topology modification function belongs to milestone3(July 25 - August 21) in the schedule. But the current progress is about one week ahead of schedule,I plan to handle topology operations after writing the NURBS editing operation documentation.
How's the topology operations coming along? :)
@Sean I've been working with Daniel on the PR2 merge recently. It's about a week or two behind schedule.
Regarding the topology operations, I was able to and plan to simply wrap topology operations into command line operations, although these commands will look very weird and require a lot of parameters.
I had previously planned to make the topology operations implicit in the higher order operations. For example, having a line rotate around an axis while encapsulating the top and bottom sides and establishing topological relationships. But these operations are not very popular. So I am wrapping the basic topological operations in the command line.
Yeah, I don't think you should focus on anything higher order, without something low-level in place first. I mean a really basic goal should be creating a sphere from one surface and/or creating a tetra, box, or sphere from multiple surfaces.
Doesn't matter if it's verbose or not. I think the subcommand structure you have is probably halfway there already. For example, could be something like this:
brep mycube create
brep mycube create_surface -name bottom -u 1 -v 1 -control_points "0,0,0 1,0,0 0,1,0 1,1,0" -weights "1 1 1 1" -knots_u "0 1" -knots_v "0 1"
brep mycube create_surface -name top -u 1 -v 1 -control_points "0,0,1 1,0,1 0,1,1 1,1,1" -weights "1 1 1 1" -knots_u "0 1" -knots_v "0 1"
brep mycube create_surface -name left -u 1 -v 1 -control_points "0,0,0 0,0,1 0,1,0 0,1,1" -weights "1 1 1 1" -knots_u "0 1" -knots_v "0 1"
brep mycube create_surface -name right -u 1 -v 1 -control_points "1,0,0 1,0,1 1,1,0 1,1,1" -weights "1 1 1 1" -knots_u "0 1" -knots_v "0 1"
brep mycube create_surface -name front -u 1 -v 1 -control_points "0,0,0 1,0,0 0,0,1 1,0,1" -weights "1 1 1 1" -knots_u "0 1" -knots_v "0 1"
brep mycube create_surface -name back -u 1 -v 1 -control_points "0,1,0 1,1,0 0,1,1 1,1,1" -weights "1 1 1 1" -knots_u "0 1" -knots_v "0 1"
# some command that figures out topology automatically
brep mycube sew_surfaces -surfaces "bottom,top,left,right,front,back"
Or a diff entirely manual approach with indices:
brep mycube add_point 0 0 0 # Point 0
brep mycube add_point 1 0 0 # Point 1
brep mycube add_point 0 1 0 # Point 2
brep mycube add_point 1 1 0 # Point 3
brep mycube add_point 0 0 1 # Point 4
brep mycube add_point 1 0 1 # Point 5
brep mycube add_point 0 1 1 # Point 6
brep mycube add_point 1 1 1 # Point 7
brep mycube create_edge 0 1 # Edge 0
brep mycube create_edge 2 3 # Edge 1
brep mycube create_edge 4 5 # Edge 2
brep mycube create_edge 6 7 # Edge 3
...
brep mycube create_surface -u 1 -v 1 -points "0,1,2,3" # Surface 0
brep mycube create_surface -u 1 -v 1 -points "4,5,6,7" # Surface 1
brep mycube create_surface -u 1 -v 1 -points "0,4,2,6" # Surface 2
brep mycube create_surface -u 1 -v 1 -points "1,5,3,7" # Surface 3
brep mycube create_surface -u 1 -v 1 -points "0,4,1,5" # Surface 4
brep mycube create_surface -u 1 -v 1 -points "2,6,3,7" # Surface 5
brep mycube create_face -surface 0 -edges "0,1,2,3" # Face 0
brep mycube create_face -surface 1 -edges "0,1,2,3" # Face 1
brep mycube create_face -surface 2 -edges "0,1,2,3" # Face 2
brep mycube create_face -surface 3 -edges "0,1,2,3" # Face 3
brep mycube create_face -surface 4 -edges "0,1,2,3" # Face 4
brep mycube create_face -surface 5 -edges "0,1,2,3" # Face 5
brep mycube assemble -faces "0,1,2,3,4,5"
Yeah, I can create a geometry face and indicates its topology info using mged commands just now. Although the topology commands seems not easy to use. For example, you have to type in edge ids and if they shall be flipped or not.
I plan to implement geometrical and topological representation for the polyhedron within a week. And I need to rearrange the geometry and topology editing operations.
image.png
image.png
Hi, I'm able to create valid brep object though mged commands with shell scripts, and I rearranged brep editing operations into geometry and topology two parts.
I'm preparing for my final submission and list possible problems and areas that need to be developed. I expect to be able to continue to contribute to this module :)
Hi, I just committed my PR of milestone 3. (https://github.com/BRL-CAD/brlcad/pull/97)
seven_eighths_cube.sh
triangular_prism.sh
These are the shell scripts that reproduce the above test cases.
:+1: I'll have a look at it :smile:
After creating faces with brep brep_t topo f_create
I'm getting
face 0 is not valid, skippingface 1 is not valid, skippingface 2 is not valid, skippingface 3 is not valid, skippingface 4 is not valid, skipping
with brep brep_t plot F
. Is this expected?
A face is invalid if it does not have a valid loop. So this is expected.
@GregoryLi so why are the loops not valid? the count of them appears to be correct. are they not going in the right directions?
Did you get the logs running the shell scripts?
A loop is valid if the edges of the loop are connected to form a circle.
That means, if we want to get a valid face, we need to:
After creating faces with
brep brep_t topo f_create
I'm gettingface 0 is not valid, skippingface 1 is not valid, skippingface 2 is not valid, skippingface 3 is not valid, skippingface 4 is not valid, skipping
with
brep brep_t plot F
. Is this expected?
I think that this operation is only up to step 5, it hasn't created a VALID loop on the face yet
Hi @GregoryLi, please add links to your pull requests to https://brlcad.org/wiki/User:GregoryLi/GSoC2023/DevLog. Otherwise, I cannot confirm that the link points to your work.
Thanks! I have attached PR links to the DevLog, and wrote a final report here. I will continue to refine the future expectations of brep operations.
Hi @Daniel Rossberg @Sean, thank you very much for your guidance! I have received the Final Evaluation. I will keep contributing to BRL-CAD :grinning:
My next step is NURBS editing using surface-surface intersection. For brep entities with NURBS surfaces, manually inputting all the geometric and topologic objects is quite hard. Getting those objects through surface-surface-intersection will help a lot.
The ability to create and modify NURBS makes BRL-CAD much more powerful. Therefore, thank you Gregory :smiley:
Hi, I created lots of test shell scripts for NURBS editing. I think they can be used over time. Do you think they should be uploaded? What directory do you think they should be uploaded to? @Daniel Rossberg @Sean
By the way, I'm adding the Surface-Surface intersection function to the NURBS editing module.
GregoryLi said:
Hi, I created lots of test shell scripts for NURBS editing. I think they can be used over time. Do you think they should be uploaded? What directory do you think they should be uploaded to? Daniel Rossberg Sean
They should definitely be saved somewhere. What came into my mind is src/libbrep/tests/tcl
. If the scripts are a good how-to for NURBS editing, https://brlcad.org/wiki/NURBS would be possible too.
I found “brep .. intersect .. SS” crashes. the dplot
object is nullptr while running. If you want to reproduce the problem, you can simply run:
make b brep
brep b geo c3_create
brep b geo c3_in 0 3 3 0 1 0 1 0 0 2 1 0
brep b geo c3_in 0 3 3 1 1 -1 1 1.5 0 1 1 1
brep b geo s_tensor 0 1
brep b geo s_tensor 2 1
brep b intersect b 0 1 SS
I solved it here: https://github.com/GregoryLi0/brlcad/commit/6705abd669be63adfddbeb61f9d32980b7f929de
image.png
Last updated: Jan 09 2025 at 00:46 UTC