Hello Daniel!
I figured instead of sending you an attachment, I'd send you a link such
that you can comment on it.
Here it is :
https://docs.google.com/document/d/1RgUDxU3x3IC1r9lba49IlKP9-wJ2PCgAbcwlj7wTlTo/edit?usp=sharing
With Regards,
Kalpit Thakkar
On Sat, Mar 21, 2015 at 3:04 PM, Kalpit Thakkar <ceasy...@gmail.com> wrote:
> On Mon, Mar 16, 2015 at 10:19 PM, Daniel Roßberg <
> danielmrossb...@gmail.com> wrote:
>
>> Kalpit,
>>
>> some answers:
>>
>> 2015-03-16 6:16 GMT+01:00 Kalpit Thakkar <ceasy...@gmail.com>:
>> > Hello Daniel,
>> > I have been looking at Andrei Popescu's patches and I tried to
>> understand
>> > the class design in core interface.
>> >
>> > According to my understanding, every primitive object class has several
>> > constructors : for it's special cases as well as it's general case.
>> > Hyperbolic and Parabolic quadrics derived from any primitive object have
>> > been made into a different class altogether.
>>
>> The constructors are often related to mged commands, e.g. arb7, arb6,
>> etc. to generate arb8s.
>>
>> > Every primitive class has helper classes for any field that is an
>> integral
>> > part of definition of the primitive.
>> > For e.g : In the class BagOfTriangles, the helper class is Face. In the
>> > class Combination, the helper classes are ConstTreeNode and TreeNode,
>> and so
>> > on.
>> > Yes, every class in general has it's fields' modifiers (getter, setter,
>> > destroyer) functions.
>> >
>> > Things common in all classes :
>> > 1. Inheritance from Object class and hence the definition of it's
>> virtual
>> > methods
>> > 2. A protected constructor connecting it to constDatabase (friend
>> class, so
>> > that constDatabase can access the constructor)
>> > 3. The internal structure of the primitive is kept private - only
>> Database
>> > can access it freely (friend class)
>> >
>> > The remaining primitives would be having a similar class design I guess
>> (I'm
>> > not an expert at this, so we'll have to discuss in detail about it)
>> >
>> > Well, I am facing a dilemma : Should we start with the testing of
>> primitive
>> > classes already implemented or should we start with designing new
>> classes?
>>
>> That's a good question. However, testing wouldn't fill a GSoC project.
>>
>> > Maybe we can do the testing of as many primitives as possible till end
>> of
>> > April and then start with designing new primitive classes?
>>
>> Maybe, but the GSoC working period starts in May.
>>
>> > The primitives left are **:
>> > ARBN
>> > ARS
>> > EXTRUDE
>> > REVOLVE
>> > DSP
>> > EBM
>> > METABALL
>> > SPLINE
>> > VOL
>> > GRIP
>> > BINUNIF ^^
>> > SUBMODEL ^^
>> > It looks like Nurb's and Brep's files are written in C++ already; do
>> they
>> > need to be restructured? Or are they fine as they are?
>> > (I personally feel they need restructuring as well as adding some
>> things!)
>>
>> I haven't looked at them yet but they probably need to be restructed a
>> little bit.
>>
>> > That's about primitives. About the features that I would like to add :
>> > 1. Centroid, Surface area and Volume (I'm assuming this would not be
>> very
>> > difficult)
>>
>> Are they available for combinations?
>>
>> > 2. Shading and Lighting from raytracing
>> > I'll need guidance on how to go about for Combinations of primitives!
>> >
>> > NOTE : I'll have to take a short break because my exams are starting
>> from
>> > 18th. I'll be available, but won't be able to provide prompt replies.
>> I'll
>> > be back to work, full flow, from 20th, 1700 hours (UTC +0530).
>>
>> I think you mean in March. I.e. this is no problem.
>>
>> > I will complete reviewing the tests written by Mark for Cone and Torus
>> today
>> > and get back to you.
>> > I'll start for the exams from today, 1700 hours (UTC +0530).
>> > From 20th, 1700 hours : I will start with my proposal and complete
>> rewriting
>> > code wherever needed to bring it in conformation with the guidelines in
>> > HACKING file.
>> > I will then write the tests for the primitives that don't already have
>> one
>> > and I will be communicating with Andrei as well, starting from today.
>> >
>> > PS : I hope I'm making things clear and not hazy. I'm really excited to
>> work
>> > on this project. :D
>> >
>> > ** I haven't included Height Field (HF) and polysolid (POLY) here,
>> because
>> > in the documentation about primitives, it is mentioned that they are
>> > deprecated and, DSP and BOT should be used instead (respectively).
>> Should I
>> > still include them?
>>
>> I would say no.
>>
>> > ^^ Are these actually geometric primitives?
>> >
>> > Doubt : In core interface, what is Unknown.h/.cpp for?
>>
>> This is a place-holder for not yet implemented primitives. For
>> example if you have an arbn the Unknown class will handle it in the
>> core interface. If you ask it for its type it will tell you
>> "Unknown".
>>
>>
>> Regards,
>> Daniel
>>
>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel