Re: [brlcad-devel] About GSOC 2015
Hi Morrison Thanks for the reply. Actually, the project ideas( Bending light and Celestial mechanics particle system) are not the only two that attract me. I think maybe I can provide some of my background and let you guys suggest a project for me? Currently I am a master candidate in China, and my major is computer science. I've been a research assistant about computer graphics for two years. - I've read some books(like pbrt) and papers about graphics. And I also implemented some toy raytracers by my own. Here is one: https://github.com/flexwang/HadoopRayTracer It is written in java though my favorite language is C/C++ - I've contributed to Appleseed, which is an open source renderer project. Here is the issue I tackled: https://github.com/appleseedhq/appleseed/issues/210 - I've done a siggraph 2015 project as the second author. The project is about 3D-reconstruction and I wrote most of the codes and I also wrote the code for rendering the final demo using Embree https://embree.github.io/as ray tracing kernels. Also, I think it is a good idea to commit a patch first, so would you guys mind suggesting something easy to handle for me? -- *Zhaotian * -- 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
Re: [brlcad-devel] GSoC Proposal (X3D importer)
Hello Sean, On 20 March 2015 at 05:02, Christopher Sean Morrison brl...@mac.com wrote: Really the only valid reason for implementing a library that is already readily available would be because they are license incompatible or yours will be substantially and non-subjectively better in some way. That usually means faster or less memory or new features. Just because something provides features X, Y, and Z when you only need feature X is not a strong position. Your response has given me some light on what path to follow. I have been revisiting some options and I think white dune http://vrml.cip.ica.uni-stuttgart.de/dune/ would be great for X3D parsing. It has great support for vrml and x3d including support for nurbs. Some of the files I used to test the vrml-g converter were X3D NurbsPatchSurface and NurbsPatchSolid files which I converted to vrml polygonal representation using white dune and so I really appreciate its functionality. The source code is about 44MB out of the box and it uses GNU GENERAL PUBLIC LICENSE Version 2. I have been able able to reduce the code to about 12MB but it still takes a noticable amount of time to compile I think I can be able to reduce it to less than 7MB by isolating the code essential for parsing but that would take some time and better understanding of the code and also I have not encountered any issues with dependencies. Thanks Konrad -- 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
Re: [brlcad-devel] Real-Time Ray Tracing
On Mar 20, 2015, at 7:17 PM, Vasco Alexandre da Silva Costa vasco.co...@gmail.com wrote: I came up with this tentative work plan for improving the OpenCL (CL) RT code on BRL-CAD: Excellent! - Hook into shot and db load routines (hooks disabled by default) in order to capture ellipsoid primitives and shots into the CL side. Get familiar with these top level interfaces of the code. (2 weeks) This might require a little more inspection. For places where you might “get opencl ready”, I would expect you to hook in when a raytrace context is created (e.g., rt_dirbuild()) or during geometry prep, which every object implements and is called during directory building. If you see the rt_ell_prep() function in the opencl branch, that’s effectively where this is already happening for our quick test. - CL megakernel for boolean operations. i need to check how involved this will be to have a more accurate time estimate. Probably requires storing some primitive hierarchy on CL. Integration with C++ side of things for other primitives may be problematic. (2 weeks?) This may be a large task, possibly the bulk of your timeframe, as boolean weaving is one of the most complex aspects in BRL-CAD. Understanding it is almost certainly going to take you some time. However, you’ll probably be able to publish a paper on it when you’re done! :) Something to consider, you could even propose *only* focusing on this aspect for GSoC. What I mean is that you could spend time restructuring the rt dispatch logic, which is something like forAllPixels-shootOneRay-traverseScene-evalHits-weaveBooleans-colorizePixel that iterates over all pixels depth-first pipeline style. You’d restructure it into something like phase1: forAllPixels-shootOneRay-traverseScene-evalHits then phase2: CLweaveAllBooleans-CLcolorizePixels. If you got it working, you’d speed up ray tracing somewhere between 25-50% (as that is about how much time Boolean weaving takes) for all geometry, not just ellipsoids and it could go into immediate production use. It’d be in users hands. More on this later. With time-permitting, you could then work on the rest of the pipeline like implementing the top-level bundled dispatch and scene traversal acceleration, and primitive shot() routines. - Implement CL rectilinear grids [1] (improvement on the Mike Gigante Nugrid currently used in BRL-CAD) spatial partitioning construction and traversal. Should reuse most of the regular grid construction code but requires some extra construction steps and has different traversal scheme (2.5 weeks) Sounds good, but know that we don’t actually use Nugrid. It’s faster for some scenes, slower for others — overall a wash. I think there’s also a bug somewhere in there. We use a custom BSP traversal for production work that is much more thoroughly tested and robust. Grids generally do much better on the GPU than they do on the CPU. - Cleanups, bugfixes, final tests, docs. (2.5 weeks) So the only planning concern is that this isn’t an incremental plan. It’s always a big red flag when a proposal has a big “test and document” at the end. If anything goes wrong or takes a couple weeks longer than planned with one of your early steps, we usually end up with something incomplete that cannot be shipped to users. Assume something will go wrong, that it will take longer, or your computer will explode next week. How would you change your approach so that users still get something? If you had to immediately stop working, there should be something usable (without requiring additional work by you or others to make it usable). This is an aspect of “coding complete” mentioned on http://brlcad.org/wiki/Google_Summer_of_Code/Acceptance#Write_complete_code Basically, this means thinking through how you can incrementally break up the task into phases where each phase gets tested and could be put into production use without detriment. It not only means you’re continually cleaning up, testing, and updating docs, it means you’re continually focused on the user and their benefit instead of your development comfort. If that means getting a little less done, that’s okay. Users will love you for it. My other concern was that your objective doesn’t result in a feature that affects users. Yay, devs can raytrace ellipsoids MUCH faster … and users see nothing. That’s why I’d suggest either focusing only on boolean weaving, or on bundled ray dispatch+traversal, or hit+result gathering, etc — something that could be put into immediate use, even if it’s not going to give the 10x speedup until the rest of the pipeline is converted. Changing BRL-CAD’s render pipeline to support this style of evaluation is going to be a lot of work. Still, outstanding proposal progress. This and other proposals are making me pretty darn excited! Cheers! Sean p.s. Some technical libraries to consider in lieu of directly binding to OpenCL:
Re: [brlcad-devel] GSoC 2015 participation
On Mar 20, 2015, at 9:51 AM, Vicky vi...@altermundi.net wrote: Hi all! I joined to this mailing list because I am a CAD user and I like FOSS, I would like to contribute to BRL-CAD by participating to GSoC 2015. Welcome Vicky! From the ideas list I liked more Benchmark Performance Database and Material Database, I like web development but I usually don't have much time to expand my knowledge, and this would be a very good occasion for me to both contribute to the community, learn more interesting stuff, know better BRL-CAD community, and have the possibility to do this gorgeous stuff full time this summer :) For some projects that have been worked on previously, you’ll want to make sure you check on the prior efforts to see where things left off. Your proposal should be a continuation/improvement of the work to date, usually with an emphasis on “finishing” the work, adding production quality, improving usability, etc. This also means taking time to become familiarized with any existing code, actually installing, and testing things out. All prior GSoC projects are on our website: http://brlcad.org/wiki/Google_Summer_of_Code/2014 http://brlcad.org/wiki/Google_Summer_of_Code/2013 http://brlcad.org/wiki/Google_Summer_of_Code/2012 http://brlcad.org/wiki/Google_Summer_of_Code/2011 http://brlcad.org/wiki/Google_Summer_of_Code/2009 http://brlcad.org/wiki/Google_Summer_of_Code/2008 Those are also GREAT resources for seeing examples of other GSoC proposals we’ve accepted in the past, the level of detail we expect to see, and summaries for how those projects went. I have recently completed Aerospace Engineering and I am student of Electronic Engineering right now, as hobby I have done web development and design, so I know HTML, CSS, JavaScript and various web development technology such as JQuery and AJAX, while I have basic knowledge of SQL, Python and PHP. I sent a message just yesterday that you might want to look up on the mailing list archives (on sourceforge). I gave an overview of our project priorities and mentioned a web application topic that might be of interest — implementing an interface for testing repository commit ranges. I would know if those ideas would be very integrated in BRL-CAD wiki or the plan is to keep them as stand alone websites? It’s good when projects integrate with existing infrastructure, but it’s even more important that projects get taken to completion so they can actually be put to use and remain maintainable by others. However this is accomplished is often secondary if the production quality is there. Cheers! Sean -- 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
Re: [brlcad-devel] Object-oriented C++ Geometry API : Project for GSoC '15
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
[brlcad-devel] GSoC 2015 participation
Hi all! I joined to this mailing list because I am a CAD user and I like FOSS, I would like to contribute to BRL-CAD by participating to GSoC 2015. From the ideas list I liked more Benchmark Performance Database and Material Database, I like web development but I usually don't have much time to expand my knowledge, and this would be a very good occasion for me to both contribute to the community, learn more interesting stuff, know better BRL-CAD community, and have the possibility to do this gorgeous stuff full time this summer :) I have recently completed Aerospace Engineering and I am student of Electronic Engineering right now, as hobby I have done web development and design, so I know HTML, CSS, JavaScript and various web development technology such as JQuery and AJAX, while I have basic knowledge of SQL, Python and PHP. I would know if those ideas would be very integrated in BRL-CAD wiki or the plan is to keep them as stand alone websites? I am very motivated to do this project and I would definitely learn a lot of things, moreover i would like to continue to cooperate with BRL-CAD community also after the GSoC ends :) Thanks for this possibility! Cheers! -- 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
Re: [brlcad-devel] [GOSC 2015 Introduction][Mesh Library Clean up][STEP Viewer Program]
Hello, If you have trouble finding the attached document here is the online link to view them. Internship Report: https://drive.google.com/file/d/0B0lbgk9iEcLqalJwVlRkZVZlc0hlQW4tcS12TGJyc2JNNkJJ/view?usp=sharing Mesh optimization module code documentation (GSOC 2014): https://drive.google.com/file/d/0B0lbgk9iEcLqNGx3aFkwcExrZ2dVNVk3andMMVJsOExqeElR/view?usp=sharing 2015-03-20 19:59 GMT+05:30 Milinda Fernando milind...@gmail.com: Hello, I am Milinda and I am a final year undergraduate student from Department of Computer Science and Engineering, University of Moratuwa Sri Lanka. I am specifically interested in the projects *“Mesh library Cleanup”* and *“STEP Viewer”*. In GSOC 2014 I implemented a separate mesh optimization module for the ViennaMesh http://viennamesh.sourceforge.net/ meshing library mentored by Florian Rudolf at Computational Science and Engineering, TU Wien. I have attached the mesh optimization module code documentation with this e-mail so you can get an idea on what I have done in that project. I believe if I have some extra time I can implement some of the mesh optimization functionality after cleaning up the Mesh library code. I have experience on working with the Opencascade http://www.opencascade.org/ library and I have coded STEP viewers/exporter programs using Opencascade Library. I got to know about Opencascade when I was working as an Intern in Sutra http://www.sutratechnologies.com/ Technologies which is attached to Concepts NREC http://www.conceptsnrec.com/. I have attached my internship report with this email so if you want you can refer to that to get an idea on what I have done during my internship. But in this project I need to implement a STEP viewer based on the BRL-CAD libraries right? I will try to submit the proposals for these ideas as soon as possible. Thank You. -- Milinda Fernando. Undergraduate Department of Computer Science and Engineering University of Moratuwa Sri Lanka. Blog: http://milindasf.blogspot.com/ -- Milinda Fernando. Undergraduate Department of Computer Science and Engineering University of Moratuwa Sri Lanka. Blog: http://milindasf.blogspot.com/ -- 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
Re: [brlcad-devel] Object-oriented C++ Geometry API : Project for GSoC '15
On Mon, Mar 16, 2015 at 11:27 PM, Andrei - Constantin Popescu popescu.andrei1...@gmail.com wrote: 2015-03-16 9:07 GMT+02:00 Kalpit Thakkar ceasy...@gmail.com: Kalpit, First of all, what I'm telling you is much more informal and probably a lot less accurate than what Daniel can, so it's best to stick with his feedback. Yes, I will stick with his feedback. As a fellow developer, I thought your experience might help me, so I asked you for details on this. Hello Andrei, I wanted to ask you some questions! Foremost, How did you start out on your project? I mean, what were the initial places where you looked and found information required for carrying out the project? I have been looking at your patches and the work done related to this in GCi '14. Your implementation on BoT, Pipe, Sketch and Sphere is pretty clean and awesome! Well, in your proposal, you have mentioned about vol, extrude and ars as well. Did you start anything on it? Can you guide me about it? No, I haven't done anything else than those you mentioned, I worked a bit on RCC but I believe I stopped very early, or was already done or so. What you could do (and again, Daniel might give you a better task) is to merge/apply my Pipe implementation, there is some feedback from Daniel which I hadn't apply, it's a good/easy thing to do. Basically, my idea was to look at how the objects are implemented internally and to design(with Daniel) a class that would resemble the primitive's behaviour. I worked to fit the internal structure into the core interface smoothly. All the operations are actually performed on the BRL-CAD internal structures (rt_primtive_internal) What I would do is integrate the work that's already been done( I think pipe is last unmerged) and anything that Daniel mentioned. You should figure out a primitive priority. In example, extrude depended on Sketch, it was difficult/not useful to implement extrude before having sketch. Regarding testing, my humble opinion is that you could test a primtive that's support for another(sketch - extrude), it's no point developing a new one if the base one doesn't work. Again, Daniel helped me throughout this project as well, so he's really the best person to speak to, I just tried to share my experience to the best of my capability. Good luck! Thanks a lot, Andrei. I was thinking the same about looking at your Pipe implementation and discussing with Daniel about anything that should be added / applied to it, because it wasn't merged, meant there was something more to be done! I will do that soon enough. That would also help me get familiar with how to go about reviewing someone else's work and make it work with the system. Also, how are things merged. Right? Yeah, all operations are done on rt_*_internal and Daniel told me that constructors use the form used in MGED commands. That was something I should've figured out but I guess I didn't work hard enough to look for it. Yeah, I have figured out a priority : I want to implement ARBN and ARS this time, without fail and as you said now that extrude depends on Sketch, it will be a good idea to implement extrude. I'll keep in mind what you have said. It has been really helpful to focus my line of thought and I hope to keep getting your valuable feedback. Regards, Andrei 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
Re: [brlcad-devel] Real-Time Ray Tracing
On Sat, Mar 21, 2015 at 12:30 AM, Christopher Sean Morrison brl...@mac.com wrote: ... This may be a large task, possibly the bulk of your timeframe, as boolean weaving is one of the most complex aspects in BRL-CAD. Understanding it is almost certainly going to take you some time. However, you’ll probably be able to publish a paper on it when you’re done! :) Something to consider, you could even propose *only* focusing on this aspect for GSoC. What I mean is that you could spend time restructuring the rt dispatch logic, which is something like forAllPixels-shootOneRay-traverseScene-evalHits-weaveBooleans-colorizePixel that iterates over all pixels depth-first pipeline style. You’d restructure it into something like phase1: forAllPixels-shootOneRay-traverseScene-evalHits then phase2: CLweaveAllBooleans-CLcolorizePixels. I see. Then I need to examine this part better and propose a plan focused on this. I only have CS grad student like knowledge of CSG since most of my experience in RT is with acceleration structures and ray processing so I am interested in seeing how you do the weaving. If there are any specific optimizations, etc. If you got it working, you’d speed up ray tracing somewhere between 25-50% (as that is about how much time Boolean weaving takes) for all geometry, not just ellipsoids and it could go into immediate production use. It’d be in users hands. More on this later. Yeah this seems to be a good idea. I wanted to do something that would leave an actual performance improvement for users in the end. If this is the critical compute intensive task then it is what needs to be addressed. With time-permitting, you could then work on the rest of the pipeline like implementing the top-level bundled dispatch and scene traversal acceleration, and primitive shot() routines. ... Sounds good, but know that we don’t actually use Nugrid. It’s faster for some scenes, slower for others — overall a wash. I think there’s also a bug somewhere in there. We use a custom BSP traversal for production work that is much more thoroughly tested and robust. Grids generally do much better on the GPU than they do on the CPU. That is news to me. When i glanced at librt/shoot.c I saw a lot of references to 'nugrid'. There's only one match for 'nubsp' and it is in a comment. I guess I need to start peeling this and see what is actually being called. - Cleanups, bugfixes, final tests, docs. (2.5 weeks) So the only planning concern is that this isn’t an incremental plan. It’s always a big red flag when a proposal has a big “test and document” at the end. If anything goes wrong or takes a couple weeks longer than planned with one of your early steps, we usually end up with something incomplete that cannot be shipped to users. I'm used to doing incremental development with continuous integration. I don't know how to do it any other way. I always test every step in order to not break the code. But in my experience something always needs fine tuning or debugging in the end. Also the docs always lag behind everything. Not dedicating time specifically in the plan for docs usually means next to no docs will be produced. Assume something will go wrong, that it will take longer, or your computer will explode next week. How would you change your approach so that users still get something? If you had to immediately stop working, there should be something usable (without requiring additional work by you or others to make it usable). This is an aspect of “coding complete” mentioned on http://brlcad.org/wiki/Google_Summer_of_Code/Acceptance#Write_complete_code I was an OSS project maintainer (Freeciv) for close to 4 years. You never ever break the code with a commit. BTW what's your process for patch code reviews? You discuss patches on the mailing-list? Basically, this means thinking through how you can incrementally break up the task into phases where each phase gets tested and could be put into production use without detriment. It not only means you’re continually cleaning up, testing, and updating docs, it means you’re continually focused on the user and their benefit instead of your development comfort. If that means getting a little less done, that’s okay. Users will love you for it. My other concern was that your objective doesn’t result in a feature that affects users. Yay, devs can raytrace ellipsoids MUCH faster … and users see nothing. That’s why I’d suggest either focusing only on boolean weaving, or on bundled ray dispatch+traversal, or hit+result gathering, etc — something that could be put into immediate use, even if it’s not going to give the 10x speedup until the rest of the pipeline is converted. Changing BRL-CAD’s render pipeline to support this style of evaluation is going to be a lot of work. I basically wanted to have a whole (optional) accelerated rendering path from end to end so we could then work on the primitives
[brlcad-devel] GSOC'15:NURBS EDITING SUPPORT
I have following doubts in this subproject: 1. Do we have support for converting trimmed to untrimmed curves with T-splines? http://www.tsplines.com/technology/WTN.pdf 2. Can we use Dual loop algorithm for smoothening curves? http://www.scientific.net/AMR.97-101.2477 3. Does detaching curve mean the same as removing knots from B-splines? -- Regards, Nihar Mehta, Second Year Undergraduate, Dept of Mechanical Engineering, Minors in Computer Science IIT Bombay. -- 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
[brlcad-devel] Interest in GSoC 2015
Hi everyone, I am Leger Foposse, a Computer Science postgraduate major from the University of Yaounde, Cameroon. I am interested in the STEP AP242 project and would like to know the specific features which pertain to AP242 that need to be added to the step-g importer. Regards. Leger Foposse. -- 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
Re: [brlcad-devel] Combination in LIBRT
On Mar 20, 2015, at 12:41 PM, Kalpit Thakkar ceasy...@gmail.com wrote: Hello! I have been trying to figure out for sometime now, what exactly is a combination in LIBRT. A combination is a collection of objects. Semantic meaning is given to a combination based on where it exists hierarchically and what it contains. Is it a non-leaf node in the tree made out of the different primitives in the scene (I guess this tree would then be used for raytracing?) It can be, yes. OR Is it a combination of different primitives explicitly assembled by the user? It can be, yes. Those options are not mutually exclusive. :) By definition, they are non-leaf nodes in terms of the geometric directed acyclic graph that they comprise. They describe a hierarchical grouping of primitives (and other combinations). They can be rendered (as can primitives). They can be assembled by the user, e.g., by a command. They can be created by some code, e.g., by an importer or procedural geometry generator. They are geometry objects. Take a look at the mged quick ref card (go to website, documentation section) for a brief summary of terminology. Cheers! Sean -- 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
Re: [brlcad-devel] [GOSC 2015 Introduction][Mesh Library Clean up][STEP Viewer Program]
n Mar 20, 2015, at 10:29 AM, Milinda Fernando milind...@gmail.com wrote: I am Milinda and I am a final year undergraduate student from Department of Computer Science and Engineering, University of Moratuwa Sri Lanka. Welcome Milinda! I am specifically interested in the projects “Mesh library Cleanup” and “STEP Viewer”. Awesome. Note that mesh library cleanup will be a continuation or restart of work performed last summer (see logs @ http://brlcad.org/wiki/Google_Summer_of_Code/2014 and check out the nmgreorg branch in our source repository ), so finishing that work would be highly valuable. I recommend talking with Zhao and checking out the sources. The STEP Viewer project is an idea for the STEPcode association, so you should join their mailing list to talk about it more there. Two proposals would be perfect if you can manage the effort. See http://brlcad.org/wiki/Google_Summer_of_Code/Checklist for a link to talk about STEPcode work. In GSOC 2014 I implemented a separate mesh optimization module for the ViennaMesh meshing library mentored by Florian Rudolf at Computational Science and Engineering, TU Wien. Neat, I haven’t looked at Vienna in years. Rather relevant to our work. I have attached the mesh optimization module code documentation with this e-mail so you can get an idea on what I have done in that project. I believe if I have some extra time I can implement some of the mesh optimization functionality after cleaning up the Mesh library code. What mesh representation structure does ViennaMesh implement? Half-edge? Winged-edge? Something else? I have attached my internship report with this email so if you want you can refer to that to get an idea on what I have done during my internship. But in this project I need to implement a STEP viewer based on the BRL-CAD libraries right? Actually no. You can use any libraries to build the viewer — you’re welcome to use BRL-CAD’s libraries, but you’ll probably be better suited with a GUI framework like Qt or a minimal API like fltk, wxwidgets, or clanlib. BRL-CAD currently uses tcl/tk extensively, but we’ll eventually be migrating over to qt ourselves. That said, developing a STEP Viewer is for the STEPcode project, so you should discuss requirements with them on their mailing list. Cheers! Sean -- 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
Re: [brlcad-devel] Interest in GSoC 2015
On Mar 20, 2015, at 8:19 AM, leger foposse fopossele...@gmail.com wrote: Hi everyone, I am Leger Foposse, a Computer Science postgraduate major from the University of Yaounde, Cameroon. I am interested in the STEP AP242 project and would like to know the specific features which pertain to AP242 that need to be added to the step-g importer. Ideally all of them. The step-g importer is currently linked against one parser, the ap203 parser generated by STEPcode. It imports solid geometry in the ap203 format, which entails support for too many entity types to itemize here — read the sources. We’d like to do the same with the ap242 format, at a minimum supporting the advanced shape representations (solid geometry objects) and more over time. Cheers! Sean -- 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
Re: [brlcad-devel] Combination in LIBRT
On Mar 20, 2015, at 3:22 PM, Kalpit Thakkar ceasy...@gmail.com wrote: Now, if I import some model into MGED, which is an external model, will it also be broken down into a hierarchy by MGED, such that leaf nodes consist of basic primitives and the parent nodes are obtained by applying union, intersection or subtraction on the child nodes? This entirely depends on what the source geometry is, what representation format it’s in, how the importer is written, and what that translate to in our system. Imported geometry rarely consists of basic primitives, usually importing in as polygonal mesh geometry (e.g., our nmg or bot object types) or as NURBS boundary representation (i.e., our brep object type). That is, is every combination a hierarchical grouping of primitives, where leaf nodes are some core(basic) primitives? (I have based this doubt on the tree you have drawn using letters CAD in the Quick Ref Card) I’m not sure I fully understand your question. A combination object is a collection of objects and operators. The objects can be primitive objects and other combination objects. The operations describe what kind of grouping to perform. What doubt do you have about the card diagram? It shows you a visual tree with several primitive objects and a hierarchy of combination objections. Okay, so I was stuck here while I was trying to figure out how to find the centroid of the combinations, because I wasn't able to visualize how exactly a combination would look like in MGED. While talking to ``Erik on IRC right now, I got an idea of how to get the volume and surface area of a combination, well, to some extent atleast. The approach involves shooting rays on the object with square 1mmx1mm cells on the grid and the distance travelled by the ray inside the object will help me find the volume. I suggest actually going through one or two of the mged tutorials. I think there is confusion because you’re trying to understand terms without actually using the tools. Especially if you plan on writing code, you probably need some basic familiarity with mged, gqa, and rtweight. The approach you suggest is undesirable as it can fail on extremely small and large objects. If you need to sample, we have tools already that do this well — it’d be better to refactor them into an API that you query. For some combinations, ones comprising single primitives or disjoint objects, you wouldn’t need to sample at all and can evaluate an exact solution. Surface area would be found by tessellating the object and summing the areas of the triangle. This would be merely an approximation. If there is any mathematical alternative to finding the volume and surface area of combinations, it'll be really helpful. Centroid is still pending. You’re going to waste time trying to tackle too many things at once. Half-solutions are not at all useful. I suggest focusing on just one small incremental change/improvement, if you’re trying to develop a patch. Cheers! Sean -- 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
Re: [brlcad-devel] Combination in LIBRT
On Fri, Mar 20, 2015 at 10:29 PM, Christopher Sean Morrison brl...@mac.com wrote: On Mar 20, 2015, at 12:41 PM, Kalpit Thakkar ceasy...@gmail.com wrote: Hello! I have been trying to figure out for sometime now, what exactly is a combination in LIBRT. A combination is a collection of objects. Semantic meaning is given to a combination based on where it exists hierarchically and what it contains. Is it a non-leaf node in the tree made out of the different primitives in the scene (I guess this tree would then be used for raytracing?) It can be, yes. OR Is it a combination of different primitives explicitly assembled by the user? It can be, yes. Those options are not mutually exclusive. :) By definition, they are non-leaf nodes in terms of the geometric directed acyclic graph that they comprise. They describe a hierarchical grouping of primitives (and other combinations). They can be rendered (as can primitives). They can be assembled by the user, e.g., by a command. They can be created by some code, e.g., by an importer or procedural geometry generator. They are geometry objects. Take a look at the mged quick ref card (go to website, documentation section) for a brief summary of terminology. Thanks a lot Sean! I had a look at the MGED ref card and I have a good understanding about what are combinations now! Now, if I import some model into MGED, which is an external model, will it also be broken down into a hierarchy by MGED, such that leaf nodes consist of basic primitives and the parent nodes are obtained by applying union, intersection or subtraction on the child nodes? That is, is every combination a hierarchical grouping of primitives, where leaf nodes are some core(basic) primitives? (I have based this doubt on the tree you have drawn using letters CAD in the Quick Ref Card) Okay, so I was stuck here while I was trying to figure out how to find the centroid of the combinations, because I wasn't able to visualize how exactly a combination would look like in MGED. While talking to ``Erik on IRC right now, I got an idea of how to get the volume and surface area of a combination, well, to some extent atleast. The approach involves shooting rays on the object with square 1mmx1mm cells on the grid and the distance travelled by the ray inside the object will help me find the volume. Surface area would be found by tessellating the object and summing the areas of the triangle. If there is any mathematical alternative to finding the volume and surface area of combinations, it'll be really helpful. Centroid is still pending. I'm trying to understand the method ``Erik suggested nicely right now. If you have any suggestions, please do let me know. :) Cheers! Sean 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
Re: [brlcad-devel] Combination in LIBRT
On Sat, Mar 21, 2015 at 1:52 AM, Christopher Sean Morrison brl...@mac.com wrote: On Mar 20, 2015, at 3:22 PM, Kalpit Thakkar ceasy...@gmail.com wrote: Now, if I import some model into MGED, which is an external model, will it also be broken down into a hierarchy by MGED, such that leaf nodes consist of basic primitives and the parent nodes are obtained by applying union, intersection or subtraction on the child nodes? This entirely depends on what the source geometry is, what representation format it’s in, how the importer is written, and what that translate to in our system. Imported geometry rarely consists of basic primitives, usually importing in as polygonal mesh geometry (e.g., our nmg or bot object types) or as NURBS boundary representation (i.e., our brep object type). That is, is every combination a hierarchical grouping of primitives, where leaf nodes are some core(basic) primitives? (I have based this doubt on the tree you have drawn using letters CAD in the Quick Ref Card) I’m not sure I fully understand your question. A combination object is a collection of objects and operators. The objects can be primitive objects and other combination objects. The operations describe what kind of grouping to perform. What doubt do you have about the card diagram? It shows you a visual tree with several primitive objects and a hierarchy of combination objections. Okay, so I was stuck here while I was trying to figure out how to find the centroid of the combinations, because I wasn't able to visualize how exactly a combination would look like in MGED. While talking to ``Erik on IRC right now, I got an idea of how to get the volume and surface area of a combination, well, to some extent atleast. The approach involves shooting rays on the object with square 1mmx1mm cells on the grid and the distance travelled by the ray inside the object will help me find the volume. I suggest actually going through one or two of the mged tutorials. I think there is confusion because you’re trying to understand terms without actually using the tools. Especially if you plan on writing code, you probably need some basic familiarity with mged, gqa, and rtweight. The approach you suggest is undesirable as it can fail on extremely small and large objects. If you need to sample, we have tools already that do this well — it’d be better to refactor them into an API that you query. For some combinations, ones comprising single primitives or disjoint objects, you wouldn’t need to sample at all and can evaluate an exact solution. Surface area would be found by tessellating the object and summing the areas of the triangle. This would be merely an approximation. If there is any mathematical alternative to finding the volume and surface area of combinations, it'll be really helpful. Centroid is still pending. You’re going to waste time trying to tackle too many things at once. Half-solutions are not at all useful. I suggest focusing on just one small incremental change/improvement, if you’re trying to develop a patch. Cheers! Sean I'm sorry I'm rushing this too much. I am trying to develop my proposal for the Object-Oriented C++ Geometry API project and I want to include adding features like Centroid, Volume and Surface Area of the primitive in the interface. I discussed with Daniel and he said, it should work for combinations as well. So, I was trying to understand combinations and how to implement these features in it's case. I will look into the tools you mentioned here and do my homework. I was a bit frustrated because I wasn't getting a clue as to what to do and hence started asking confusing questions! Sorry if this caused an inconvenience. With Regards, Kalpit Thakkar PS : I'll come back after doing homework with better questions :) -- 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
Re: [brlcad-devel] GSoC 2015 Introduction
On Mar 19, 2015, at 7:33 PM, Ilinca Andrei andrei.ilinc...@gmail.com wrote: Kintel advised me to aim towards creating a common parser for both openscad and brl-cad and relicense that as LGPL or BSD/MIT. He said we could either refactor existing openscad code into a clean component, or rewrite the parser and retrofit it into openscad. The former is a bit messy but safer - the latter would be preferable but is likely a fair bit of work. What is your advice regarding this matter? We would prefer bsd/mit license, but as far as which approach would be better — that’s not something I can fully answer without researching the situation in depth. All I can offer is industry observation. You being unfamiliar with the existing code will undoubtedly be biased towards a rewrite. That’s a position *most* programmers prefer taking when presented with a refactor vs rewrite. However, most research on the subject has shown it’s nearly always better to refactor. Exceptions are when you’re changing entire paradigms, sometimes when you’re changing languages, or when it’s just not very much or the code is young. The bigger and more mature the code, the less likely it’ll be cost effective. That said, I know very little about the modular status of their code, its age/maturity, its complexity, or the level of effort that might be involved. Just recognize your own bias when estimating, and if you work with them to estimate that effort, you should be able to answer the question better than anyone. Summary: break down both those options into a set of at least 10 subtasks and estimate how long each might take, show them your estimates and see if they concur, then you’ll have a better plan on how to proceed. I understood a bit more about their internal structure (their compile table was very useful too) and there are 2 types of OpenSCAD files: *.scad- normal ones, providing the full list of features and *.csg , which are a subset that only contain a smaller set of features and those are basically a tree describing the model using a defined set of operators. So, if for the .scad file ,the converting flow would be .scad - (parse) - AST - (evaluate) - Node Tree , for the .csg file that would turn into .csg - (parse) - Node Tree, leaving out the evaluating part. He said that, if I go for the .csg - .g first, a good way to start would be this. What is your opinion? I have no basis with their code or that module to have an opinion on whether that’s a good way. I’m would have to explore and do extensive homework (which you should be doing). Doing .csg to .g first does sound intrinsically less risky on the surface simply because there’s not an intermediate representation and evaluation step. Incremental steps that demonstrate functionality is desirable. They have also told me about FreeCAD and their python parser. I believe I could utilize that python code to quickly establish a .csg to .g converter (that might be good for prototyping, testing etc.). The only problem will be using it in brl-cad's binary, since brl-cad uses C/C++. A C++ component could be build later, separately, but will take longer time. Do you think I should start working on it ? We would prefer something that will integrate with our newly developing geometry conversion (GCV) API. Binding through to python can work but is not ideal (especially for large complex models with lots of detail). If you went with a refactoring approach, would that also be python code or C/C++ code? A beneficial aspect for both orgs would be to also make (if time allows) a .g - .scad converter. Kindel suggested that if we successfully develop a .scad - .g one, to reverse the algorithm wouldn't be so hard. I believe this would (very probably) overcome the GSoC timeline but I'm willing to work until October 1st (when school starts) if needed in order to complete both converters. Do you think its a good idea or its too much to ask? Going .g to .scad would be very easy, but I agree that you almost certainly will not have time during GSoC to do both (unless you’re just that awesome). ;) If and when you start going down that route, we can certainly help you navigate the BRL-CAD .g API for creating that exporter. We have LOTS of examples you can follow that are very similar to what you’ll need. Cheers! Sean -- 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
Re: [brlcad-devel] Combination in LIBRT
On Mar 20, 2015, at 5:35 PM, Kalpit Thakkar ceasy...@gmail.com wrote: I'm sorry I'm rushing this too much. I am trying to develop my proposal for the Object-Oriented C++ Geometry API project and I want to include adding features like Centroid, Volume and Surface Area of the primitive in the interface. I discussed with Daniel and he said, it should work for combinations as well. So, I was trying to understand combinations and how to implement these features in it's case. I will look into the tools you mentioned here and do my homework. I was a bit frustrated because I wasn't getting a clue as to what to do and hence started asking confusing questions! No problem at all asking questions — you shouldn’t hesitate to engage in discussions. That goes for everyone new here. ;-) Just the less researched or more vaguely worded a question (e.g., an open-ended question asking for guidance), the more difficult it is to give you a useful reply. We want to help each other, we enjoy solving problems! When you do your homework and ask detailed or “hard” questions, those are really great to see. Of course by the time you do that, you just might end up answering your own question or someone else’s question. If you do, share your successful understandings, your eureka moments. It can be exciting! That’s when you start becoming a productive contributor to open source and is what this program is all about. Cheers! Sean -- 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
