> 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.
>

Oh right, I didn't try to draw anything with MGED before, even though I
built it. I tried some commands today and yeah, I get the similarity in the
constructors and the MGED commands. Nice!


> > 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.


Yeah, I was suggesting to do the testing part before the coding period
starts in May, so that I also get more familiar with the design and
implementation of the current interface.


> > 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.
>

Okay. Nice then. If time allows, I'll try to do this before coding starts
as well. :)


> > 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?
>

No they are not. So, I guess I'll have to implement new functions in comb.c
first and then create an interface in the API. Am I right?


> > 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.
>

Okay, cool.


> > ^^ 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".
>

Ah! I see. So, this is the guide to be looked up to while designing a new
class in coreinterface, is it?

Some things I would like to talk about :
1. There are some primitives that don't have a centroid, volume and / or
surface area callback(s). So, I'll have to implement their callbacks in the
src/librt/primitives/*/*.c first and then create an interface for them in
the API. I would also add these features for combinations. Right?

2. This time in the project, the two primitives that I want to add without
fail, are ARBN and ARS. That won't be a bad idea, right?

3. I will send you the proposal in a day. I hope that won't be too late! I
want to give you as much time as I can for reviewing it. :)

Regards,
>     Daniel
>

With Regards,
Kalpit Thakkar

------------------------------------------------------------------------------
> 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

Reply via email to