On Feb 24, 2012, at 05:00 AM, Kaushik Subramanian <humantorch.shadowsin@...> wrote:
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.
At only 4-5 hours a day, you certainly have your work cut out for you! Best of luck. :)
I agree and I apologize. My only aim is to learn more about CAD systems and contribute code to the open source community.
That's all you need to say really, that you're interested in contributing to open source. ;) If you're willing to learn and able to contribute, then open source is a perfect fit. While we won't do your homework for you, most are more than happy to help you learn and become an integrated part of our development team. ;)
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!
Moreover, when I said a month, I meant a month of 40 hours-per-week effort. Roughly 100-200 hours from start to finish. That's not counting time exploring, learning, testing, documenting, communicating, etc.
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.
Your best bet to get started may be to identify 5-10 specific tasks that you'll need to accomplish. A task would be something that is well-defined and probably takes only a few days or less to complete. Stubbing in a new mged/archer "brepify" command (which does nothing but report usage) is an example. Itemizing all primitives and the status of their brep() callback function is another. Identify 3-8 others and you'll have a clear plan moving forward to make sure you're using your 10 weeks wisely.
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?
Yes. All of the primitives in src/librt/primitives have a function in their src/librt/primitives/*/*_brepcpp file that turns them into implicit form.
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?)
That sounds spot on. You can see hundreds of other command examples in the src/libged directory. For an overarching goal, you could aim to implement a conversion capability that converts a given geometry hierarchy into BREP form As a new mged/archer command, that might have a usage statement that looks something like this:
brepify [-vh] [old_object] [new_object]
Sounds super! But where do I start? Just start looking into the code to understand the logic?
I'd start by identify those 5-10 tasks first, the more specific the better. If you share them here, we can discuss and make sure everything is covered before you spend time browsing code. The tasks could certainly change once you get started so it doesn't have to be perfect, but it should point you in a direction. Depending on the task you're working on next will determine what code you'll need to be understanding next so that should save you lots of time.