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 > Hello Daniel! I had some discussions with Erik and Sean on the IRC and Mailing list repectively. I had a look at mged and gqa yesterday and Erik told me about the sampling method (it is followed in gqa for finding volume of any object in 'n' number of views). Surface area of the combination would be approximated by tessellating the combination into a triangle mesh. For centroid of combination, I'm not very sure if what I've proposed is good enough. Well, I have attached my first proposal draft. Waiting to hear from you. :) 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 >
Draft1.docx
Description: MS-Word 2007 document
------------------------------------------------------------------------------ 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
