Re: [brlcad-devel] Interested in development of BRL-CAD, as a research/idea paper for my undergraduate final year project

[Kaushik S. <hum...@gm...>]

Hello Sean,

Thank you for the prompt reply. My reply follows:

On Thu, Feb 23, 2012 at 1:21 AM, brlcad <br...@ma...> wrote:

>
> So you basically have 9 or 10 weeks remaining... :)
>

Yes, which is about the time I need. I'm willing to dedicate 4-5 hours a
day for the next 10 weeks to work on this. That is the system in my
university. We have 3 whole months off of university to work on our
projects. So I'll be working out of home for my project for the next 2 and
a half months.

That's a rather broad topic category.  You have your work cut out for you,
> but you must narrow your focus.  You don't have nearly enough time to do
> everything you are asking about.  Both methods of implementation and
> applications domains are two very broad categories on their own that you
> could write a book on.  I'd suggest focusing on a coding project over
> applications of CAD since it may be more easily planned, measured, and
> achieved.
>

I agree with you there. I took a broad topic, cause this is the first time
I'm even exposed to the back-end of a "CAD" software. It took me some time
to learn what exactly being "specific" meant. Now, I have a much clearer
idea, since I've been reading up a lot from articles on the official
Documentation and the wiki page. This is also my first time with open
source, so please bear with me if I'm a bit slow to grasp the general
protocols.

But yes, simply focusing on a coding project should be more easily planned,
measured and achieved. Based on what comes from our discussions here, I'll
change my project title to a more apt one.

>
> I suggest sticking to just coding, frankly, since you cannot realistically
> inspect the implementations of most of the commercial CAD software out
> there, only the end-behavior result.  Moreover, most of the commercial CAD
> softwares are built on specific commercial geometry kernels, many of which
> are cross-licensed amongst many of the other CAD systems.  So comparing
> them becomes a very very complex topic.
>

I've been wondering about this myself. I got this idea of comparing
algorithms, from the fact that I could finally compare my output with
industry standards on already existing scales of measurement to show the
effectiveness of what I've done. *My question was if this was possible? Or
would this be possible if I lessened the scope to just open source
applications? *

If it is tedious like you have mentioned, I'm willing to cut that out off
the project scope.


> I'm going to skip a lot of questions from your e-mail because they're more
> a brain dump than anything.  Many of your questions depend on the answers
> to other questions or are completely off-base.  You're all over the place,
> lacking specific goals, and up against a very specific deadline.
>

I agree and I apologize. My only aim is to learn more about CAD systems and
contribute code to the open source community. Since BRL-CAD falls in my
field of study, I thought a project with you guys would be really cool. I
was being all over the place, cause I've been trying to figure out the
software and it's code all by myself. I've been doing a lot of homework,
but when I tried to identify my specific goals, I failed. But this is
mainly my fault, cause I've been lacking communication when there's a whose
listserve of people willing to help me out. I wish to change that from now
on. I'll also try to be more coherent with my emails.

I also want to clarify that this project wouldn't mark the end of our
correspondence. I wish to stay, contribute and gain more experience.

That project will probably take a minimum of a month full-time effort to
> complete plus another week for overhead and learning time, so you should
> plan accordingly.  Given you only have 9 or 10 weeks remaining, you will
> need to start immediately if you intend to finish within 9-10 months.  With
> the other analysis work you were proposing, I don't see that happening..
>

Agreed. I'm willing to stick to just the coding part of it and start
immediately.

The Implicit_to_NURBS_conversion wiki page is the "real deal" and more
> appropriate for your project.  You should expect it to take a month minimum
> to implement plus another month for overhead discussions, learning,
> documentation, testing, etc, spread throughout.
>

I didn't know this. Thanks for the clarification!

The task you found involves converting geometry that is in non-BREP (i.e.,
> probably implicit) form (with CSG operators) into BREP (i.e., NURBS) form
> (with CSG operators).
>

This makes things much clearer.

 You don't have time for that. ;)
>
> Implicit-to-NURBS or NURBS tessellation is about as simple as it gets and
> either (but not both) are viable coding projects.  Moreover, the time
> estimates on the NURBS_TODO page would be in units of weeks, not days, for
> someone getting started (so 2 days becomes 2 weeks minimum).
>

I can logically understand the implicit-to-NURBS project better than the
tessellation one, so I'm sticking to the conversion project. Maybe
tessellation can be my next project :). And about the time I have left,
like you said, I'm willing to focus on a more specific goal over the next 2
months to complete this project.


> Most are already converted, but only as a C API function.  There needs to
> be a command that walks a hierarchy, converts the geometry to NURBS, then
> writes a new hierarchy.  Maybe call the command "brepify".
>

Thanks for this clarification. When I was looking through the source code
for primitives, I was sure I saw some BREP and NURBS functions. *This is
what you're refering to as C API functions, yeah? *

*So, the sole command I'll be working on is "brepify". This command allows
users to convert primitives to BREP format. (The specific goal I need to
have?)*

You have time but only if you focus on getting familiar with the code NOW
> and stop fiddling with comparisons and research.  If you do that, you
> should be able to finish comfortably with time available to document your
> progress and perform ray trace visualization comparisons.
>

*Sounds super! But where do I start? Just start looking into the code to
understand the logic?*


> I strongly suggest breaking your mails up into much smaller chunks.  You
> should have no more than one question per e-mail if you need to get a quick
> response, plus it should help you prioritize your questions and clarify
> your goals.  Look forward to your follow-up. ;-)
>

Again, I apologize for the haphazard manner in which my previous mails were
drafted. I promise to improve!