Are we participating this year too? All seems busy here?
(deleted)
(deleted)
(deleted)
I’ve been crazy busy since the new year for me which is why I’ve been away of late but finally getting caught up.
I did apply for BRL-CAD in anticipation. We need unto update our project ideas list, check on mentor interests, and touch base with the other orgs to see whom all is participating.
@Sean Just updated the year in the issues list. https://github.com/opencax/opencax.github.io/pull/5
That's great, thank you @Himanshu Sekhar Nayak ! There's a bit more work to do as FreeCAD is not participating under our umbrella this year, so some updates will need to be made to pull a couple of their org sponsorships.
We also need to update our ideas list, identify interested mentors, close out the completed project ideas, and consolidate on new/continuation priority projects. Love to see more progress on the GUI/API, physically-based rendering, robust export, and performance.
I would love to develop again on GUI and try to add or fix feature. But love to see if any other will continue this project this year.
@Himanshu Sekhar Nayak, I could imagine you being a mentor this year.
Currently I am learning ray tracing and implemented it too. Ray traced a Cornell box and wow :ok: my interest grows more towards game graphics and how the game developers able to implement that. Today, I rendered a sphere using ray marching through the help of SDF and it looks cool. The more I getting to know these, the more it looks interesting.
Saw 2 projects regarding these. I hope I can contribute these too in future.
Daniel Rossberg said:
Himanshu Sekhar Nayak, I could imagine you being a mentor this year.
Mentor :sweat_smile:. I am no good enough I think. But whatever I learned from this organization, yes I can help someone to start only.
@Himanshu Sekhar Nayak you’ve participated twice now yes? If so then you’d definitely make a great mentor..
You could also do great things on a graphics project, especially if you’re getting into ray tracing
Sean said:
Himanshu Sekhar Nayak you’ve participated twice now yes? If so then you’d definitely make a great mentor..
Twice yes, one gci and second one gsoc.
Himanshu Sekhar Nayak said:
Daniel Rossberg said:
Himanshu Sekhar Nayak, I could imagine you being a mentor this year.
Mentor :sweat_smile:. I am no good enough I think. But whatever I learned from this organization, yes I can help someone to start only.
You are member of our community since many years and have seen many parts of the BRL-CAD suite during this time. Not only that you can guide newbies during their first steps, you followed the developer discussions too and got an idea in which directions the development shall go.
In addition, you will obtain new skills when mentoring. This is not a one-way street. Looking at and understanding other peoples patches will broaden your horizon as well.
And last but not least: You won't mentor alone but together with an experienced developer. We aim for two mentors per project in general.
Okay, I am in. :sunglasses:
Hi, I noticed we have NURBS editing topic this year, I'm interested in it! I've been working on splines for a few months now, including NURBS intersection, Spline knot subdivision and insert, bounding box, symbolic computation & numerical computation. My doctoral topics in the next few years will also be related research directions. I'm using SISL NURBS lib. I have a lot of experience with NURBS algorithm implementation, but I'm not so familar with GUI development which is also important. Is it possible to join twice? I would love to attend with or without GSOC :grinning: because I'm interested in concrete industrial implementations of NURBS. I would like to know about and implement newer algorithms in industry softwares.
@GregoryLi Unfortunately, SISL NURBS isn't license compatible with BRL-CAD :-( My suggestion, if you feel comfortable working with it, would be to keep digging into our boolean evaluation logic for NURBS. That capability, if we can make it production ready, is a potential game changer for our export capabilities and a number of other very interesting features.
Another effort in a similar vein is continuing to improve our polygonalization codes for NURBS - we use a variation on the poly2tri code in combination with a variety of custom logic, but our watertight meshing capabilities need work both for speed and robustness (See https://apps.dtic.mil/sti/pdfs/AD1094344.pdf)
You'd have to talk to one of the others about what's allowed/not allowed for GSOC - I'm not acting as a mentor this go-around...
This years GSoC rules allow to join twice.
To understand, what the "NURBS Editing Support in BRL-CAD" project idea means, you should go through the mged tutorial. Then, the task would be to create and modify NURBS objects the same way :wink:
BRL-CAD uses the openNURBS library.
starseeker @Daniel Rossberg
Thanks! I will use openNURBS within BRL-CAD. I will check what has ben implemented in BRL-CAD & openNURBS and what is needed for NURBS.
I think the "NURBS Editing Support in BRL-CAD" project needs mged development much more than NURBS algorithm implement(because openNURBS has done this). Am I right?
The right answer is probably yes, even if you don't have to touch the mged code yet. This is because it is only one of many programs build on top of the core libraries. These are the ones you have to work extend. Maybe libbrep and libged? Ideally, you don't have to change the openNURBS library.
The first step would be to get access to the data structures. The openNURBS library has probably an API for this, but it isn't used on the BRL-CAD side yet. Then, a kind of ASCII serialization would be nice. Having this, you could implement a function in libged, which creates a NURBS from such a string. And so on...
Agreed, you definitely will have to use openNURBS and would likely end up adding command-line editing capabilities in libged and/or librt first, then if there's time you'd be figuring out how to expose editing through a GUI. Solid polygonal export of NURBS is definitely also needed. There is/was code that supposedly guarantees they're solid, but it's not been tested, is slower, and I believe is presently #ifdef'd out so it's not even compiled.
I checked NURBS Editing Support and NURBS curve editing operations in openNURBS and bound NURBS curve operations and openNURBS functions. I found some operations needs to be implemented in BRL-CAD, too.
image.png
I don't fully understand the specific meaning of some operations so I marked "?", we can discuss these specific issues after discussing the whole process :)
Here is a brief work sequence for NURBS editing project. Is my understanding of this project too broad, too narrow or biased?
I see there are a lot of interesting work to do in BRL-CAD, which is familiar and interesting to me...
Number 4. could be a problem, because openNURBS is another project, and maintaining a fork is challenging. Hopefully, it isn't necessary.
Hi @Mohamed Adel, Welcome to our community. To start, you may look at
Daniel Rossberg said:
Number 4. could be a problem, because openNURBS is another project, and maintaining a fork is challenging. Hopefully, it isn't necessary.
Yeah, maybe we can implement those functions in libbrep/libged?
For example, NURBS curve Attach
operation doesn't exists in openNURBS, we can implement it in libged based on openNURBS.
Just as " or identifying that the equivalent routine doesn't exist in openNURBS and will need to be implemented" here NURBS Editing Support
@GregoryLi functions that opennurbs has in headers but doesn't have the implementation for are typically implemented in libbrep. Note that those are typically functions that are harder to implement too. The opennurbs folks remove the hard bits that don't have anything to do with the 3dm file format in order to encourage people to buy their rhinosdk licensing which costs, is not open source.
There's actually a project starseeker started some 10+ years ago to address that very issue that is worth studying (called libnurbs). Looks like someone pulled it over to github: https://github.com/yiskang/libnurbs
Other references worth checking out: https://www.google.com/search?q=nurbs+editing+site%3Agithub.com&ie=UTF-8&oe=UTF-8#ip=1
Hii , myself Neeraj Sharma I build the BRLCAD. now I want to go further .
Follow rest? #Google Summer of Code > general @Neeraj Sharma
@GregoryLi the libnurbs "project" never came to anything much, mostly due to lack of time... when it comes to the notion of "forking" openNURBS, I agree in principle that it's usually undesirable to do that due to the amount of work involved. We've not been compelled to thus far. That said, my sense is that the core parts of openNURBS we need for what we're focused on (opennurbs_brep.h and its friends) haven't changed enormously over the decades.
If we were to think about a "libnurbs" style project, I'd probably look at identifying a "minimal functional core" of openNURBS needed for BRep NURBS solids and related data types. My hunch is that the core code there hasn't undergone extensive modification for a long time, and even if it would be challenging to try to keep up with the changes for ALL of openNURBS it might be much more practical to identify the changes for that core. If for a "libnurbs" we stripped out subdivision, I/O, layers, visualization, mesh, etc. and narrowed it just to the ON_Brep related parts, and then checked to see how stable that code has been in the upstream repository, it would give us some idea of how hard that might be.
We would still use openNURBS proper for 3dm import and export (which after all is what it's intended for) and build more advanced NURBS BRep capabilities on top of the smaller "libnurbs" core, making minimal modifications to the "original" openNURBS files (for example, replacing stubs with real implementations) and defining all-new functionality (for example, a proper ASCII serialization of the ON_Brep containers to replace our current b64 hack used by asc2g) in our own files. Then with any luck we could merge upstream changes to just the files in question fairly easily, without having to worry about new code they introduce.
Although that articulates the idea behind libnurbs, I should point out I'm not actually advocating for that approach - it still has some potentially significant upfront costs even if the stability of the relevant portions of the openNURBS code holds, and it should be possible to do most of the substantive work we need in libbrep.
Sean said:
GregoryLi functions that opennurbs has in headers but doesn't have the implementation for are typically implemented in libbrep. Note that those are typically functions that are harder to implement too. The opennurbs folks remove the hard bits that don't have anything to do with the 3dm file format in order to encourage people to buy their rhinosdk licensing which costs, is not open source.
There's actually a project starseeker started some 10+ years ago to address that very issue that is worth studying (called libnurbs). Looks like someone pulled it over to github: https://github.com/yiskang/libnurbs
Other references worth checking out: https://www.google.com/search?q=nurbs+editing+site%3Agithub.com&ie=UTF-8&oe=UTF-8#ip=1
@starseeker libnurbs is really great work! starseeker pointed out a feasible method to build a "libnurbs" like project. But as you said, it time consuming with little payoff. So I think focus on NURBS editing support for BRL-CAD is OK. So Achieving other NURBS operations is the icing on the cake...
I will see how to call NURBS editing operation though cmd. This is something I'm not familiar with. :smile:
@GregoryLi a potential starting point that might help would be to look at the opennurbs examples in src/proc-db which are in C++ and construct basic shapes manually like a cube. imagine having a CLI in mged where you could create the twisted cube example, or take an existing twisted cube and move an existing control point, or adjust a knot, or move an edge , or move a surface, or clamp all the control points precisely to their parametric domain counterparts, etc
Congratulations @GregoryLi, @Caio José Dos Santos Brito and @Abhiram. We are as excited as you. I as member of BRL-CAD community, welcomes you all and can't wait to start working on projects.
It is sad that this year, we didn't get more slots than previous year but not to worry @Nishanth, you can still contribute, learn and can gain experience here. I know how it feels to not get pass through even if we are dedicating for something. I hope you will stay and contribute. This will broaden your horizon as well.
Thank you for the opportunity!!! I am very excited and it will be fun for sure! =)
Congratulations and thank you to all that applied. Alas, we won't get to all the applicants we wanted to work with, but encourage all to get involved and apply again next year (especially if this was your first time applying). Open source thrives on communication, so being active and involved is one of the best ways to learn, get noticed, and get selected.
That said, for @GregoryLi @Caio José Dos Santos Brito and @Abhiram please do check up the checklist for what steps are next: https://opencax.github.io/gsoc_checklist.html
GSoC 2023 page site is now created and now you will able to maintain your project related information here https://brlcad.org/wiki/Google_Summer_of_Code/2023. You can look into other project info which are selected previously https://brlcad.org/wiki/Google_Summer_of_Code/2022 otherwise there is a template added to 2023 page. Whatever you like pick it.
Himanshu Sekhar Nayak said:
GSoC 2023 page site is now created and now you will able to maintain your project related information here https://brlcad.org/wiki/Google_Summer_of_Code/2023. You can look into other project info which are selected previously https://brlcad.org/wiki/Google_Summer_of_Code/2022 otherwise there is a template added to 2023 page. Whatever you like pick it.
Okay will do!
Hi @Sean , can we have a meeting over the weekend or whenever you are free in the coming days so that we can both plan and discuss the updated deliverables (changes to boost etc, which I haven't really emphasized on in the proposal) and any other things you'd like me to do?
Last updated: Nov 15 2024 at 00:49 UTC