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.
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?
Maybe we can do the testing of as many primitives as possible till end of
April and then start with designing new primitive classes?
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!)
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)
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 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?
^^ Are these actually geometric primitives?
*Doubt : In core interface, what is Unknown.h/.cpp for?*
With Regards,
Kalpit Thakkar
On Fri, Mar 13, 2015 at 10:15 PM, Daniel Roßberg <danielmrossb...@gmail.com>
wrote:
> Kalpit,
>
> Sorry for the late response. I was busy at work.
>
> > I'm sorry I forgot to mention in my changes that you need to include
> > "raytrace.h".
> > The error will go away then and source will be succesfully compiled.
> > Here are the final changes, that I have done and successfully compiled
> the
> > source and run the tests :
> >
> > http://pastebin.com/Y0Aqy7ht
> >
> > I have attached the test log generated by ctest.
> >
> >>
> >> Maybe you should
> >> make a patch file from what you have really compiled and upload it to
> >> sourceforge.
> >
> >
> > Should I upload a patch now and add you as the owner?
>
> Exactly. This is usually what will be evaluated. Otherwise you could
> forget to mention something ;)
>
> >> > Everything else is good and running properly and fits the coding
> style.
> >> >
> >> > So, what's up next? :)
> >>
> >> Where do you think are the building sites of the core interface?
> >
> >
> > I didn't quite get you.
>
> There are many areas where the C++ interface can be improved. E.g.
> - Adding new primitives
> - Adding new features, e.g.
> - Primitives' features like centroid etc.. But they have to work
> for combinations too.
> - Shader-colors from ray-trace
> - Improving the tests/test framework
> - Fixing oddness in BRL-CAD found during C++ interface development
> to list some of them. On which area do you want to work? Whith which
> would you feel comfortable?
>
>
> 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
