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