pca006132 (Jan 13 2024 at 17:12): pca006132 (Jan 13 2024 at 17:12):Hi, we from the manifold project wants to join GSoC (opencax). Is there a list of requirements in addition to submitting a project list, and formal procedure for joining?
pca006132 (Jan 13 2024 at 17:14):we currently have 3 devs willing to be mentor, and are thinking about projects
pca006132 (Jan 13 2024 at 17:26):https://github.com/elalish/manifold/discussions/697
Daniel Rossberg (Jan 18 2024 at 07:58):Hi @pca006132, thanks for your interest. I think that it should be possible to let you join OpenCAx (probably still called BRL-CAD in the GSoC organisations list) for GSoC. However, the owner of OpenCAx is @Sean.
pca006132 (Jan 18 2024 at 10:19):Thanks
starseeker (Jan 18 2024 at 14:23):@pca006132 he's a little busy right now, but he's aware of your interest and I'm sure he'll respond - I agree with @Daniel Rossberg , it sounds like a good fit.
starseeker (Jan 18 2024 at 14:26):@pca006132 I was interested to see your suggestion for an optimized quickhull. @Alexis Naveros took a look at that QuickHull implementation and was a little concerned: https://brlcad.zulipchat.com/#narrow/stream/104062-general/topic/mesh.20reconstruction/near/406682309
Torsten Paul (Jan 18 2024 at 15:09):If we have the general thumbs up, I can get @pca006132 setup on the github OpenCAx website. I suppose it may need a bit of a general makeover too acknowledging the program changes of last and this year.
pca006132 (Jan 18 2024 at 16:27):@starseeker Yeah I am a bit concerned about that as well, but I don't have much idea about their underlying algorithm, will need some time to check. I was thinking about using things like parallelization, as these are easier for me. I think for point removal, it should be safe within their epsilon which is expected to be small, but again this is just guessing, need to look at it for details.
Sean (Jan 18 2024 at 19:44):@pca006132 sorry for the slow reply but I agree with what everyone else here is saying -- definitely sounds like a good fit and thank you for reaching out.
Sean (Jan 18 2024 at 19:47):there is a bit to discuss to make sure we're all on the same page and so you know how the program works. there are some details like partner-org and mentoring expectations, selecting contributors, failing contributors, slots, stipends, mentor summit, conflict resolution, and probably other questions.
Sean (Jan 18 2024 at 19:50):might be best to schedule a synchronous meeting to discuss if there are lots of questions, or can sort things out async and I can summarize each of the more important points that come to mind.
in terms of getting set up, all that's required will be you defining 1-3 project ideas, getting you set up on our opencax github project (thanks for the offer @Torsten Paul! using issue tracker for our ideas is something to discuss... I'll start a thread), and getting you and your mentors set up on our mailing list.
pca006132 (Jan 18 2024 at 23:22):@Sean Thanks. We only have basic idea about mentoring expectation but not much else. It would be nice if you can give a summary for these details asycn, and decide if we need a synchronous meeting after that.
pca006132 (Jan 18 2024 at 23:23):btw where is the mailing list for this?
Emmett Lalish (Jan 19 2024 at 00:58):Thanks! I haven't done GSoC before, but I am a Google employee, so I have no excuse if I'm misinformed. They can't pay me a stipend, but I'm hoping they can pay other mentors of manifold. I've hosted interns, so I'm not too worried about defining projects and mentoring students.
Emmett Lalish (Jan 19 2024 at 00:59):I don't have too many questions, but you may know better than I the useful pieces of info. How do we collaborate with you? I take it all of these projects come together in a single submission somehow?
Johnathon (zalo) Selstad (Jan 19 2024 at 22:57):I believe the VHACD library switched from QuickHull to Julio Jerez (of Newton Physics)'s Convex Hull algorithm because it's much faster and more numerically stable:
https://github.com/kmammou/v-hacd/blob/master/include/VHACD.h#L1988-L3489
Perhaps this can be repurposed as well?
(EDIT: Ah, did I mess up the thread? I'm still new to this interface...)
Emmett Lalish (Jan 20 2024 at 02:33):It's all good - I think this thread is more for logistics - let's keep manifold project ideas over at https://github.com/elalish/manifold/discussions/697
Sean (Jan 22 2024 at 17:39):pca006132 said:
btw where is the mailing list for this?
It's a private "gsocax" google group. If everything lines up with your expectations, I can send the link to join. That's usually where time-sensitive inquiries are sent out just because we're all on different communication infrastructure.
Sean (Jan 22 2024 at 17:48):Emmett Lalish said:
Thanks! I haven't done GSoC before, but I am a Google employee, so I have no excuse if I'm misinformed. They can't pay me a stipend, but I'm hoping they can pay other mentors of manifold. I've hosted interns, so I'm not too worried about defining projects and mentoring students.
Hi @Emmett Lalish and welcome! Always happy when Google employees get involved in GSoC. It's a truly great program.. Stephanie is amazing.
As for the stipend, our org has not (ever) sent the stipend to mentors. The legal and tax implications sending money is incredibly complicated (even domestically, but especially internationally -- it took 4 months and over a hundred hrs effort to send money to an EU contributor a couple years ago). I started a non-profit to help address that with suborgs, but that is even more time-consuming and not fully established for sending internationally.
What we have done in the past is allocated funds for sending additional mentors to the mentor summit. Anything left over (rare) typically goes towards swag (e.g., stickers), paying for conference attendance, buy mentors books, or offsetting our open source server hosting.
Sean (Jan 22 2024 at 17:58):Emmett Lalish said:
I don't have too many questions, but you may know better than I the useful pieces of info. How do we collaborate with you? I take it all of these projects come together in a single submission somehow?
This will be our 16th year BRL-CAD is participating., and our 10th year as an "umbrella org", working with CAx-related partners. We put together a single submission that says who we are, how we operate, and the groups we're working with and/or incubating as an umbrella.
General idea is we're really good at managing overall participation, student/contributor management, enforcing rules and guidelines that make for successful participation, and more. It's a formula that has worked pretty well over the years. Goal is introducing contributors to open source community, aiming to identify those more likely to stick around, and striving to foster desperately needed broader CAx-community collaboration.
Emmett Lalish (Jan 23 2024 at 02:40):This sounds great, would love an invite to the gsocax group. No mentor stipends certainly simplifies things - works for me! What is the mentor summit? @pca006132 has already been adding issues to your Github for Manifold project ideas. Anything else we can do to help?
Sean (Jan 23 2024 at 17:46):pca006132 said:
Sean Thanks. We only have basic idea about mentoring expectation but not much else. It would be nice if you can give a summary for these details asycn, and decide if we need a synchronous meeting after that.
@pca006132 Apologies in advance on the length... there's a lot to cover! The general expectations to be aware of definitely vary from project-org to project-org.
Regarding projects: In general, you will have autonomy on projects you propose and mentor, though projects that enable or benefit multiple code bases are encouraged. You'll need to make sure your ideas have very clear, general-population-friendly titles -- detail and domain-specific terminology can go in the description. Projects need to have a mentor designated (more on that below).
Proposals: What's not entirely in your control is what proposals are received as they need to be high quality. You are encouraged to solicit proposals through any means available (e.g., invite local universities or interest groups). Proposals with little effort invested invariably result in poor experiences. That is to say, if you get a proposal for topic X and even if that's your only proposal received, if it's not a "great" write-up (i.e., the person half-assed the submission) or if the person never joins chat or other red flags, it would get disqualified. That's to say there is an overarching quality metric that all proposals need to satisfy before they are valid for ranking consideration. We typically get 4-12 slots and the goal is accepting at least one per partner, but it does depend on the number of proposals received, how many we got last year, and Google's funding level.
New Org: As a new org, you're not allowed to have more than two slots, default may be just one depending on the quality and variety of proposals received -- that's a Google rule that we must also enforce.
Mentor summit: Veteran mentors that have not been recently typically get priority for the summit but it depends on availability, and if we can get additional mentors approved. We typically get 1-3 delegates (all expenses are paid by Google and our org).
Stipends: We don't give stipends to individual mentors. We've discussed directing funds to partner org organizations/foundations, but even that is proving to be complex form a tax code perspective. We can discuss more if needed, but typically it's asked that orgs just let the funds go towards overhead expenses like summit travel, books, stickers, servers, etc. I would love help if anyone is interested in getting our non-profit more organized and structured (e.g., how to incroporate membership and decision-making) since that's really what is needed at this point to enable fundraising/fundspending without so much complexity.
Mentors: There's a lot of great information on Google's sight on what is expected of mentors, so they should all definitely read that information. I helped write them, and there's even a couple videos with yours truly. The general guideline we impose is that mentors should have (on average) about 10 hours a week available for mentoring. That will be potentially more during evaluations, but more is better as that results in engagement and contributors that stick around.
Probation and Failure: I do ask that all participants maintain a public dev log that is watched to ensure consistency of experience and equity across all participants. If a participant doesn't appear to be working, there is a probationary process where the admin (myself or Daniel) may step in and take over mentoring, to impose additional requirements prior to failing them, or to help reassign mentoring if there is an interpersonal situation. Super rare for us, but it happens.
Communications: Work is expected to be completed fully in the open somewhere (including discussions), e.g., IRC, Zulip, Discord, etc. You can also have face-to-face / video meetings, or can be entirely online -- just not via private e-mail.
That's all I can think off the top of my head.... any questions? Anything I missed?
pca006132 (Jan 23 2024 at 18:06):@Sean thanks, this is very clear
Emmett Lalish (Jan 26 2024 at 05:31):Okay, so we the mentors of an org (Manifold) write up 3-5 projects with mentors assigned, then hope students will submit proposals to work on those projects, and of those proposals we hope to accept 1-2 based on quality of the student writeup? If I got all that right, then I think that's all clear. Thanks!
starseeker (Jul 10 2024 at 00:43):@Emmett Lalish I had a question about how manifold is structured... I'm thinking I probably just missed some earlier design discussion, and if so apologies, but what's the motivation for having the various individual libraries rather than a single libmanifold which can be compiled with or without various functionality? I get the bindings being managed separately, but are there users who look to only use a subset of the core C++ functionality and need a really minimalist footprint?
starseeker (Jul 10 2024 at 00:49):I'm mostly asking out of laziness - currently for our bext repo I've got a somewhat modded Manifold build that produces a single manifold lib, so our FindMANIFOLD.cmake file can go hunting just for a single library. This is pretty much left over from the early testing setup I put together, and I really should make it so we can use a vanilla Manifold build/install, but before I add logic to go hunting for things like meshIO I thought I might as well ask if producing a single libmanifold with the core logic and optional assimp-based I/O might be an option?
starseeker (Jul 10 2024 at 00:56):Or perhaps I should be using the "new" find_package style and relying on a manifoldConfig.cmake file? (Still feeling my way around how that works, to be honest...)
pca006132 (Jul 10 2024 at 15:54):I think you can have a look at how openscad does that: https://github.com/openscad/openscad/blob/master/CMakeLists.txt#L953-L960
pca006132 (Jul 10 2024 at 15:56):We have some (potential) users that are very picky about their dependencies... and we want to allow them to only include the essential part of the library, so we made it modular.
Using compile-time options will make it harder for distros to include our package, as different libraries may want different configuration but the distro can only provide one
starseeker (Jul 10 2024 at 20:29):If I'm seeing that right, they're adding the manifold build as a subdirectory into their own build - unfortunately that won't work for us. OK, I'll dig a little further.
pca006132 (Jul 11 2024 at 03:24):you can have a look at https://github.com/elalish/manifold/blob/master/test-cmake.sh
pca006132 (Jul 11 2024 at 03:25):we had this to test cmake find_package(manifold)
Sean (Oct 04 2024 at 20:29):If people haven't seen it, Kushal did a great job summarizing the project outcomes in a presentation at https://drive.google.com/file/d/1u6WuAq0zZ5U48oRBmTi1bplga0G3soe-/view
Last updated: Oct 09 2024 at 00:44 UTC